Hi all,
Commit
b6fbc2f6a686 ("GFS2: Fix recovery issues for spectators")
is missing a Signed-off-by from its committer. It was rebased.
--
Cheers,
Stephen Rothwell
pgpT7fPZVLrkY.pgp
Description: OpenPGP digital signature
Hi all,
Commit
b6fbc2f6a686 ("GFS2: Fix recovery issues for spectators")
is missing a Signed-off-by from its committer. It was rebased.
--
Cheers,
Stephen Rothwell
pgpT7fPZVLrkY.pgp
Description: OpenPGP digital signature
Hi arm-soc maintainers,
Please merge the following tag to get updates to the soc/fsl drivers:
Moves DPAA2 DPIO driver from staging to fsl/soc
Adds multiple-pin support to QE gpio driver
Regards,
Leo
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux
Hi arm-soc maintainers,
Please merge the following tag to get updates to the soc/fsl drivers:
Moves DPAA2 DPIO driver from staging to fsl/soc
Adds multiple-pin support to QE gpio driver
Regards,
Leo
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux
A reminder to review a few patches I had sent last week. Below are the
links for the patches.
https://lkml.org/lkml/2018/7/5/798
http://lists-archives.com/linux-kernel/29168320-checkpatch-check-for-invalid-return-codes.html
- Prakruthi Deepak Heragu
A reminder to review a few patches I had sent last week. Below are the
links for the patches.
https://lkml.org/lkml/2018/7/5/798
http://lists-archives.com/linux-kernel/29168320-checkpatch-check-for-invalid-return-codes.html
- Prakruthi Deepak Heragu
On Tue, Jul 24, 2018 at 9:38 AM, Ioana Ciocoi Radulescu
wrote:
>> -Original Message-
>> From: Horia Geanta
>> Sent: Tuesday, July 24, 2018 5:35 PM
>> To: Roy Pledge ; de...@driverdev.osuosl.org; linux-
>> arm-ker...@lists.infradead.org; gre...@linuxfoundation.org; Leo Li
>>
>> Cc:
On Tue, Jul 24, 2018 at 9:38 AM, Ioana Ciocoi Radulescu
wrote:
>> -Original Message-
>> From: Horia Geanta
>> Sent: Tuesday, July 24, 2018 5:35 PM
>> To: Roy Pledge ; de...@driverdev.osuosl.org; linux-
>> arm-ker...@lists.infradead.org; gre...@linuxfoundation.org; Leo Li
>>
>> Cc:
On Tue, Jul 24 2018, Brian Norris wrote:
> Hi,
>
> On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
>> On Tue, Jul 24 2018, Boris Brezillon wrote:
>> > On Tue, 24 Jul 2018 08:46:33 +1000
>> > NeilBrown wrote:
>> >> One possibility that occurred to me when I was exploring this issue is
On Tue, Jul 24, 2018 at 9:01 AM, Vasundhara Volam
wrote:
> On Tue, Jul 24, 2018 at 1:01 PM, Michael Chan
> wrote:
>>
>> On Mon, Jul 23, 2018 at 10:24 PM, YueHaibing wrote:
>> > Based on the comments,req->l2addr must match the VF MAC address
>> > if firmware spec >= 1.2.2, mac_ok can be true.
On Tue, Jul 24 2018, Brian Norris wrote:
> Hi,
>
> On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
>> On Tue, Jul 24 2018, Boris Brezillon wrote:
>> > On Tue, 24 Jul 2018 08:46:33 +1000
>> > NeilBrown wrote:
>> >> One possibility that occurred to me when I was exploring this issue is
On Tue, Jul 24, 2018 at 9:01 AM, Vasundhara Volam
wrote:
> On Tue, Jul 24, 2018 at 1:01 PM, Michael Chan
> wrote:
>>
>> On Mon, Jul 23, 2018 at 10:24 PM, YueHaibing wrote:
>> > Based on the comments,req->l2addr must match the VF MAC address
>> > if firmware spec >= 1.2.2, mac_ok can be true.
On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> You can't apply "[patch v4] mm, oom: fix unnecessary killing of additional
> processes"
> because Michal's patch which removes oom_lock serialization was added to -mm
> tree.
>
I've rebased the patch to linux-next and posted a v5.
> You might worry
On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> You can't apply "[patch v4] mm, oom: fix unnecessary killing of additional
> processes"
> because Michal's patch which removes oom_lock serialization was added to -mm
> tree.
>
I've rebased the patch to linux-next and posted a v5.
> You might worry
The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
it cannot reap an mm. This can happen for a variety of reasons,
including:
- the inability to grab mm->mmap_sem in a sufficient amount of time,
- when the mm has blockable mmu notifiers that could cause the oom reaper
The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
it cannot reap an mm. This can happen for a variety of reasons,
including:
- the inability to grab mm->mmap_sem in a sufficient amount of time,
- when the mm has blockable mmu notifiers that could cause the oom reaper
Please did you recieve the email i sent you ?
Please did you recieve the email i sent you ?
On Tue, 24 Jul 2018 at 15:30, Mathieu Poirier
wrote:
>
> Good afternoon,
>
> On Thu, Jul 19, 2018 at 11:55:06AM +0100, Suzuki K Poulose wrote:
> > Refactor the of graph endpoint parsing code, to make the error
> > handling easier.
> >
> > Cc: Mathieu Poirier
> > Signed-off-by: Suzuki K Poulose
On Tue, 24 Jul 2018 at 15:30, Mathieu Poirier
wrote:
>
> Good afternoon,
>
> On Thu, Jul 19, 2018 at 11:55:06AM +0100, Suzuki K Poulose wrote:
> > Refactor the of graph endpoint parsing code, to make the error
> > handling easier.
> >
> > Cc: Mathieu Poirier
> > Signed-off-by: Suzuki K Poulose
On Tue, Jul 24, 2018 at 7:07 PM, kbuild test robot wrote:
> Hi Arnd,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on sof-driver-fuweitax/master]
> [also build test ERROR on v4.18-rc6 next-20180724]
> [if your patch is applied to the wrong git
On Tue, Jul 24, 2018 at 7:07 PM, kbuild test robot wrote:
> Hi Arnd,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on sof-driver-fuweitax/master]
> [also build test ERROR on v4.18-rc6 next-20180724]
> [if your patch is applied to the wrong git
Please did you recieve the email i sent you ?
Please did you recieve the email i sent you ?
Please did you recieve the email i sent you ?
Please did you recieve the email i sent you ?
On Tue, 24 Jul 2018 16:49:59 -0400
Steven Rostedt wrote:
> > Hmm it seems we should review the register_trigger() implementation.
> > It should return the return value of trace_event_trigger_enable_disable(),
> > shouldn't it?
> >
>
> Yeah, that's not done well. I'll fix it up.
>
> Thanks
Good afternoon,
On Thu, Jul 19, 2018 at 11:55:06AM +0100, Suzuki K Poulose wrote:
> Refactor the of graph endpoint parsing code, to make the error
> handling easier.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> Changes since v1:
> - Splitted from the of_node refcounting
On Tue, 24 Jul 2018 16:49:59 -0400
Steven Rostedt wrote:
> > Hmm it seems we should review the register_trigger() implementation.
> > It should return the return value of trace_event_trigger_enable_disable(),
> > shouldn't it?
> >
>
> Yeah, that's not done well. I'll fix it up.
>
> Thanks
Good afternoon,
On Thu, Jul 19, 2018 at 11:55:06AM +0100, Suzuki K Poulose wrote:
> Refactor the of graph endpoint parsing code, to make the error
> handling easier.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K Poulose
> ---
> Changes since v1:
> - Splitted from the of_node refcounting
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman
> wrote:
>>
>> + if (signal_pending(current)) {
>> + retval = restart_syscall();
>> + goto fork_out;
>> + }
>
> Oh, the previous version had this too, but it wasn't as obvious
>
Linus Torvalds writes:
> On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman
> wrote:
>>
>> + if (signal_pending(current)) {
>> + retval = restart_syscall();
>> + goto fork_out;
>> + }
>
> Oh, the previous version had this too, but it wasn't as obvious
>
On Mon 2018-07-23 14:50:50, Andy Lutomirski wrote:
>
>
> > On Jul 23, 2018, at 2:38 PM, Pavel Machek wrote:
> >
> >> On Mon 2018-07-23 12:00:08, Linus Torvalds wrote:
> >>> On Mon, Jul 23, 2018 at 7:09 AM Pavel Machek wrote:
> >>>
> >>> Meanwhile... it looks like gcc is not slowed down
On Mon 2018-07-23 14:50:50, Andy Lutomirski wrote:
>
>
> > On Jul 23, 2018, at 2:38 PM, Pavel Machek wrote:
> >
> >> On Mon 2018-07-23 12:00:08, Linus Torvalds wrote:
> >>> On Mon, Jul 23, 2018 at 7:09 AM Pavel Machek wrote:
> >>>
> >>> Meanwhile... it looks like gcc is not slowed down
On Tue, Jul 24, 2018 at 01:46:39PM -0700, Cannon Matthews wrote:
> Reimplement clear_gigantic_page() to clear gigabytes pages using the
> non-temporal streaming store instructions that bypass the cache
> (movnti), since an entire 1GiB region will not fit in the cache anyway.
>
> Doing an mlock()
On Tue, Jul 24, 2018 at 01:46:39PM -0700, Cannon Matthews wrote:
> Reimplement clear_gigantic_page() to clear gigabytes pages using the
> non-temporal streaming store instructions that bypass the cache
> (movnti), since an entire 1GiB region will not fit in the cache anyway.
>
> Doing an mlock()
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
I have a business Proposal that will be of benefit to the both of us.Kindly
contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
I would like to speak with the person that managing photos for your
company?
We provide image editing like – photos cutting out and retouching.
Enhancing your images is just a part of what we can do for your business.
Whether you’re an ecommerce
store or portrait photographer, real estate
On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman wrote:
>
> + if (signal_pending(current)) {
> + retval = restart_syscall();
> + goto fork_out;
> + }
Oh, the previous version had this too, but it wasn't as obvious
because it was just in a single line:
On Tue, Jul 24, 2018 at 1:40 PM Eric W. Biederman wrote:
>
> + if (signal_pending(current)) {
> + retval = restart_syscall();
> + goto fork_out;
> + }
Oh, the previous version had this too, but it wasn't as obvious
because it was just in a single line:
On Thu, 19 Jul 2018, Michal Hocko wrote:
> From: Michal Hocko
>
> oom_reaper used to rely on the oom_lock since e2fe14564d33 ("oom_reaper:
> close race with exiting task"). We do not really need the lock anymore
> though. 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run
>
On Thu, 19 Jul 2018, Michal Hocko wrote:
> From: Michal Hocko
>
> oom_reaper used to rely on the oom_lock since e2fe14564d33 ("oom_reaper:
> close race with exiting task"). We do not really need the lock anymore
> though. 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run
>
From: Sai Praneeth
Some future Intel processors may support "Enhanced IBRS" which is an
"always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and
never disabled. According to specification[1], this should simplify
software enabling and improve performance.
[With enhanced IBRS, the
From: Sai Praneeth
Some future Intel processors may support "Enhanced IBRS" which is an
"always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and
never disabled. According to specification[1], this should simplify
software enabling and improve performance.
[With enhanced IBRS, the
On Tue, 24 Jul 2018 13:46:39 -0700 Cannon Matthews
wrote:
> Reimplement clear_gigantic_page() to clear gigabytes pages using the
> non-temporal streaming store instructions that bypass the cache
> (movnti), since an entire 1GiB region will not fit in the cache anyway.
>
> ...
>
> Tested:
>
On Tue, 24 Jul 2018 13:46:39 -0700 Cannon Matthews
wrote:
> Reimplement clear_gigantic_page() to clear gigabytes pages using the
> non-temporal streaming store instructions that bypass the cache
> (movnti), since an entire 1GiB region will not fit in the cache anyway.
>
> ...
>
> Tested:
>
On Wed, 25 Jul 2018 00:09:09 +0900
Masami Hiramatsu wrote:
> Hmm, your patch seems to leak a memory since event_trigger_init() will
> be called twice on same trigger_data (Note that event_trigger_init()
> does not init ref counter, but increment it.) So we should decrement
> it when we find it
On Wed, 25 Jul 2018 00:09:09 +0900
Masami Hiramatsu wrote:
> Hmm, your patch seems to leak a memory since event_trigger_init() will
> be called twice on same trigger_data (Note that event_trigger_init()
> does not init ref counter, but increment it.) So we should decrement
> it when we find it
Hi Matthieu,
On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote:
> diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig
> index 1a354a6b6e87..35d82d96e781 100644
> --- a/sound/soc/jz4740/Kconfig
> +++ b/sound/soc/jz4740/Kconfig
> @@ -1,20 +1,20 @@
> config
Hi Matthieu,
On Wed, Jun 06, 2018 at 09:38:08PM +0200, Mathieu Malaterre wrote:
> diff --git a/sound/soc/jz4740/Kconfig b/sound/soc/jz4740/Kconfig
> index 1a354a6b6e87..35d82d96e781 100644
> --- a/sound/soc/jz4740/Kconfig
> +++ b/sound/soc/jz4740/Kconfig
> @@ -1,20 +1,20 @@
> config
From: Randy Dunlap
Add to fix build errors.
Both ctop.h and use u32 types and cause many
errors.
Examples:
../include/soc/nps/common.h:71:4: error: unknown type name 'u32'
u32 __reserved:20, cluster:4, core:4, thread:4;
../include/soc/nps/common.h:76:3: error: unknown type name 'u32'
From: Randy Dunlap
Fix printk format warning in arch/arc/plat-eznps/mtm.c:
In file included from ../include/linux/printk.h:7,
from ../include/linux/kernel.h:14,
from ../include/linux/list.h:9,
from ../include/linux/smp.h:12,
Reimplement clear_gigantic_page() to clear gigabytes pages using the
non-temporal streaming store instructions that bypass the cache
(movnti), since an entire 1GiB region will not fit in the cache anyway.
Doing an mlock() on a 512GiB 1G-hugetlb region previously would take on
average 134 seconds,
From: Randy Dunlap
Add to fix build errors.
Both ctop.h and use u32 types and cause many
errors.
Examples:
../include/soc/nps/common.h:71:4: error: unknown type name 'u32'
u32 __reserved:20, cluster:4, core:4, thread:4;
../include/soc/nps/common.h:76:3: error: unknown type name 'u32'
From: Randy Dunlap
Fix printk format warning in arch/arc/plat-eznps/mtm.c:
In file included from ../include/linux/printk.h:7,
from ../include/linux/kernel.h:14,
from ../include/linux/list.h:9,
from ../include/linux/smp.h:12,
Reimplement clear_gigantic_page() to clear gigabytes pages using the
non-temporal streaming store instructions that bypass the cache
(movnti), since an entire 1GiB region will not fit in the cache anyway.
Doing an mlock() on a 512GiB 1G-hugetlb region previously would take on
average 134 seconds,
Hi Mathieu,
On Wed, Jun 06, 2018 at 09:37:29PM +0200, Mathieu Malaterre wrote:
> Update the Ci20's defconfig to enable the JZ4780's SPI/GPIO driver.
>
> Signed-off-by: Mathieu Malaterre
> ---
> arch/mips/configs/ci20_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
Thanks - both patches
Hi Mathieu,
On Wed, Jun 06, 2018 at 09:37:29PM +0200, Mathieu Malaterre wrote:
> Update the Ci20's defconfig to enable the JZ4780's SPI/GPIO driver.
>
> Signed-off-by: Mathieu Malaterre
> ---
> arch/mips/configs/ci20_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
Thanks - both patches
On Sat, 21 Jul 2018 18:08:13 +0200
Nicholas Mc Guire wrote:
> wait_for_completion_timeout returns an unsigned long not int. declare a
> suitably type timeout and fix up assignment and check.
>
> Signed-off-by: Nicholas Mc Guire
> Reported-by: Vignesh R
> Fixes: 140623410536 ("mtd: spi-nor:
On Sat, 21 Jul 2018 18:08:13 +0200
Nicholas Mc Guire wrote:
> wait_for_completion_timeout returns an unsigned long not int. declare a
> suitably type timeout and fix up assignment and check.
>
> Signed-off-by: Nicholas Mc Guire
> Reported-by: Vignesh R
> Fixes: 140623410536 ("mtd: spi-nor:
On Mon, Jul 23, 2018 at 03:35:34PM -0700, Dmitry Torokhov wrote:
> On Fri, Jul 20, 2018 at 10:51:19PM +0100, Nick Dyer wrote:
> > From: Nick Dyer
> >
> > We use sscanf to parse the configuration file, so it's necessary to zero
> > terminate the configuration otherwise a truncated file can cause
On Mon, Jul 23, 2018 at 03:35:34PM -0700, Dmitry Torokhov wrote:
> On Fri, Jul 20, 2018 at 10:51:19PM +0100, Nick Dyer wrote:
> > From: Nick Dyer
> >
> > We use sscanf to parse the configuration file, so it's necessary to zero
> > terminate the configuration otherwise a truncated file can cause
On Tue, 24 Jul 2018 13:16:33 -0700 Linus Torvalds
wrote:
> On Tue, Jul 24, 2018 at 1:03 PM Andrew Morton
> wrote:
> >
> >
> > I'd sleep better if this became a kmem_cache_alloc() and the memset
> > was moved into vma_init().
>
> Yeah, with the vma_init(), I guess the advantage of using
>
On Tue, 24 Jul 2018 13:16:33 -0700 Linus Torvalds
wrote:
> On Tue, Jul 24, 2018 at 1:03 PM Andrew Morton
> wrote:
> >
> >
> > I'd sleep better if this became a kmem_cache_alloc() and the memset
> > was moved into vma_init().
>
> Yeah, with the vma_init(), I guess the advantage of using
>
In preparation for support of restoring pseudo-locked regions two
functions are exposed to all RDT code: closid_alloc() and
closid_allocated().
Signed-off-by: Reinette Chatre
---
arch/x86/kernel/cpu/intel_rdt.h | 2 ++
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 4 ++--
2 files changed,
In preparation for support of restoring pseudo-locked regions two
functions are exposed to all RDT code: closid_alloc() and
closid_allocated().
Signed-off-by: Reinette Chatre
---
arch/x86/kernel/cpu/intel_rdt.h | 2 ++
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 4 ++--
2 files changed,
Dear Maintainers,
A Cache Pseudo-Locked region is vulnerable to certain instructions (INVD,
WBINVD, CLFLUSH) or deeper C-states (that could shrink or power off the
cache) evicting the pseudo-locked memory. The current support for
pseudo-locked regions already restrict deeper C-states on cores
Expose a new debugfs file that user can use to trigger the restoration
of a specific Cache Pseudo-Locked region at any time.
Signed-off-by: Reinette Chatre
---
Documentation/x86/intel_rdt_ui.txt | 18 ++---
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 45 -
2
Memory that has been pseudo-locked to cache could be evicted if
an instruction like WBINVD has been used on a core in the cache
hierarchy. When this happens the region of cache would remained
orphaned.
Make it possible for pseudo-locked memory that may have been evicted
to be restored to its
Dear Maintainers,
A Cache Pseudo-Locked region is vulnerable to certain instructions (INVD,
WBINVD, CLFLUSH) or deeper C-states (that could shrink or power off the
cache) evicting the pseudo-locked memory. The current support for
pseudo-locked regions already restrict deeper C-states on cores
Expose a new debugfs file that user can use to trigger the restoration
of a specific Cache Pseudo-Locked region at any time.
Signed-off-by: Reinette Chatre
---
Documentation/x86/intel_rdt_ui.txt | 18 ++---
arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c | 45 -
2
Memory that has been pseudo-locked to cache could be evicted if
an instruction like WBINVD has been used on a core in the cache
hierarchy. When this happens the region of cache would remained
orphaned.
Make it possible for pseudo-locked memory that may have been evicted
to be restored to its
The wbinvd instruction would evict all pseudo-locked data from a
pseudo-locked region within the hierarchy where the wbinvd instruction
was run. The expectation is that a platform with pseudo-locked regions
should not run code depending on the wbinvd instruction after the
pseudo-locked regions are
An instruction like wbinvd would evict all data from pseudo-locked
regions within the cache hierarchy on which the instruction was run.
Add support for offloading the restoration of all pseudo-locked
regions since it is not possible to know which pseudo-locked regions
specifically are in need of
The wbinvd instruction would evict all pseudo-locked data from a
pseudo-locked region within the hierarchy where the wbinvd instruction
was run. The expectation is that a platform with pseudo-locked regions
should not run code depending on the wbinvd instruction after the
pseudo-locked regions are
An instruction like wbinvd would evict all data from pseudo-locked
regions within the cache hierarchy on which the instruction was run.
Add support for offloading the restoration of all pseudo-locked
regions since it is not possible to know which pseudo-locked regions
specifically are in need of
The nettel driver contains a few direct wbinvd invocations in the form:
__asm__ ("wbinvd")
Replace all of these calls with the kernel API "native_wbinvd()" that
translates to same as "asm volatile("wbinvd" : : : "memory")" and
provides a central location where calls to this destructive
The nettel driver contains a few direct wbinvd invocations in the form:
__asm__ ("wbinvd")
Replace all of these calls with the kernel API "native_wbinvd()" that
translates to same as "asm volatile("wbinvd" : : : "memory")" and
provides a central location where calls to this destructive
The i810 driver contains a direct wbinvd invocations in the form:
asm volatile ("wbinvd":::"memory")
Replace this call with the kernel API "native_wbinvd()" that
translates to same as "asm volatile("wbinvd" : : : "memory")" and
provides a central location where calls to this destructive
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before
The i810 driver contains a direct wbinvd invocations in the form:
asm volatile ("wbinvd":::"memory")
Replace this call with the kernel API "native_wbinvd()" that
translates to same as "asm volatile("wbinvd" : : : "memory")" and
provides a central location where calls to this destructive
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before
This commit fixes this sparse warning:
drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment
(different modifiers)
drivers/i2c/busses/i2c-aspeed.c:875:38:expected unsigned int (
*get_clk_reg_val )( ... )
drivers/i2c/busses/i2c-aspeed.c:875:38:got void const *const
This commit fixes this sparse warning:
drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment
(different modifiers)
drivers/i2c/busses/i2c-aspeed.c:875:38:expected unsigned int (
*get_clk_reg_val )( ... )
drivers/i2c/busses/i2c-aspeed.c:875:38:got void const *const
On Tue, 24 Jul 2018, Kirill A. Shutemov wrote:
> > use_zero_page is currently a simple thp flag, meaning it rejects writes
> > where val != !!val, so perhaps it would be best to overload it with
> > additional options? I can imagine 0x2 defining persistent allocation so
> > that the hzp is
On Tue, 24 Jul 2018, Kirill A. Shutemov wrote:
> > use_zero_page is currently a simple thp flag, meaning it rejects writes
> > where val != !!val, so perhaps it would be best to overload it with
> > additional options? I can imagine 0x2 defining persistent allocation so
> > that the hzp is
On Sat, Jun 23, 2018 at 10:35:01AM +0300, Yury Norov wrote:
> On top of next-20180622.
>
> bitmap_zero() is called after bitmap_alloc() in perf code. But
> bitmap_alloc() internally uses calloc() which guarantees that allocated
> area is zeroed. So following bitmap_zero is unneeded. Drop it.
>
>
On Sat, Jun 23, 2018 at 10:35:01AM +0300, Yury Norov wrote:
> On top of next-20180622.
>
> bitmap_zero() is called after bitmap_alloc() in perf code. But
> bitmap_alloc() internally uses calloc() which guarantees that allocated
> area is zeroed. So following bitmap_zero is unneeded. Drop it.
>
>
study it.
>
> ...
> Console: colour dummy device 80x30
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:180
> sched_clock_register+0x44/0x278
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc6-next-20180724
study it.
>
> ...
> Console: colour dummy device 80x30
> [ cut here ]
> WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:180
> sched_clock_register+0x44/0x278
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc6-next-20180724
On Tue, Jul 24, 2018 at 1:03 PM Andrew Morton wrote:
>
>
> I'd sleep better if this became a kmem_cache_alloc() and the memset
> was moved into vma_init().
Yeah, with the vma_init(), I guess the advantage of using
kmem_cache_zalloc() is pretty dubious.
Make it so.
Linus
On Tue, Jul 24, 2018 at 1:03 PM Andrew Morton wrote:
>
>
> I'd sleep better if this became a kmem_cache_alloc() and the memset
> was moved into vma_init().
Yeah, with the vma_init(), I guess the advantage of using
kmem_cache_zalloc() is pretty dubious.
Make it so.
Linus
On Tue, Jul 24, 2018 at 1:05 PM Eric W. Biederman wrote:
>
> What I hear you asking is moving up copy_signal copy_sighand copy_creds
> and alloc_pid, and anything else that signal delivery might depend on.
No, _just_ signal allocation.
It would still just use the special-case list to set the
On Tue, Jul 24, 2018 at 1:05 PM Eric W. Biederman wrote:
>
> What I hear you asking is moving up copy_signal copy_sighand copy_creds
> and alloc_pid, and anything else that signal delivery might depend on.
No, _just_ signal allocation.
It would still just use the special-case list to set the
On Wed, 25 Jul 2018 04:53:18 +0900
Minwoo Im wrote:
> Hi Alex,
>
> On Tue, 2018-07-24 at 10:14 -0600, Alex Williamson wrote:
> > The Samsung SM961/PM961 (960 EVO) sometimes fails to return from FLR
> > with the PCI config space reading back as -1. A reproducible instance
> > of this behavior
On Wed, 25 Jul 2018 04:53:18 +0900
Minwoo Im wrote:
> Hi Alex,
>
> On Tue, 2018-07-24 at 10:14 -0600, Alex Williamson wrote:
> > The Samsung SM961/PM961 (960 EVO) sometimes fails to return from FLR
> > with the PCI config space reading back as -1. A reproducible instance
> > of this behavior
301 - 400 of 1482 matches
Mail list logo
