On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> PMS405 is used in QCS405-EVB so include that with SPMI nodes
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcs404-evb.dts | 1 +
> arch/arm64/boot/dts/qcom/qcs404.dtsi| 18
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> PMS405 is used in QCS405-EVB so include that with SPMI nodes
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcs404-evb.dts | 1 +
> arch/arm64/boot/dts/qcom/qcs404.dtsi| 18
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> RTC is found on PMIC PMS405 and is same as other PMIC used, so add the
> rtc node with compatible as qcom,pm8941-rtc
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/pms405.dtsi | 6
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> RTC is found on PMIC PMS405 and is same as other PMIC used, so add the
> rtc node with compatible as qcom,pm8941-rtc
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/pms405.dtsi | 6
> On Nov 5, 2018, at 9:49 AM, Nadav Amit wrote:
>
> From: Andy Lutomirski
> Sent: November 5, 2018 at 5:22:32 PM GMT
>> To: Peter Zijlstra
>> Cc: Nadav Amit , Ingo Molnar ,
>> linux-kernel@vger.kernel.org, x...@kernel.org, H. Peter Anvin
>> , Thomas Gleixner , Borislav Petkov
>> , Dave
> On Nov 5, 2018, at 9:49 AM, Nadav Amit wrote:
>
> From: Andy Lutomirski
> Sent: November 5, 2018 at 5:22:32 PM GMT
>> To: Peter Zijlstra
>> Cc: Nadav Amit , Ingo Molnar ,
>> linux-kernel@vger.kernel.org, x...@kernel.org, H. Peter Anvin
>> , Thomas Gleixner , Borislav Petkov
>> , Dave
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> Add the smp2p-adsp, smp2p-cdsp and smp2p-wcss nodes found in QCS404.
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 60
>
> 1
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> Add the smp2p-adsp, smp2p-cdsp and smp2p-wcss nodes found in QCS404.
>
> Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 60
>
> 1
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> Add the pms405 DT file with spmi node.
>
> Signed-off-by: Vinod Koul
> ---
> arch/arm64/boot/dts/qcom/pms405.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/pms405.dtsi
>
> diff
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> Add the pms405 DT file with spmi node.
>
> Signed-off-by: Vinod Koul
> ---
> arch/arm64/boot/dts/qcom/pms405.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/pms405.dtsi
>
> diff
On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
> apply ?
Personally I don't think it needs to go to stable, because I don't see any
functional failures caused by this invalid register access.
Thanks,
Tao Ren
On 11/5/18, 10:51 AM, "Daniel Lezcano" wrote:
> Oh right, sorry. Should it go to stable also ? Is there a Fixes tag it can
> apply ?
Personally I don't think it needs to go to stable, because I don't see any
functional failures caused by this invalid register access.
Thanks,
Tao Ren
get_scattered_cpuid_leaf() was added[1] to help KVM rebuild hardware-
defined leafs that are rearranged by Linux to avoid bloating the
x86_capability array. Eventually, the last consumer of the function
was removed[2], but the function itself was kept, perhaps even
intentionally as a form of
get_scattered_cpuid_leaf() was added[1] to help KVM rebuild hardware-
defined leafs that are rearranged by Linux to avoid bloating the
x86_capability array. Eventually, the last consumer of the function
was removed[2], but the function itself was kept, perhaps even
intentionally as a form of
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> b/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> new file mode 100644
> index ..74dc09ddb0d2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> @@ -0,0 +1,21 @@
> +//
On Mon 05 Nov 07:45 PST 2018, Vinod Koul wrote:
> diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> b/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> new file mode 100644
> index ..74dc09ddb0d2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dts
> @@ -0,0 +1,21 @@
> +//
On 5 November 2018 at 19:53, Jessica Yu wrote:
> Instead of saving a pointer to the .plt and .init.plt sections to apply
> plt-based relocations, save and use their section indices instead.
>
> The mod->arch.{core,init}.plt pointers were problematic for livepatch
> because they pointed within
On 5 November 2018 at 19:53, Jessica Yu wrote:
> Instead of saving a pointer to the .plt and .init.plt sections to apply
> plt-based relocations, save and use their section indices instead.
>
> The mod->arch.{core,init}.plt pointers were problematic for livepatch
> because they pointed within
Instead of saving a pointer to the .plt and .init.plt sections to apply
plt-based relocations, save and use their section indices instead.
The mod->arch.{core,init}.plt pointers were problematic for livepatch
because they pointed within temporary section headers (provided by the
module loader
Instead of saving a pointer to the .plt and .init.plt sections to apply
plt-based relocations, save and use their section indices instead.
The mod->arch.{core,init}.plt pointers were problematic for livepatch
because they pointed within temporary section headers (provided by the
module loader
On Mon, Nov 5, 2018 at 3:17 AM Heikki Krogerus
wrote:
>
> Instead of always being forced to read the "name" property
> in fwnode_name() with of_nodes, implementing the fwnode
> operation meant for getting the node name.
>
> Signed-off-by: Heikki Krogerus
> Cc: Rob Herring
> ---
>
On Mon, Nov 5, 2018 at 3:17 AM Heikki Krogerus
wrote:
>
> Instead of always being forced to read the "name" property
> in fwnode_name() with of_nodes, implementing the fwnode
> operation meant for getting the node name.
>
> Signed-off-by: Heikki Krogerus
> Cc: Rob Herring
> ---
>
On 05/11/2018 19:43, Tao Ren wrote:
> On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>>
>> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>>
>>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>>> for masking interrupts on ast2500 chips, and it's not even listed in
>>>
On 05/11/2018 19:43, Tao Ren wrote:
> On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>>
>> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>>
>>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>>> for masking interrupts on ast2500 chips, and it's not even listed in
>>>
Hi Daniel,
On 5 Nov 2018, at 11:55, Daniel Jordan wrote:
> Hi,
>
> This version addresses some of the feedback from Andrew and Michal last year
> and describes the plan for tackling the rest. I'm posting now since I'll be
> presenting ktask at Plumbers next week.
>
> Andrew, you asked about
Hi Daniel,
On 5 Nov 2018, at 11:55, Daniel Jordan wrote:
> Hi,
>
> This version addresses some of the feedback from Andrew and Michal last year
> and describes the plan for tackling the rest. I'm posting now since I'll be
> presenting ktask at Plumbers next week.
>
> Andrew, you asked about
Em Mon, Nov 05, 2018 at 02:11:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Nov 05, 2018 at 07:44:33AM -0800, Guenter Roeck escreveu:
> > On Wed, Oct 31, 2018 at 01:44:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > > From: Arnaldo Carvalho de Melo
> > > Now when we run 'make -C
Em Mon, Nov 05, 2018 at 02:11:40PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Nov 05, 2018 at 07:44:33AM -0800, Guenter Roeck escreveu:
> > On Wed, Oct 31, 2018 at 01:44:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > > From: Arnaldo Carvalho de Melo
> > > Now when we run 'make -C
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>
> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access
On 10/7/18, 2:03 PM, "Linus Walleij" wrote:
>
> On Wed, Oct 3, 2018 at 11:54 PM Tao Ren wrote:
>
>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access
My Name is Yeong Keun Lee I am the executive Chairman Of Bank Of China.I have
an Urgent Business Proposal worth US$150,000,000.00 to share with you in the
ratio of 60% for me, 40% for you, that will be of benefit for both of us, if
interested please get back to me by Email:
My Name is Yeong Keun Lee I am the executive Chairman Of Bank Of China.I have
an Urgent Business Proposal worth US$150,000,000.00 to share with you in the
ratio of 60% for me, 40% for you, that will be of benefit for both of us, if
interested please get back to me by Email:
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
>
> Actually, the commit is mainly for optimizing the long stall time caused
> by holding mmap_sem by write when unmapping or shrinking large mapping.
> It downgrades write mmap_sem to read when zapping pages. So, it looks
> the downgrade incurs
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
>
> Actually, the commit is mainly for optimizing the long stall time caused
> by holding mmap_sem by write when unmapping or shrinking large mapping.
> It downgrades write mmap_sem to read when zapping pages. So, it looks
> the downgrade incurs
On Mon 05-11-18 16:04:00, Mikhail Zaslonko wrote:
[...]
> Another approach was to fix memmap_init() and initialize struct pages
> beyond the end.
Yes I still do not want to give up at least this option. We do have
struct pages for the full section. Leaving som of them uninitialized is
just asking
On Mon 05-11-18 16:04:00, Mikhail Zaslonko wrote:
[...]
> Another approach was to fix memmap_init() and initialize struct pages
> beyond the end.
Yes I still do not want to give up at least this option. We do have
struct pages for the full section. Leaving som of them uninitialized is
just asking
Hi,
typo below:
On 11/5/18 9:02 AM, Lucas Stach wrote:
> Device drivers with optional firmware may still want to use the
> asynchronous firmware loading interface. To avoid printing a
> warning into the kernel log when the optional firmware is
> absent, add a nowarn variant of this interface.
>
Hi,
typo below:
On 11/5/18 9:02 AM, Lucas Stach wrote:
> Device drivers with optional firmware may still want to use the
> asynchronous firmware loading interface. To avoid printing a
> warning into the kernel log when the optional firmware is
> absent, add a nowarn variant of this interface.
>
Mark,
On Mon, Oct 22, 2018 at 6:07 PM Ryan Case wrote:
>
> Address remaining comments from original driver patch series
>
> * Move RD_FIFO_CFG to be ordered corretly
> * Expand spinlock comment
>
> Signed-off-by: Ryan Case
> ---
>
> drivers/spi/spi-qcom-qspi.c | 8
> 1 file changed, 4
Mark,
On Mon, Oct 22, 2018 at 6:07 PM Ryan Case wrote:
>
> Address remaining comments from original driver patch series
>
> * Move RD_FIFO_CFG to be ordered corretly
> * Expand spinlock comment
>
> Signed-off-by: Ryan Case
> ---
>
> drivers/spi/spi-qcom-qspi.c | 8
> 1 file changed, 4
On 11/5/18 9:50 AM, Linus Torvalds wrote:
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
shrinking")
Ugh. That looks pretty bad.
in testcase:
On 11/5/18 9:50 AM, Linus Torvalds wrote:
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
shrinking")
Ugh. That looks pretty bad.
in testcase:
I ran into a similar problem with my PEBS virtualization patchkit.
My solution was: basically schedule as normal, but tell the scheduler to
force allocate a counter on a specific index. It can be done
only with a few lines of change in the scheduler code.
-Andi
I ran into a similar problem with my PEBS virtualization patchkit.
My solution was: basically schedule as normal, but tell the scheduler to
force allocate a counter on a specific index. It can be done
only with a few lines of change in the scheduler code.
-Andi
From: Arnaldo Carvalho de Melo
Date: Mon, 5 Nov 2018 14:29:46 -0300
>> @@ -2542,6 +2542,46 @@ int machine__get_kernel_start(struct machine *machine)
>> return err;
>> }
>>
>> +/*
>> + * machine__single_ku_as - Machine has same address space for kernel and
>> user.
>> + * @machine:
From: Arnaldo Carvalho de Melo
Date: Mon, 5 Nov 2018 14:29:46 -0300
>> @@ -2542,6 +2542,46 @@ int machine__get_kernel_start(struct machine *machine)
>> return err;
>> }
>>
>> +/*
>> + * machine__single_ku_as - Machine has same address space for kernel and
>> user.
>> + * @machine:
Hello Arnaud,
On 11/5/2018 4:43 PM, Arnaud Pouliquen wrote:
Hello Rohit,
On 11/2/18 1:06 PM, Rohit Kumar wrote:
On 11/2/2018 1:12 PM, Takashi Iwai wrote:
On Thu, 01 Nov 2018 13:38:49 +0100,
Rohit kumar wrote:
Remove no_pcm check to invoke pcm_new() for backend dai-links
too. This fixes
Hello Arnaud,
On 11/5/2018 4:43 PM, Arnaud Pouliquen wrote:
Hello Rohit,
On 11/2/18 1:06 PM, Rohit Kumar wrote:
On 11/2/2018 1:12 PM, Takashi Iwai wrote:
On Thu, 01 Nov 2018 13:38:49 +0100,
Rohit kumar wrote:
Remove no_pcm check to invoke pcm_new() for backend dai-links
too. This fixes
Hi Yangtao,
On Mon, Nov 05, 2018 at 09:50:49AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
> ---
> arch/mips/math-emu/me-debugfs.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
Thanks - applied to
Hi Yangtao,
On Mon, Nov 05, 2018 at 09:50:49AM -0500, Yangtao Li wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Yangtao Li
> ---
> arch/mips/math-emu/me-debugfs.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
Thanks - applied to
From: Thomas Gleixner
Sent: November 4, 2018 at 8:58:20 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org>,
> x...@kernel.org>, H. Peter Anvin , Borislav Petkov
> , Dave Hansen , Jiri Kosina
> , Andy Lutomirski , Kees Cook
> , Dave Hansen
> Subject: Re: [PATCH v3 1/7]
From: Thomas Gleixner
Sent: November 4, 2018 at 8:58:20 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org>,
> x...@kernel.org>, H. Peter Anvin , Borislav Petkov
> , Dave Hansen , Jiri Kosina
> , Andy Lutomirski , Kees Cook
> , Dave Hansen
> Subject: Re: [PATCH v3 1/7]
Hi Aaro,
On Sat, Oct 27, 2018 at 01:46:34AM +0300, Aaro Koskinen wrote:
> The maximum number of interfaces is returned by
> cvmx_helper_get_number_of_interfaces(), and the value is used to access
> interface_port_count[]. When CN68XX support was added, we forgot
> to increase the array size. Fix
Hi Aaro,
On Sat, Oct 27, 2018 at 01:46:34AM +0300, Aaro Koskinen wrote:
> The maximum number of interfaces is returned by
> cvmx_helper_get_number_of_interfaces(), and the value is used to access
> interface_port_count[]. When CN68XX support was added, we forgot
> to increase the array size. Fix
Hi Dhaval,
On 9/19/18 7:13 PM, Dhaval Giani wrote:
Hi folks,
Sasha and I are pleased to announce the Testing and Fuzzing track at
LPC [ 1 ]. We are planning to continue the discussions from last
year's microconference [2]. Many discussions from the Automated
Testing Summit [3] will also
Hi Dhaval,
On 9/19/18 7:13 PM, Dhaval Giani wrote:
Hi folks,
Sasha and I are pleased to announce the Testing and Fuzzing track at
LPC [ 1 ]. We are planning to continue the discussions from last
year's microconference [2]. Many discussions from the Automated
Testing Summit [3] will also
From: Peter Zijlstra
Sent: November 5, 2018 at 1:30:41 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org,
> x...@kernel.org, H. Peter Anvin , Thomas Gleixner
> , Borislav Petkov , Dave Hansen
> , Andy Lutomirski , Kees Cook
> , Dave Hansen , Masami
> Hiramatsu
>
From: Peter Zijlstra
Sent: November 5, 2018 at 1:30:41 PM GMT
> To: Nadav Amit
> Cc: Ingo Molnar , linux-kernel@vger.kernel.org,
> x...@kernel.org, H. Peter Anvin , Thomas Gleixner
> , Borislav Petkov , Dave Hansen
> , Andy Lutomirski , Kees Cook
> , Dave Hansen , Masami
> Hiramatsu
>
On 5 November 2018 at 18:57, Jessica Yu wrote:
> Instead of saving a pointer to the .plt and .init.plt sections to apply
> plt-based relocations, save and use their section indices instead.
>
> The mod->arch.{core,init}.plt pointers were problematic for livepatch
> because they pointed within
On 5 November 2018 at 18:57, Jessica Yu wrote:
> Instead of saving a pointer to the .plt and .init.plt sections to apply
> plt-based relocations, save and use their section indices instead.
>
> The mod->arch.{core,init}.plt pointers were problematic for livepatch
> because they pointed within
Em Sun, Nov 04, 2018 at 05:12:34PM +0200, Adrian Hunter escreveu:
> Hi
>
> Here is the libxed fix, the last 2 patches from last submission and another
> fix.
>
> Changes in V2:
Thanks, applied the four patches.
- Arnaldo
> On Tue, 2018-10-30 at 21:26 +, justin.l...@dell.com wrote:
> > > +int ncsi_reset_dev(struct ncsi_dev *nd)
> > > +{
> > > + struct ncsi_dev_priv *ndp = TO_NCSI_DEV_PRIV(nd);
> > > + struct ncsi_channel *nc, *active;
> > > + struct ncsi_package *np;
> > > + unsigned long flags;
> > > + bool
Em Sun, Nov 04, 2018 at 05:12:34PM +0200, Adrian Hunter escreveu:
> Hi
>
> Here is the libxed fix, the last 2 patches from last submission and another
> fix.
>
> Changes in V2:
Thanks, applied the four patches.
- Arnaldo
> On Tue, 2018-10-30 at 21:26 +, justin.l...@dell.com wrote:
> > > +int ncsi_reset_dev(struct ncsi_dev *nd)
> > > +{
> > > + struct ncsi_dev_priv *ndp = TO_NCSI_DEV_PRIV(nd);
> > > + struct ncsi_channel *nc, *active;
> > > + struct ncsi_package *np;
> > > + unsigned long flags;
> > > + bool
Em Mon, Nov 05, 2018 at 09:35:03AM +0200, Adrian Hunter escreveu:
> Hi
>
> Here is a couple of small patches to add more information to the Intel PT
> debug log.
>
>
> Adrian Hunter (2):
> perf intel-pt: Add more event information to debug log
> perf intel-pt: Add MTC and CYC
Em Mon, Nov 05, 2018 at 09:35:03AM +0200, Adrian Hunter escreveu:
> Hi
>
> Here is a couple of small patches to add more information to the Intel PT
> debug log.
>
>
> Adrian Hunter (2):
> perf intel-pt: Add more event information to debug log
> perf intel-pt: Add MTC and CYC
Greetings From Mrs.elodie antoine,
May be this letter will definitely come to you as a huge surprise, but I
implore you to take the time to go through it carefully as the decision you
make will go off a long way to determine my future and continued existence. I
am Mrs.elodie antoine, aging
Greetings From Mrs.elodie antoine,
May be this letter will definitely come to you as a huge surprise, but I
implore you to take the time to go through it carefully as the decision you
make will go off a long way to determine my future and continued existence. I
am Mrs.elodie antoine, aging
On 11/5/18 8:27 AM, Waiman Long wrote:
> So gcc had changed to avoid doing that, but my main concern are old
> binaries that were compiled with old gcc.
Yeah, fair enough.
FWIW, I don't have any strong feelings about this patch either way, but
supporting old binaries/compilers without crashing
On 11/5/18 8:27 AM, Waiman Long wrote:
> So gcc had changed to avoid doing that, but my main concern are old
> binaries that were compiled with old gcc.
Yeah, fair enough.
FWIW, I don't have any strong feelings about this patch either way, but
supporting old binaries/compilers without crashing
On Mon, Nov 05, 2018 at 09:57:47AM -0800, Linus Torvalds wrote:
> Willy,
>
> On Sun, Nov 4, 2018 at 11:03 PM kernel test robot
> wrote:
> >
> > commit: 0e9446c35a80931044b6d8d2d74a9cabd248539f ("xarray: Add range store
> > functionality")
> ...
> > [ 11.880031] WARNING: CPU: 0 PID: 1 at
On Mon, Nov 05, 2018 at 09:57:47AM -0800, Linus Torvalds wrote:
> Willy,
>
> On Sun, Nov 4, 2018 at 11:03 PM kernel test robot
> wrote:
> >
> > commit: 0e9446c35a80931044b6d8d2d74a9cabd248539f ("xarray: Add range store
> > functionality")
> ...
> > [ 11.880031] WARNING: CPU: 0 PID: 1 at
On Mon, Nov 5, 2018 at 1:19 AM Masahiro Yamada
wrote:
>
> On Mon, Nov 5, 2018 at 6:10 PM Stefan Agner wrote:
> >
> > On 05.11.2018 03:48, Masahiro Yamada wrote:
> > > Add basic options for Clang such as --target, --prefix, --gcc-toolchain,
> > > -no-integrated-as to a single variable
On Mon, Nov 5, 2018 at 1:19 AM Masahiro Yamada
wrote:
>
> On Mon, Nov 5, 2018 at 6:10 PM Stefan Agner wrote:
> >
> > On 05.11.2018 03:48, Masahiro Yamada wrote:
> > > Add basic options for Clang such as --target, --prefix, --gcc-toolchain,
> > > -no-integrated-as to a single variable
* Eial Czerwacki wrote:
> +#if defined(CONFIG_PCI)
This is shorter:
#ifdef CONFIG_PCI
Thanks,
Ingo
* Eial Czerwacki wrote:
> +#if defined(CONFIG_PCI)
This is shorter:
#ifdef CONFIG_PCI
Thanks,
Ingo
Willy,
On Sun, Nov 4, 2018 at 11:03 PM kernel test robot wrote:
>
> commit: 0e9446c35a80931044b6d8d2d74a9cabd248539f ("xarray: Add range store
> functionality")
...
> [ 11.880031] WARNING: CPU: 0 PID: 1 at include/linux/xarray.h:54
> xa_mk_value+0x7/0x10
> [ 11.881944] EIP:
Willy,
On Sun, Nov 4, 2018 at 11:03 PM kernel test robot wrote:
>
> commit: 0e9446c35a80931044b6d8d2d74a9cabd248539f ("xarray: Add range store
> functionality")
...
> [ 11.880031] WARNING: CPU: 0 PID: 1 at include/linux/xarray.h:54
> xa_mk_value+0x7/0x10
> [ 11.881944] EIP:
Instead of saving a pointer to the .plt and .init.plt sections to apply
plt-based relocations, save and use their section indices instead.
The mod->arch.{core,init}.plt pointers were problematic for livepatch
because they pointed within temporary section headers (provided by the
module loader
Hi Marc,
On 11/5/2018 10:14 PM, Marc Zyngier wrote:
> On 05/11/18 16:20, Lokesh Vutla wrote:
>> Hi Marc,
>>
>> On Monday 05 November 2018 09:06 PM, Marc Zyngier wrote:
>>> On 05/11/18 08:08, Lokesh Vutla wrote:
Hi Marc,
On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
>
Instead of saving a pointer to the .plt and .init.plt sections to apply
plt-based relocations, save and use their section indices instead.
The mod->arch.{core,init}.plt pointers were problematic for livepatch
because they pointed within temporary section headers (provided by the
module loader
Hi Marc,
On 11/5/2018 10:14 PM, Marc Zyngier wrote:
> On 05/11/18 16:20, Lokesh Vutla wrote:
>> Hi Marc,
>>
>> On Monday 05 November 2018 09:06 PM, Marc Zyngier wrote:
>>> On 05/11/18 08:08, Lokesh Vutla wrote:
Hi Marc,
On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
>
Em Mon, Nov 05, 2018 at 07:44:33AM -0800, Guenter Roeck escreveu:
> On Wed, Oct 31, 2018 at 01:44:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo
> >
> > Now when we run 'make -C tools/perf O=/tmp/build/perf' we end up with:
> >
> > $ cat
Em Mon, Nov 05, 2018 at 07:44:33AM -0800, Guenter Roeck escreveu:
> On Wed, Oct 31, 2018 at 01:44:59PM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo
> >
> > Now when we run 'make -C tools/perf O=/tmp/build/perf' we end up with:
> >
> > $ cat
Em Wed, Oct 31, 2018 at 11:10:39AM +0200, Adrian Hunter escreveu:
> For branch stacks or branch samples, the sample cpumode might not be
> correct because it applies only to the sample 'ip' and not necessary to
> 'addr' or branch stack addresses. Add fallback functions that can be used
> to deal
Em Wed, Oct 31, 2018 at 11:10:39AM +0200, Adrian Hunter escreveu:
> For branch stacks or branch samples, the sample cpumode might not be
> correct because it applies only to the sample 'ip' and not necessary to
> 'addr' or branch stack addresses. Add fallback functions that can be used
> to deal
Em Wed, Oct 31, 2018 at 11:10:41AM +0200, Adrian Hunter escreveu:
> Branch stacks do not necessarily have the same cpumode as the 'ip'. Use the
> fallback functions in those cases.
>
> This patch depends on patch "perf tools: Add fallback functions for cases
>> where cpumode is insufficient".
Em Wed, Oct 31, 2018 at 11:10:41AM +0200, Adrian Hunter escreveu:
> Branch stacks do not necessarily have the same cpumode as the 'ip'. Use the
> fallback functions in those cases.
>
> This patch depends on patch "perf tools: Add fallback functions for cases
>> where cpumode is insufficient".
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
>
> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
> shrinking")
Ugh. That looks pretty bad.
> in testcase: will-it-scale
> on test machine: 8
On Sun, Nov 4, 2018 at 9:08 PM kernel test robot wrote:
>
> FYI, we noticed a -64.1% regression of will-it-scale.per_thread_ops
> due to commit 9bc8039e715d ("mm: brk: downgrade mmap_sem to read when
> shrinking")
Ugh. That looks pretty bad.
> in testcase: will-it-scale
> on test machine: 8
From: Andy Lutomirski
Sent: November 5, 2018 at 5:22:32 PM GMT
> To: Peter Zijlstra
> Cc: Nadav Amit , Ingo Molnar ,
> linux-kernel@vger.kernel.org, x...@kernel.org, H. Peter Anvin
> , Thomas Gleixner , Borislav Petkov
> , Dave Hansen , Andy Lutomirski
> , Kees Cook , Dave Hansen
> , Masami
From: Andy Lutomirski
Sent: November 5, 2018 at 5:22:32 PM GMT
> To: Peter Zijlstra
> Cc: Nadav Amit , Ingo Molnar ,
> linux-kernel@vger.kernel.org, x...@kernel.org, H. Peter Anvin
> , Thomas Gleixner , Borislav Petkov
> , Dave Hansen , Andy Lutomirski
> , Kees Cook , Dave Hansen
> , Masami
On Sat, Nov 03, 2018 at 03:22:34PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 3, 2018 at 1:17 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
> > Enumerate Enclave Page Cache (EPC) sections via CPUID and add the data
> > structures necessary to track EPC pages so that they can
On Sat, Nov 03, 2018 at 03:22:34PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 3, 2018 at 1:17 AM Jarkko Sakkinen
> wrote:
> >
> > From: Sean Christopherson
> >
> > Enumerate Enclave Page Cache (EPC) sections via CPUID and add the data
> > structures necessary to track EPC pages so that they can
Em Mon, Nov 05, 2018 at 10:10:27AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Nov 05, 2018 at 08:31:59AM +0800, Jin, Yao escreveu:
> > Hi,
> >
> > Any comments for this patch?
>
> I'll check it today, I'm just a bit behind while preparing for plumbers,
> I'll get to all the patches :-)
Em Mon, Nov 05, 2018 at 10:10:27AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Nov 05, 2018 at 08:31:59AM +0800, Jin, Yao escreveu:
> > Hi,
> >
> > Any comments for this patch?
>
> I'll check it today, I'm just a bit behind while preparing for plumbers,
> I'll get to all the patches :-)
vSMP dependency on pv_irq_ops has been removed some years ago, but the code
still deals with pv_irq_ops.
In short, "cap & ctl & (1 << 4)" is always returning 0, so all
PARAVIRT/PARAVIRT_XXL code related to that can be removed.
However, the rest of the code depends on CONFIG_PCI, so fix it
vSMP dependency on pv_irq_ops has been removed some years ago, but the code
still deals with pv_irq_ops.
In short, "cap & ctl & (1 << 4)" is always returning 0, so all
PARAVIRT/PARAVIRT_XXL code related to that can be removed.
However, the rest of the code depends on CONFIG_PCI, so fix it
On Sat, Nov 03, 2018 at 01:07:27AM +, Jethro Beekman wrote:
> > + for (i = 0; i < SGX_MAX_EPC_SECTIONS; i++) {
>
> Perhaps print a warning if there are more than SGX_MAX_EPC_SECTIONS sections
> reported by CPUID.
Makes sense. I'll add it.
/Jarkko
On Sat, Nov 03, 2018 at 01:07:27AM +, Jethro Beekman wrote:
> > + for (i = 0; i < SGX_MAX_EPC_SECTIONS; i++) {
>
> Perhaps print a warning if there are more than SGX_MAX_EPC_SECTIONS sections
> reported by CPUID.
Makes sense. I'll add it.
/Jarkko
601 - 700 of 1452 matches
Mail list logo
