Hi Michael:
Thanks for your review.
On 6/6/2018 12:59 AM, Michael Kelley (EOSG) wrote:
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> On Behalf
>> Of Tianyu Lan
>> Sent: Monday, June 4, 2018 2:08 AM
>> Cc: Tianyu Lan ; KY Srinivasan
>> ; Haiyang
>> Zhang ;
Hi Michael:
Thanks for your review.
On 6/6/2018 12:59 AM, Michael Kelley (EOSG) wrote:
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> On Behalf
>> Of Tianyu Lan
>> Sent: Monday, June 4, 2018 2:08 AM
>> Cc: Tianyu Lan ; KY Srinivasan
>> ; Haiyang
>> Zhang ;
Hi,
> Am 05.06.2018 um 22:39 schrieb Pavel Machek :
>
> On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
>> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek wrote:
>>> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
The register constants are so far defined in a way that they fit
Hi,
> Am 05.06.2018 um 22:39 schrieb Pavel Machek :
>
> On Tue 2018-06-05 18:37:21, Andy Shevchenko wrote:
>> On Wed, May 23, 2018 at 5:06 PM, Pavel Machek wrote:
>>> On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote:
The register constants are so far defined in a way that they fit
On Tue, Jun 05, 2018 at 07:35:01AM +, Horiguchi Naoya(堀口 直也) wrote:
> On Mon, Jun 04, 2018 at 06:18:36PM -0700, Matthew Wilcox wrote:
> > On Tue, Jun 05, 2018 at 12:54:03AM +, Naoya Horiguchi wrote:
> > > Reproduction precedure is like this:
> > > - enable RAM based PMEM (with a kernel
On Tue, Jun 05, 2018 at 07:35:01AM +, Horiguchi Naoya(堀口 直也) wrote:
> On Mon, Jun 04, 2018 at 06:18:36PM -0700, Matthew Wilcox wrote:
> > On Tue, Jun 05, 2018 at 12:54:03AM +, Naoya Horiguchi wrote:
> > > Reproduction precedure is like this:
> > > - enable RAM based PMEM (with a kernel
On Tue, Jun 05, 2018 at 09:47:57AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:30PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC MFD.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 76
On Tue, Jun 05, 2018 at 09:47:57AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:30PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC MFD.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > .../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 76
Signed-off-by: Masatake YAMATO
---
arch/x86/include/asm/iommu_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/iommu_table.h
b/arch/x86/include/asm/iommu_table.h
index 1fb3fd1a83c2..2a0d5f7d1ed1 100644
--- a/arch/x86/include/asm/iommu_table.h
+++
Signed-off-by: Masatake YAMATO
---
arch/x86/include/asm/iommu_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/iommu_table.h
b/arch/x86/include/asm/iommu_table.h
index 1fb3fd1a83c2..2a0d5f7d1ed1 100644
--- a/arch/x86/include/asm/iommu_table.h
+++
On (06/05/18 14:47), Petr Mladek wrote:
[..]
> Grr, the ABBA deadlock is still there. NMIs are not sent to the other
> CPUs atomically. Even if we detect that logbuf_lock is available
> in printk_nmi_enter() on some CPUs, it might still get locked on
> another CPU before the other CPU gets NMI.
On (06/05/18 14:47), Petr Mladek wrote:
[..]
> Grr, the ABBA deadlock is still there. NMIs are not sent to the other
> CPUs atomically. Even if we detect that logbuf_lock is available
> in printk_nmi_enter() on some CPUs, it might still get locked on
> another CPU before the other CPU gets NMI.
On Tue, Jun 05, 2018 at 09:49:32AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:53PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC clock output.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > .../bindings/clock/rohm,bd71837-clock.txt
On Tue, Jun 05, 2018 at 09:49:32AM -0600, Rob Herring wrote:
> On Mon, Jun 04, 2018 at 04:18:53PM +0300, Matti Vaittinen wrote:
> > Document devicetree bindings for ROHM BD71837 PMIC clock output.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > .../bindings/clock/rohm,bd71837-clock.txt
On Wed, Jun 6, 2018 at 5:19 AM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
Thanks for an update.
My comments below.
I think you need to mentioned the string literal change in the commit message.
On Wed, Jun 6, 2018 at 5:19 AM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
Thanks for an update.
My comments below.
I think you need to mentioned the string literal change in the commit message.
Viresh got ahead of my answer a bit. :)
Sure I'll post the module exit later.
On June 6, 2018 7:09:29 AM GMT+03:00, Viresh Kumar
wrote:
>On 05-06-18, 13:44, Arnd Bergmann wrote:
>> Building the kryo cpufreq driver while QCOM_SMEM is a loadable module
>> results in a link error:
>>
>>
Viresh got ahead of my answer a bit. :)
Sure I'll post the module exit later.
On June 6, 2018 7:09:29 AM GMT+03:00, Viresh Kumar
wrote:
>On 05-06-18, 13:44, Arnd Bergmann wrote:
>> Building the kryo cpufreq driver while QCOM_SMEM is a loadable module
>> results in a link error:
>>
>>
On Tue, 5 Jun 2018 16:34:21 +0100
Will Deacon wrote:
> On Tue, Jun 05, 2018 at 12:51:24AM +0900, Masami Hiramatsu wrote:
> > Remove arch dependent setjump/longjump functions
> > and unused fields in kprobe_ctlblk for jprobes
> > from arch/arm64.
> >
> > Signed-off-by: Masami Hiramatsu
> > Cc:
On Tue, 5 Jun 2018 16:34:21 +0100
Will Deacon wrote:
> On Tue, Jun 05, 2018 at 12:51:24AM +0900, Masami Hiramatsu wrote:
> > Remove arch dependent setjump/longjump functions
> > and unused fields in kprobe_ctlblk for jprobes
> > from arch/arm64.
> >
> > Signed-off-by: Masami Hiramatsu
> > Cc:
On 04-06-18, 16:16, Taniya Das wrote:
> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> SoCs. This is required for managing the cpu frequency transitions which are
> controlled by firmware.
>
> Signed-off-by: Taniya Das
> ---
> .../bindings/cpufreq/cpufreq-qcom-fw.txt
On 04-06-18, 16:16, Taniya Das wrote:
> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
> SoCs. This is required for managing the cpu frequency transitions which are
> controlled by firmware.
>
> Signed-off-by: Taniya Das
> ---
> .../bindings/cpufreq/cpufreq-qcom-fw.txt
Introduce __pa_swapper_pg_dir to save physical address of
swapper_pg_dir. And pass it as an argument to __enable_mmu().
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/mmu_context.h | 4 +---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 +-
Introduce __pa_swapper_pg_dir to save physical address of
swapper_pg_dir. And pass it as an argument to __enable_mmu().
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/mmu_context.h | 4 +---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 +-
Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
do not correlate with kernel's address.
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/mmu.c | 79 +---
2 files changed, 52 insertions(+), 28
Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
do not correlate with kernel's address.
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/mmu.c | 79 +---
2 files changed, 52 insertions(+), 28
Version 3 changes:
* Fix memory leak problem with CONFIG_ARM64_SW_TTBR0_PAN
* add comment explaining why the flush is needed and also why
__pa_swapper_pg_dir gets placed in the .mmuoff.data.read
section.
[v2]
Prepare for migrating swapper_pg_dir, introduce new_swapper_pg_dir
to save virtual address of swapper_pg_dir.
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/mmu_context.h | 2 +-
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c
Prepare for migrating swapper_pg_dir, introduce new_swapper_pg_dir
to save virtual address of swapper_pg_dir.
Signed-off-by: Jun Yao
---
arch/arm64/include/asm/mmu_context.h | 2 +-
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c
Version 3 changes:
* Fix memory leak problem with CONFIG_ARM64_SW_TTBR0_PAN
* add comment explaining why the flush is needed and also why
__pa_swapper_pg_dir gets placed in the .mmuoff.data.read
section.
[v2]
On 05-06-18, 16:54, Daniel Lezcano wrote:
> On 05/06/2018 12:39, Viresh Kumar wrote:
> I don't think you are doing a mistake. Even if this can happen
> theoretically, I don't think practically that is the case.
>
> The play_idle() has 1ms minimum sleep time.
>
> The scenario you are describing
On 05-06-18, 16:54, Daniel Lezcano wrote:
> On 05/06/2018 12:39, Viresh Kumar wrote:
> I don't think you are doing a mistake. Even if this can happen
> theoretically, I don't think practically that is the case.
>
> The play_idle() has 1ms minimum sleep time.
>
> The scenario you are describing
On 05-06-18, 13:44, Arnd Bergmann wrote:
> Building the kryo cpufreq driver while QCOM_SMEM is a loadable module
> results in a link error:
>
> drivers/cpufreq/qcom-cpufreq-kryo.o: In function `qcom_cpufreq_kryo_probe':
> qcom-cpufreq-kryo.c:(.text+0xbc): undefined reference to `qcom_smem_get'
>
On 05-06-18, 13:44, Arnd Bergmann wrote:
> Building the kryo cpufreq driver while QCOM_SMEM is a loadable module
> results in a link error:
>
> drivers/cpufreq/qcom-cpufreq-kryo.o: In function `qcom_cpufreq_kryo_probe':
> qcom-cpufreq-kryo.c:(.text+0xbc): undefined reference to `qcom_smem_get'
>
Hi Thomas,
At 06/05/2018 07:41 PM, Thomas Gleixner wrote:
On Tue, 5 Jun 2018, Dou Liyang wrote:
+{
+ if (unlikely(irqd_is_setaffinity_pending(irqd)))
Affinity pending is also judged in
+ irq_move_irq(irqd);
If we can remove the if(...) statement here
That requires
Hi Thomas,
At 06/05/2018 07:41 PM, Thomas Gleixner wrote:
On Tue, 5 Jun 2018, Dou Liyang wrote:
+{
+ if (unlikely(irqd_is_setaffinity_pending(irqd)))
Affinity pending is also judged in
+ irq_move_irq(irqd);
If we can remove the if(...) statement here
That requires
Hi Linus,
2018-06-06 11:19 GMT+09:00 Linus Torvalds :
> On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
> wrote:
>>
>> But once you *have* that particular Kconfig, I do think that "make
>> oldconfig" should just work. And it apparently used to.
>>
>> So I think this is a behavioral regression.
>
>
Hi Linus,
2018-06-06 11:19 GMT+09:00 Linus Torvalds :
> On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
> wrote:
>>
>> But once you *have* that particular Kconfig, I do think that "make
>> oldconfig" should just work. And it apparently used to.
>>
>> So I think this is a behavioral regression.
>
>
Please reply me back i have something to tell u I am Sgt.Sherri Gallagher.
Please reply me back i have something to tell u I am Sgt.Sherri Gallagher.
On Tue, Jun 05, 2018 at 02:49:20PM -0500, Eric Sandeen wrote:
> From: Arnd Bergmann
>
> [sandeen: fix subject, avoid copy-out of uninit data in getlabel]
>
> gcc-8 reports two warnings for the newly added getlabel/setlabel code:
>
> fs/xfs/xfs_ioctl.c: In function 'xfs_ioc_getlabel':
>
On Tue, Jun 05, 2018 at 02:49:20PM -0500, Eric Sandeen wrote:
> From: Arnd Bergmann
>
> [sandeen: fix subject, avoid copy-out of uninit data in getlabel]
>
> gcc-8 reports two warnings for the newly added getlabel/setlabel code:
>
> fs/xfs/xfs_ioctl.c: In function 'xfs_ioc_getlabel':
>
On Tue, Jun 5, 2018 at 7:06 PM, Hans de Goede wrote:
> Hi,
>
>
> On 05-06-18 12:46, Benjamin Berg wrote:
>>
>> Hey,
>>
>> On Tue, 2018-06-05 at 12:31 +0200, Hans de Goede wrote:
>>>
>>> On 05-06-18 12:14, Bastien Nocera wrote:
On Tue, 2018-06-05 at 12:05 +0200, Hans de Goede wrote:
On Tue, Jun 5, 2018 at 7:06 PM, Hans de Goede wrote:
> Hi,
>
>
> On 05-06-18 12:46, Benjamin Berg wrote:
>>
>> Hey,
>>
>> On Tue, 2018-06-05 at 12:31 +0200, Hans de Goede wrote:
>>>
>>> On 05-06-18 12:14, Bastien Nocera wrote:
On Tue, 2018-06-05 at 12:05 +0200, Hans de Goede wrote:
When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.
If LPI is bind to offline cpu, sync cmd will use zero TA,
it leads to ITS queue timeout. Fix this by choosing a
online cpu, if there is no online cpu in
When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.
If LPI is bind to offline cpu, sync cmd will use zero TA,
it leads to ITS queue timeout. Fix this by choosing a
online cpu, if there is no online cpu in
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Greg Kroah-Hartman
Cc: Quytelda Kahja
Cc: de...@driverdev.osuosl.org
Signed-off-by: Yisheng Xie
---
v3:
- no need to check input tty's index - per Greg
v2:
- const
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Greg Kroah-Hartman
Cc: Quytelda Kahja
Cc: de...@driverdev.osuosl.org
Signed-off-by: Yisheng Xie
---
v3:
- no need to check input tty's index - per Greg
v2:
- const
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: "David S. Miller"
Cc: Anthony Yznaga
Cc: Pavel Tatashin
Cc: sparcli...@vger.kernel.org
Signed-off-by: Yisheng Xie
---
v3:
- add string literal instead of NULL for array
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: "David S. Miller"
Cc: Anthony Yznaga
Cc: Pavel Tatashin
Cc: sparcli...@vger.kernel.org
Signed-off-by: Yisheng Xie
---
v3:
- add string literal instead of NULL for array
On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
wrote:
>
> But once you *have* that particular Kconfig, I do think that "make
> oldconfig" should just work. And it apparently used to.
>
> So I think this is a behavioral regression.
That doesn't necessarily mean that he fix should be to revert.
On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
wrote:
>
> But once you *have* that particular Kconfig, I do think that "make
> oldconfig" should just work. And it apparently used to.
>
> So I think this is a behavioral regression.
That doesn't necessarily mean that he fix should be to revert.
Hi Bjorn,
On 2018/6/6 7:53, Bjorn Helgaas wrote:
> On Tue, May 29, 2018 at 08:18:18PM +0800, Yisheng Xie wrote:
>> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size:
>>
>> [2.470908] kernel BUG at lib/ioremap.c:72!
>> [2.475079] Internal error: Oops - BUG: 0 [#1]
Hi Bjorn,
On 2018/6/6 7:53, Bjorn Helgaas wrote:
> On Tue, May 29, 2018 at 08:18:18PM +0800, Yisheng Xie wrote:
>> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size:
>>
>> [2.470908] kernel BUG at lib/ioremap.c:72!
>> [2.475079] Internal error: Oops - BUG: 0 [#1]
G'day Brian,
One comment below.
On 2/06/2018 09:28, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true
G'day Brian,
One comment below.
On 2/06/2018 09:28, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por
el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser
capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de
correo electrónico. Para revalidar su buzón de
On Tue, Jun 5, 2018 at 6:38 PM Masahiro Yamada
wrote:
>
> Was the v4.16 behavior intentional,
> or just something people found to work?
I don't think all the _details_ may be intentional, but the fact that
make oldconfig
"just works" is definitely a good thing.
> "make ARCH=i386
On Tue, Jun 5, 2018 at 6:38 PM Masahiro Yamada
wrote:
>
> Was the v4.16 behavior intentional,
> or just something people found to work?
I don't think all the _details_ may be intentional, but the fact that
make oldconfig
"just works" is definitely a good thing.
> "make ARCH=i386
On 06/06, Dave Chinner wrote:
>On Tue, Jun 05, 2018 at 03:16:57PM +0800, kernel test robot wrote:
>>
>> Greeting,
>>
>> FYI, we noticed a +7.1%% regression of fio.latency_2ms% due to commit:
>>
>>
>> commit: b027d4c97b9675c2ad75dec94be4e46dceb3ec74 ("xfs: don't retry
>> xfs_buf_find on
On 06/06, Dave Chinner wrote:
>On Tue, Jun 05, 2018 at 03:16:57PM +0800, kernel test robot wrote:
>>
>> Greeting,
>>
>> FYI, we noticed a +7.1%% regression of fio.latency_2ms% due to commit:
>>
>>
>> commit: b027d4c97b9675c2ad75dec94be4e46dceb3ec74 ("xfs: don't retry
>> xfs_buf_find on
Hi, Julien
On 2018/6/5 18:16, Julien Thierry wrote:
Hi Yang,
On 05/06/18 07:30, Yang Yingliang wrote:
When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.
If LPI is bind to offline cpu, sync cmd will use zero
Hi, Julien
On 2018/6/5 18:16, Julien Thierry wrote:
Hi Yang,
On 05/06/18 07:30, Yang Yingliang wrote:
When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.
If LPI is bind to offline cpu, sync cmd will use zero
Hi Linus, Thomas,
2018-06-06 4:13 GMT+09:00 Linus Torvalds :
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund wrote:
>> >
>> > but why do you care?
>>
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
>
> Ahh. I can re-create that now.
>
> Yes,
Hi Linus, Thomas,
2018-06-06 4:13 GMT+09:00 Linus Torvalds :
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund wrote:
>> >
>> > but why do you care?
>>
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
>
> Ahh. I can re-create that now.
>
> Yes,
On Tue, Jun 5, 2018 at 5:08 PM, Jerome Glisse wrote:
> On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
[..]
>> I want the EXPORT_SYMBOL_GPL on devm_memremap_pages() primarily for
>> development purposes. Any new users of devm_memremap_pages() should be
>> aware that they are
On Tue, Jun 5, 2018 at 5:08 PM, Jerome Glisse wrote:
> On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
[..]
>> I want the EXPORT_SYMBOL_GPL on devm_memremap_pages() primarily for
>> development purposes. Any new users of devm_memremap_pages() should be
>> aware that they are
On 06/05/18 at 05:04pm, Christopher Lameter wrote:
> On Sun, 3 Jun 2018, Baoquan He wrote:
>
> > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> > index d9228e4d0320..3485c58cfd1c 100644
> > --- a/include/linux/slab_def.h
> > +++ b/include/linux/slab_def.h
> > @@ -67,9 +67,10
On 06/05/18 at 05:04pm, Christopher Lameter wrote:
> On Sun, 3 Jun 2018, Baoquan He wrote:
>
> > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
> > index d9228e4d0320..3485c58cfd1c 100644
> > --- a/include/linux/slab_def.h
> > +++ b/include/linux/slab_def.h
> > @@ -67,9 +67,10
When CONFIG_MODULE_SIG_FORCE is enabled, also provide a boot-time-only
parameter, module.sig_unenforce, to disable signature enforcement. This
allows distributions to ship with signature verification enforcement
enabled by default, but for users to elect to disable it without
recompiling, to
When CONFIG_MODULE_SIG_FORCE is enabled, also provide a boot-time-only
parameter, module.sig_unenforce, to disable signature enforcement. This
allows distributions to ship with signature verification enforcement
enabled by default, but for users to elect to disable it without
recompiling, to
On 06/04/2018 11:53 PM, Masahiro Yamada wrote:
> Hi Randy,
>
>
> 2018-06-04 11:59 GMT+09:00 Randy Dunlap :
>> From: Randy Dunlap
>>
>> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
>> that other required files are present and to determine build flags
>> settings, but
On 06/04/2018 11:53 PM, Masahiro Yamada wrote:
> Hi Randy,
>
>
> 2018-06-04 11:59 GMT+09:00 Randy Dunlap :
>> From: Randy Dunlap
>>
>> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
>> that other required files are present and to determine build flags
>> settings, but
On Tue, Jun 05, 2018 at 07:01:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.136 release.
> There are 37 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
.
Please pull, thanks.
-Paul
--
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20180605
for you
On Tue, Jun 05, 2018 at 07:01:05PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.136 release.
> There are 37 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
.
Please pull, thanks.
-Paul
--
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20180605
for you
Hi all,
On Wed, 30 May 2018 18:30:58 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> arch/arm/mm/fault.c
>
> between commit:
>
> 93a24d7e23e7 ("ARM: spectre-v2: harden user aborts in kernel space")
>
> from the arm tree and commit:
>
Hi all,
On Wed, 30 May 2018 18:30:58 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> arch/arm/mm/fault.c
>
> between commit:
>
> 93a24d7e23e7 ("ARM: spectre-v2: harden user aborts in kernel space")
>
> from the arm tree and commit:
>
On Tue, Jun 5, 2018 at 12:22 PM Tejun Heo wrote:
>
> * cgroup uses file modified events to notify certain events. A rate
> limiting mechanism is added.
This "explanation" didn't really parse for me at all.
I edited the merge message to something that I think is correct and
made more sense to
On Tue, Jun 5, 2018 at 12:22 PM Tejun Heo wrote:
>
> * cgroup uses file modified events to notify certain events. A rate
> limiting mechanism is added.
This "explanation" didn't really parse for me at all.
I edited the merge message to something that I think is correct and
made more sense to
On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
> On Tue, Jun 5, 2018 at 3:19 PM, Dave Airlie wrote:
> > On 6 June 2018 at 04:48, Jerome Glisse wrote:
> >> On Tue, May 29, 2018 at 04:33:49PM -0700, Dan Williams wrote:
> >>> On Tue, May 29, 2018 at 4:00 PM, Dave Airlie wrote:
> >>>
On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
> On Tue, Jun 5, 2018 at 3:19 PM, Dave Airlie wrote:
> > On 6 June 2018 at 04:48, Jerome Glisse wrote:
> >> On Tue, May 29, 2018 at 04:33:49PM -0700, Dan Williams wrote:
> >>> On Tue, May 29, 2018 at 4:00 PM, Dave Airlie wrote:
> >>>
Oh, you meant that it has keesc...@chromium.org author sign-off, but
it needs mine because I applied it.
Please add
Signed-off-by: Deepa Dinamani
I also updated it in my tree.
Thanks,
- Deepa
On Tue, Jun 5, 2018 at 4:17 PM, Stephen Rothwell wrote:
> Hi Deepa,
>
> On Tue, 5 Jun 2018 15:00:24
Oh, you meant that it has keesc...@chromium.org author sign-off, but
it needs mine because I applied it.
Please add
Signed-off-by: Deepa Dinamani
I also updated it in my tree.
Thanks,
- Deepa
On Tue, Jun 5, 2018 at 4:17 PM, Stephen Rothwell wrote:
> Hi Deepa,
>
> On Tue, 5 Jun 2018 15:00:24
On Tue, May 29, 2018 at 08:18:18PM +0800, Yisheng Xie wrote:
> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size:
>
> [2.470908] kernel BUG at lib/ioremap.c:72!
> [2.475079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [2.480551] Modules linked in:
> [
On Tue, May 29, 2018 at 08:18:18PM +0800, Yisheng Xie wrote:
> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size:
>
> [2.470908] kernel BUG at lib/ioremap.c:72!
> [2.475079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [2.480551] Modules linked in:
> [
(Resending since Andy wasn't on CC - sorry)
Hi,
On Tue, May 29, 2018 at 05:04:59PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In this patch we introduce a test module for simulating a long atomic
> section in the kernel which the preemptoff or irqsoff tracers can
>
(Resending since Andy wasn't on CC - sorry)
Hi,
On Tue, May 29, 2018 at 05:04:59PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In this patch we introduce a test module for simulating a long atomic
> section in the kernel which the preemptoff or irqsoff tracers can
>
Hi all,
Please do *not* add any v4.19 related material to your linux-next
included branches until after v4.18-rc1 has been released i.e. during
the current merge window.
--
Cheers,
Stephen Rothwell
pgpjhWrkCQJDU.pgp
Description: OpenPGP digital signature
Hi all,
Please do *not* add any v4.19 related material to your linux-next
included branches until after v4.18-rc1 has been released i.e. during
the current merge window.
--
Cheers,
Stephen Rothwell
pgpjhWrkCQJDU.pgp
Description: OpenPGP digital signature
On Tue, Jun 5, 2018 at 4:20 PM Alexey Dobriyan wrote:
>
> This is Broadwell Xeon E5-2620 v4.
> Which is somewhat strange indeed because it should be modern enough.
Yeah, odd.
Here's the benchmark I used:
#define SIZE 4068
int main(int argc, char **argv)
{
int i;
unsigned char
On Tue, Jun 5, 2018 at 4:20 PM Alexey Dobriyan wrote:
>
> This is Broadwell Xeon E5-2620 v4.
> Which is somewhat strange indeed because it should be modern enough.
Yeah, odd.
Here's the benchmark I used:
#define SIZE 4068
int main(int argc, char **argv)
{
int i;
unsigned char
On 05/27/2018 11:00 PM, MyungJoo Ham wrote:
Many CPU architectures have caches that can scale independent of the CPUs.
Frequency scaling of the caches is necessary to make sure the cache is not
a performance bottleneck that leads to poor performance and power. The same
idea applies for
On 05/27/2018 11:00 PM, MyungJoo Ham wrote:
Many CPU architectures have caches that can scale independent of the CPUs.
Frequency scaling of the caches is necessary to make sure the cache is not
a performance bottleneck that leads to poor performance and power. The same
idea applies for
On Tue, Jun 05, 2018 at 04:04:37PM -0700, Linus Torvalds wrote:
> On Tue, Jun 5, 2018 at 4:01 PM Linus Torvalds
> wrote:
> >
> > On Tue, Jun 5, 2018 at 3:41 PM Alexey Dobriyan wrote:
> > >
> > > On my potato performance increase is 33%, sheesh.
> > > And CPU starts doing 3 instructions per cycle
On Tue, Jun 05, 2018 at 04:04:37PM -0700, Linus Torvalds wrote:
> On Tue, Jun 5, 2018 at 4:01 PM Linus Torvalds
> wrote:
> >
> > On Tue, Jun 5, 2018 at 3:41 PM Alexey Dobriyan wrote:
> > >
> > > On my potato performance increase is 33%, sheesh.
> > > And CPU starts doing 3 instructions per cycle
1 - 100 of 1606 matches
Mail list logo
