* Eric W. Biederman wrote:
> tip-bot for Dave Hansen writes:
>
> > Commit-ID: aa37c51b9421d66f7931c5fdcb9ce80c450974be
> > Gitweb:
> > https://git.kernel.org/tip/aa37c51b9421d66f7931c5fdcb9ce80c450974be
> > Author: Dave Hansen
> > AuthorDate: Fri, 28 Sep 2018 09:02:23 -0700
> >
* Eric W. Biederman wrote:
> tip-bot for Dave Hansen writes:
>
> > Commit-ID: aa37c51b9421d66f7931c5fdcb9ce80c450974be
> > Gitweb:
> > https://git.kernel.org/tip/aa37c51b9421d66f7931c5fdcb9ce80c450974be
> > Author: Dave Hansen
> > AuthorDate: Fri, 28 Sep 2018 09:02:23 -0700
> >
On Thu, Oct 18, 2018 at 12:16:32PM +0100, Mel Gorman wrote:
> On Wed, Oct 17, 2018 at 10:59:04PM +0800, Aaron Lu wrote:
> > > Any particuular reason why? I assume it's related to the number of zone
> > > locks with the increase number of zones and the number of threads used
> > > for the test.
> >
On Thu, Oct 18, 2018 at 12:16:32PM +0100, Mel Gorman wrote:
> On Wed, Oct 17, 2018 at 10:59:04PM +0800, Aaron Lu wrote:
> > > Any particuular reason why? I assume it's related to the number of zone
> > > locks with the increase number of zones and the number of threads used
> > > for the test.
> >
Commit-ID: 485734f3fc77c1eb77ffe138c027b9a4bf0178f3
Gitweb: https://git.kernel.org/tip/485734f3fc77c1eb77ffe138c027b9a4bf0178f3
Author: Christoph Hellwig
AuthorDate: Sun, 14 Oct 2018 09:52:08 +0200
Committer: Ingo Molnar
CommitDate: Fri, 19 Oct 2018 07:49:32 +0200
x86/swiotlb: Enable
Commit-ID: 485734f3fc77c1eb77ffe138c027b9a4bf0178f3
Gitweb: https://git.kernel.org/tip/485734f3fc77c1eb77ffe138c027b9a4bf0178f3
Author: Christoph Hellwig
AuthorDate: Sun, 14 Oct 2018 09:52:08 +0200
Committer: Ingo Molnar
CommitDate: Fri, 19 Oct 2018 07:49:32 +0200
x86/swiotlb: Enable
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Tue, Oct 16, 2018 at 05:14:43PM -0700, Dmitry Torokhov wrote:
> synaptics_detect() does not check whether sending commands to the
> device succeeds and instead relies on getting unique data from the
> device. Let's make sure we seed entire buffer with zeroes to make sure
> we not use garbage on
On Tue, Oct 16, 2018 at 05:14:43PM -0700, Dmitry Torokhov wrote:
> synaptics_detect() does not check whether sending commands to the
> device succeeds and instead relies on getting unique data from the
> device. Let's make sure we seed entire buffer with zeroes to make sure
> we not use garbage on
WhiteEgret is an LSM to simply provide a whitelisting-type
execution control.
An execution-whitelist, simply called whitelist, is a list
of executable components (e.g., applications, libraries)
that are approved to run on a host. The whitelist is used
to decide whether executable components are
WhiteEgret is an LSM to simply provide a whitelisting-type
execution control.
An execution-whitelist, simply called whitelist, is a list
of executable components (e.g., applications, libraries)
that are approved to run on a host. The whitelist is used
to decide whether executable components are
A user application is required to use WhiteEgret.
This RFC provides a sample user application program.
Usage
sample-we-user
A user application is required to use WhiteEgret.
This RFC provides a sample user application program.
Usage
sample-we-user
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
This RFC provides implementation of WhiteEgret.
Signed-off-by: Shinya Takumi
---
security/Kconfig | 1 +
security/Makefile | 2 +
security/whiteegret/Kconfig| 82 +++
security/whiteegret/Makefile | 2 +
security/whiteegret/init.c
This RFC provides implementation of WhiteEgret.
Signed-off-by: Shinya Takumi
---
security/Kconfig | 1 +
security/Makefile | 2 +
security/whiteegret/Kconfig| 82 +++
security/whiteegret/Makefile | 2 +
security/whiteegret/init.c
>
> >
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong.
why 'just wrong' ?
> Do you know why it uses
> preempt_enable_no_resched()?
dont recall precisely.
we could be preemptable at the point where
>
> >
> > Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> > preempt_enable_no_resched().
>
> Alexei, I think this code is just wrong.
why 'just wrong' ?
> Do you know why it uses
> preempt_enable_no_resched()?
dont recall precisely.
we could be preemptable at the point where
Hi James,
On Thu, 18 Oct 2018 21:54:03 -0700 James Bottomley
wrote:
>
> It's the merge commit ... it was obviously the wrong choice; I'll fix
> it.
OK, thanks.
--
Cheers,
Stephen Rothwell
pgpS8HDlYzZFg.pgp
Description: OpenPGP digital signature
Hi James,
On Thu, 18 Oct 2018 21:54:03 -0700 James Bottomley
wrote:
>
> It's the merge commit ... it was obviously the wrong choice; I'll fix
> it.
OK, thanks.
--
Cheers,
Stephen Rothwell
pgpS8HDlYzZFg.pgp
Description: OpenPGP digital signature
Commit 4d3ebd3658d8 ("coreisght: tmc: Claim device before use") uses
CLAIM tag to validate if the device is available, it needs to pass
the device base address to access related registers.
In the function tmc_etb_disable_hw() it wrongly passes the driver data
pointer as register base address,
Commit 4d3ebd3658d8 ("coreisght: tmc: Claim device before use") uses
CLAIM tag to validate if the device is available, it needs to pass
the device base address to access related registers.
In the function tmc_etb_disable_hw() it wrongly passes the driver data
pointer as register base address,
On Fri, 2018-10-19 at 15:50 +1100, Stephen Rothwell wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function
> 'lpfc_debugfs_nodelist_open':
>
On Fri, 2018-10-19 at 15:50 +1100, Stephen Rothwell wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function
> 'lpfc_debugfs_nodelist_open':
>
On 10/18/18 6:47 PM, Andrew Morton wrote:
> On Thu, 18 Oct 2018 20:46:21 -0400 Andrea Arcangeli
> wrote:
>
>> On Thu, Oct 18, 2018 at 04:16:40PM -0700, Mike Kravetz wrote:
>>> I was not sure about this, and expected someone could come up with
>>> something better. It just seems there are
On 10/18/18 6:47 PM, Andrew Morton wrote:
> On Thu, 18 Oct 2018 20:46:21 -0400 Andrea Arcangeli
> wrote:
>
>> On Thu, Oct 18, 2018 at 04:16:40PM -0700, Mike Kravetz wrote:
>>> I was not sure about this, and expected someone could come up with
>>> something better. It just seems there are
Hi James,
After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_nodelist_open':
drivers/scsi/lpfc/lpfc_debugfs.c:706:17: warning: 'nrport' may be used
uninitialized in this function
Hi James,
After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_nodelist_open':
drivers/scsi/lpfc/lpfc_debugfs.c:706:17: warning: 'nrport' may be used
uninitialized in this function
On 10/17/2018 10:02 PM, Tomas Winkler wrote:
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index caa86b19c76d..f74f451baf6a 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -369,6 +369,7 @@ static int
On 10/17/2018 10:02 PM, Tomas Winkler wrote:
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index caa86b19c76d..f74f451baf6a 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -369,6 +369,7 @@ static int
at 9:29 PM, Andy Lutomirski wrote:
>> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>>
>> at 10:00 AM, Andy Lutomirski wrote:
>>
On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
at 8:51 PM, Andy Lutomirski wrote:
>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit
at 9:29 PM, Andy Lutomirski wrote:
>> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>>
>> at 10:00 AM, Andy Lutomirski wrote:
>>
On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
at 8:51 PM, Andy Lutomirski wrote:
>> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit
Hi Stefan,
I love your patch! Yet something to improve:
[auto build test ERROR on iio/togreg]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
Hi Stefan,
I love your patch! Yet something to improve:
[auto build test ERROR on iio/togreg]
[also build test ERROR on v4.19-rc8 next-20181018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>
> at 10:00 AM, Andy Lutomirski wrote:
>
>>
>>
>>> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>>>
>>> at 8:51 PM, Andy Lutomirski wrote:
>>>
> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
> at 6:22 PM, Andy Lutomirski wrote:
> On Oct 18, 2018, at 6:08 PM, Nadav Amit wrote:
>
> at 10:00 AM, Andy Lutomirski wrote:
>
>>
>>
>>> On Oct 18, 2018, at 9:47 AM, Nadav Amit wrote:
>>>
>>> at 8:51 PM, Andy Lutomirski wrote:
>>>
> On Wed, Oct 17, 2018 at 8:12 PM Nadav Amit wrote:
> at 6:22 PM, Andy Lutomirski wrote:
Currently seq_buf_puts() will happily create a non null-terminated
string for you in the buffer. This is particularly dangerous if the
buffer is on the stack.
For example:
char buf[8];
char secret = "secret";
struct seq_buf s;
seq_buf_init(, buf, sizeof(buf));
seq_buf_puts(, "foo");
Jann Horn points out that we're using unsigned int for len in
seq_buf_puts(), which could potentially overflow if we're passed a
UINT_MAX sized string.
The rest of the code already uses size_t, so we should also use that
in seq_buf_puts() to avoid any issues.
Suggested-by: Jann Horn
Currently seq_buf_puts() will happily create a non null-terminated
string for you in the buffer. This is particularly dangerous if the
buffer is on the stack.
For example:
char buf[8];
char secret = "secret";
struct seq_buf s;
seq_buf_init(, buf, sizeof(buf));
seq_buf_puts(, "foo");
Jann Horn points out that we're using unsigned int for len in
seq_buf_puts(), which could potentially overflow if we're passed a
UINT_MAX sized string.
The rest of the code already uses size_t, so we should also use that
in seq_buf_puts() to avoid any issues.
Suggested-by: Jann Horn
Jann Horn writes:
> On Wed, Oct 17, 2018 at 2:10 PM Michael Ellerman wrote:
>> Currently seq_buf_puts() will happily create a non NULL terminated
>> string for you in the buffer. This is particularly dangerous if the
>> buffer is on the stack.
>>
>> For example:
>>
>> char buf[8];
>> char
Jann Horn writes:
> On Wed, Oct 17, 2018 at 2:10 PM Michael Ellerman wrote:
>> Currently seq_buf_puts() will happily create a non NULL terminated
>> string for you in the buffer. This is particularly dangerous if the
>> buffer is on the stack.
>>
>> For example:
>>
>> char buf[8];
>> char
On Thu, Oct 18, 2018 at 09:17:06AM -0400, Steven Rostedt wrote:
> On Thu, 18 Oct 2018 10:51:18 +0530
> Sai Prakash Ranjan wrote:
>
> > > So something else is causing an issue besides just msm_read.
> > >
> > > Can you do an objdump -dr of the entire vmlinux binary and gzip it and
> > > post it
On Thu, Oct 18, 2018 at 09:17:06AM -0400, Steven Rostedt wrote:
> On Thu, 18 Oct 2018 10:51:18 +0530
> Sai Prakash Ranjan wrote:
>
> > > So something else is causing an issue besides just msm_read.
> > >
> > > Can you do an objdump -dr of the entire vmlinux binary and gzip it and
> > > post it
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
tools/include/uapi/linux/kvm.h
between commit:
25fe15e54fe5 ("tools headers uapi: Sync kvm.h copy")
from the tip tree and commit:
c939989d74e2 ("tools/headers: update kvm.h")
from the kvm tree.
I fixed it up (the
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
tools/include/uapi/linux/kvm.h
between commit:
25fe15e54fe5 ("tools headers uapi: Sync kvm.h copy")
from the tip tree and commit:
c939989d74e2 ("tools/headers: update kvm.h")
from the kvm tree.
I fixed it up (the
On 10/18/18 10:37, Wenwen Wang wrote:
> In coreboot_table_init(), a for loop is used to copy the entries of the
> coreboot table. For each entry, the header of the entry, which is a
> structure coreboot_table_entry and includes the size of the entry, is
> firstly copied from the IO region
On 10/18/18 10:37, Wenwen Wang wrote:
> In coreboot_table_init(), a for loop is used to copy the entries of the
> coreboot table. For each entry, the header of the entry, which is a
> structure coreboot_table_entry and includes the size of the entry, is
> firstly copied from the IO region
On Thu, Oct 18, 2018 at 11:42 PM Masahiro Yamada
wrote:
> Adding -Wshadow to KBUILD_HOSTCFLAGS emits another warning in Kconfig.
> Of course, it is easy to fix.
For v2, I already replaced '-Wshadow=local' for '-Wshadow' and fixed this
warning.
> But, I just started to think this option is a kind
On Thu, Oct 18, 2018 at 11:42 PM Masahiro Yamada
wrote:
> Adding -Wshadow to KBUILD_HOSTCFLAGS emits another warning in Kconfig.
> Of course, it is easy to fix.
For v2, I already replaced '-Wshadow=local' for '-Wshadow' and fixed this
warning.
> But, I just started to think this option is a kind
On Thu, Oct 18, 2018 at 11:04 AM Leonardo Bras wrote:
>
> Hello Helen,
>
> On Wed, Oct 17, 2018 at 12:06 AM Helen Koike wrote:
> >
> > Hi Leonardo,
> >
> > On 10/16/18 9:09 PM, Leonardo Brás wrote:
> > > Removes an unnecessary shadowed local variable (start).
> > > Optimize test of
On Thu, Oct 18, 2018 at 11:04 AM Leonardo Bras wrote:
>
> Hello Helen,
>
> On Wed, Oct 17, 2018 at 12:06 AM Helen Koike wrote:
> >
> > Hi Leonardo,
> >
> > On 10/16/18 9:09 PM, Leonardo Brás wrote:
> > > Removes an unnecessary shadowed local variable (start).
> > > Optimize test of
On Fri, Oct 19, 2018 at 1:53 AM Borislav Petkov wrote:
>
> On Fri, Oct 19, 2018 at 01:39:21AM +0900, Masahiro Yamada wrote:
> > It is not realistic to enable this warning option by default.
>
> I believe the question is whether to enable that warning by default in
> KBUILD_HOSTCFLAGS. Enabling it
On Fri, Oct 19, 2018 at 1:53 AM Borislav Petkov wrote:
>
> On Fri, Oct 19, 2018 at 01:39:21AM +0900, Masahiro Yamada wrote:
> > It is not realistic to enable this warning option by default.
>
> I believe the question is whether to enable that warning by default in
> KBUILD_HOSTCFLAGS. Enabling it
On 10/19/2018 07:29 AM, Naoya Horiguchi wrote:
> On Fri, Oct 12, 2018 at 09:29:56AM +0530, Anshuman Khandual wrote:
>> During huge page allocation it's migratability is checked to determine if
>> it should be placed under movable zones with GFP_HIGHUSER_MOVABLE. But the
>> movability aspect of
On 10/19/2018 07:29 AM, Naoya Horiguchi wrote:
> On Fri, Oct 12, 2018 at 09:29:56AM +0530, Anshuman Khandual wrote:
>> During huge page allocation it's migratability is checked to determine if
>> it should be placed under movable zones with GFP_HIGHUSER_MOVABLE. But the
>> movability aspect of
On 10/18/18 7:20 PM, Alexander Duyck wrote:
I see what you are talking about now. Actually I think this was an
existing issue before my patch even came into play. Basically the code
as it currently stands is device specific in terms of the attach and
release code.
I wonder if we shouldn't have
On 10/18/18 7:20 PM, Alexander Duyck wrote:
I see what you are talking about now. Actually I think this was an
existing issue before my patch even came into play. Basically the code
as it currently stands is device specific in terms of the attach and
release code.
I wonder if we shouldn't have
On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote:
>
> Constants of the *_ALL type can be actively harmful due to the fact that
> developers will usually fail to consider the possible effects of future
> changes to the definition.
>
> Remove STATX_ALL from the uapi, while no damage has been
On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote:
>
> Constants of the *_ALL type can be actively harmful due to the fact that
> developers will usually fail to consider the possible effects of future
> changes to the definition.
>
> Remove STATX_ALL from the uapi, while no damage has been
On Thu, Oct 18, 2018 at 1:15 PM Bart Van Assche wrote:
>
> On Thu, 2018-10-18 at 12:38 -0700, Alexander Duyck wrote:
> > Basically if somebody loads a driver the dev->driver becomes set. If a
> > driver is removed it will clear dev->driver and set driver_data to
> > 0/NULL. That is what I am
On Thu, Oct 18, 2018 at 1:15 PM Bart Van Assche wrote:
>
> On Thu, 2018-10-18 at 12:38 -0700, Alexander Duyck wrote:
> > Basically if somebody loads a driver the dev->driver becomes set. If a
> > driver is removed it will clear dev->driver and set driver_data to
> > 0/NULL. That is what I am
On Thu, Oct 18, 2018 at 09:31:35AM -0500, Rob Herring wrote:
> On Tue, 16 Oct 2018 10:58:37 +0800, Guo Ren wrote:
> > This patch adds the documentation to describe that how to add cpu nodes in
> > dts for SMP.
> >
> > Signed-off-by: Guo Ren
> > Cc: Rob Herring
> > ---
> > Changelog:
> > - Add
On Thu, Oct 18, 2018 at 09:31:35AM -0500, Rob Herring wrote:
> On Tue, 16 Oct 2018 10:58:37 +0800, Guo Ren wrote:
> > This patch adds the documentation to describe that how to add cpu nodes in
> > dts for SMP.
> >
> > Signed-off-by: Guo Ren
> > Cc: Rob Herring
> > ---
> > Changelog:
> > - Add
On Wed, 26 Sep 2018 16:22:27 +0200 Michal Hocko wrote:
> > MPOL_PREFERRED is handled by policy_node() before we call
> > __alloc_pages_nodemask.
> > __GFP_THISNODE is applied only when we are not using
> > __GFP_DIRECT_RECLAIM which is handled in alloc_hugepage_direct_gfpmask
> > now.
> >
On Wed, 26 Sep 2018 16:22:27 +0200 Michal Hocko wrote:
> > MPOL_PREFERRED is handled by policy_node() before we call
> > __alloc_pages_nodemask.
> > __GFP_THISNODE is applied only when we are not using
> > __GFP_DIRECT_RECLAIM which is handled in alloc_hugepage_direct_gfpmask
> > now.
> >
syzbot has found a reproducer for the following crash on:
HEAD commit:fa520c47eaa1 fscache: Fix out of bound read in long cookie..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130da8ee40
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:fa520c47eaa1 fscache: Fix out of bound read in long cookie..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=130da8ee40
kernel config:
On Tue, 28 Aug 2018 13:22:49 -0400 Johannes Weiner wrote:
> This version 4 of the PSI series incorporates feedback from Peter and
> fixes two races in the lockless aggregator that Suren found in his
> testing and which caused the sample calculation to sometimes underflow
> and record bogusly
On Tue, 28 Aug 2018 13:22:49 -0400 Johannes Weiner wrote:
> This version 4 of the PSI series incorporates feedback from Peter and
> fixes two races in the lockless aggregator that Suren found in his
> testing and which caused the sample calculation to sometimes underflow
> and record bogusly
When /tmp is mounted with noexec, mksyscalltbl fails.
[snip]
|perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl:
/tmp/create-table-6VGPSt: Permission denied
[snip]
Add variable TMPDIR as prefix dir of the temporary file, if it is set,
replace default /tmp
Remove extra slash from
When /tmp is mounted with noexec, mksyscalltbl fails.
[snip]
|perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl:
/tmp/create-table-6VGPSt: Permission denied
[snip]
Add variable TMPDIR as prefix dir of the temporary file, if it is set,
replace default /tmp
Remove extra slash from
On Fri, Oct 12, 2018 at 09:29:56AM +0530, Anshuman Khandual wrote:
> During huge page allocation it's migratability is checked to determine if
> it should be placed under movable zones with GFP_HIGHUSER_MOVABLE. But the
> movability aspect of the huge page could depend on other factors than just
>
On Wed, Oct 17, 2018 at 01:49:17PM +0530, Anshuman Khandual wrote:
>
>
> On 10/12/2018 09:29 AM, Anshuman Khandual wrote:
> > This patch series enables HugeTLB migration support for all supported
> > huge page sizes at all levels including contiguous bit implementation.
> > Following HugeTLB
On Fri, Oct 12, 2018 at 09:29:56AM +0530, Anshuman Khandual wrote:
> During huge page allocation it's migratability is checked to determine if
> it should be placed under movable zones with GFP_HIGHUSER_MOVABLE. But the
> movability aspect of the huge page could depend on other factors than just
>
On Wed, Oct 17, 2018 at 01:49:17PM +0530, Anshuman Khandual wrote:
>
>
> On 10/12/2018 09:29 AM, Anshuman Khandual wrote:
> > This patch series enables HugeTLB migration support for all supported
> > huge page sizes at all levels including contiguous bit implementation.
> > Following HugeTLB
On 19 October 2018 at 00:51, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 04:09:22PM +0800, Baolin Wang wrote:
>> Some battery driver will use the open circuit voltage (OCV) value to look
>> up the corresponding battery capacity percent in one certain degree Celsius.
>> Thus this patch provides
On 19 October 2018 at 00:51, Rob Herring wrote:
> On Mon, Oct 15, 2018 at 04:09:22PM +0800, Baolin Wang wrote:
>> Some battery driver will use the open circuit voltage (OCV) value to look
>> up the corresponding battery capacity percent in one certain degree Celsius.
>> Thus this patch provides
On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote:
>
> FUSE will want to know if stx_attributes is interesting or not, because
> there's a non-zero cost of retreiving it.
>
> This is more of a "want" flag, since stx_attributes_mask already indicates
> whether we "got" stx_attributes or not. So
On Oct 18, 2018, at 7:11 AM, Miklos Szeredi wrote:
>
> FUSE will want to know if stx_attributes is interesting or not, because
> there's a non-zero cost of retreiving it.
>
> This is more of a "want" flag, since stx_attributes_mask already indicates
> whether we "got" stx_attributes or not. So
On Thu, 18 Oct 2018 20:46:21 -0400 Andrea Arcangeli wrote:
> On Thu, Oct 18, 2018 at 04:16:40PM -0700, Mike Kravetz wrote:
> > I was not sure about this, and expected someone could come up with
> > something better. It just seems there are filesystems like huegtlbfs,
> > where it makes no sense
On Thu, 18 Oct 2018 20:46:21 -0400 Andrea Arcangeli wrote:
> On Thu, Oct 18, 2018 at 04:16:40PM -0700, Mike Kravetz wrote:
> > I was not sure about this, and expected someone could come up with
> > something better. It just seems there are filesystems like huegtlbfs,
> > where it makes no sense
Make the frequently used lockdep global variable debug_locks read-mostly.
As debug_locks_silent is sometime used together with debug_locks,
it is also made read-mostly so that they can be close together.
With false cacheline sharing, cacheline contention problem can happen
depending on what get
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For instance, parallel kernel build time on a 4-socket x86-64
server nearly doubled.
Make the frequently used lockdep global variable debug_locks read-mostly.
As debug_locks_silent is sometime used together with debug_locks,
it is also made read-mostly so that they can be close together.
With false cacheline sharing, cacheline contention problem can happen
depending on what get
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For instance, parallel kernel build time on a 4-socket x86-64
server nearly doubled.
> On Oct 18, 2018, at 7:15 AM, Florian Weimer wrote:
>
> * Miklos Szeredi:
>
>> #define STATX__RESERVED 0x8000U /* Reserved for future
>> struct statx expansion */
>
> What about this? Isn't it similar to STATX_ALL in the sense that we
> don't know yet what it will
> On Oct 18, 2018, at 7:15 AM, Florian Weimer wrote:
>
> * Miklos Szeredi:
>
>> #define STATX__RESERVED 0x8000U /* Reserved for future
>> struct statx expansion */
>
> What about this? Isn't it similar to STATX_ALL in the sense that we
> don't know yet what it will
On Thu, Oct 18, 2018 at 07:54:29PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.135 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 18, 2018 at 07:54:15PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.78 release.
> There are 41 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 18, 2018 at 07:54:15PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.78 release.
> There are 41 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 18, 2018 at 07:54:29PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.135 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 18, 2018 at 07:54:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.162 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Oct 18, 2018 at 07:54:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.162 release.
> There are 48 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Oct 12, 2018 at 07:03:41PM -0400, Len Brown wrote:
> > Why would the cpu topology report 0 cpus? I added a debug entry to
> > cpu_usage_stat and /proc/stat showed it as an extra column. Then
> > fscanf parsing in for_all_cpus() failed, causing the SIGFPE.
> >
> > This is not an issue.
On Fri, Oct 12, 2018 at 07:03:41PM -0400, Len Brown wrote:
> > Why would the cpu topology report 0 cpus? I added a debug entry to
> > cpu_usage_stat and /proc/stat showed it as an extra column. Then
> > fscanf parsing in for_all_cpus() failed, causing the SIGFPE.
> >
> > This is not an issue.
On Tue, Oct 16, 2018 at 3:36 PM Heiko Carstens
wrote:
>
> On Tue, Oct 16, 2018 at 02:29:28PM +0800, Pingfan Liu wrote:
> > > I think it is caused by the uinon page->lru and page->next. It can be
> > > fixed by:
> > > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > > index
On Tue, Oct 16, 2018 at 3:36 PM Heiko Carstens
wrote:
>
> On Tue, Oct 16, 2018 at 02:29:28PM +0800, Pingfan Liu wrote:
> > > I think it is caused by the uinon page->lru and page->next. It can be
> > > fixed by:
> > > diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> > > index
1 - 100 of 1550 matches
Mail list logo
