On 5/31/2018 2:28 AM, CHANDAN VN wrote:
> From: "sireesha.t"
>
> Leak is caused because smack_inode_getsecurity() is allocating memory
> using kstrdup(). Though the security_release_secctx() is called, it
> would not free the allocated memory. Calling security_release_secctx is
> not relevant for
Quoting Codrin Ciubotariu (2018-05-25 05:34:23)
> This driver is a simple muxing driver that controls the
> I2S's clock input by using syscon/regmap to change the parrent.
s/parrent/parent/
> The available inputs can be Peripheral clock and Generated clock.
Why capitalize peripheral and
Add S900 clk entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 48bfffe..964cd28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1143,12 +1143,14 @@ N: owl
F:
Add S900 clk entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 48bfffe..964cd28 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1143,12 +1143,14 @@ N: owl
F:
On Thu, 2018-05-31 at 12:16 -0300, Thadeu Lima de Souza Cascardo wrote:
> On Thu, May 31, 2018 at 08:15:45AM -0700, Joe Perches wrote:
> > On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > []
> > > @@
On Thu, 2018-05-31 at 12:16 -0300, Thadeu Lima de Souza Cascardo wrote:
> On Thu, May 31, 2018 at 08:15:45AM -0700, Joe Perches wrote:
> > On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > []
> > > @@
Quoting Linus Torvalds (2018-05-31 07:32:10)
> On Thu, May 31, 2018 at 5:05 AM Petr Mladek wrote:
> >
> > Anyway, we need to fix or remove this format. vsprintf-like functions
> > are called in any context and nobody expect that they might sleep.
>
> Ack. I guess the argument is that "%pCr" is
Quoting Linus Torvalds (2018-05-31 07:32:10)
> On Thu, May 31, 2018 at 5:05 AM Petr Mladek wrote:
> >
> > Anyway, we need to fix or remove this format. vsprintf-like functions
> > are called in any context and nobody expect that they might sleep.
>
> Ack. I guess the argument is that "%pCr" is
On Thu, May 31, 2018 at 08:15:45AM -0700, Joe Perches wrote:
> On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> []
> > @@ -4788,7 +4788,7 @@ ftrace_set_addr(struct ftrace_ops *ops, unsigned long
> > ip, int
On Thu, May 31, 2018 at 08:15:45AM -0700, Joe Perches wrote:
> On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> []
> > @@ -4788,7 +4788,7 @@ ftrace_set_addr(struct ftrace_ops *ops, unsigned long
> > ip, int
On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
[]
> @@ -4788,7 +4788,7 @@ ftrace_set_addr(struct ftrace_ops *ops, unsigned long
> ip, int remove,
> * @reset - non zero to reset all filters before applying this
On Thu, 2018-05-31 at 09:17 -0300, Thadeu Lima de Souza Cascardo wrote:
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
[]
> @@ -4788,7 +4788,7 @@ ftrace_set_addr(struct ftrace_ops *ops, unsigned long
> ip, int remove,
> * @reset - non zero to reset all filters before applying this
On Thu, 2018-05-31 at 14:16 +0200, Petr Mladek wrote:
> On Thu 2018-05-31 15:47:51, Maninder Singh wrote:
> > This patch removes unused flag LOG_NOCONS for printk.
> > usage of this flag is removed long back with below commit.
>
> Make sense.
>
> > "5c2992ee7fd8a29d04125dc0aa3522784c5fa5eb"
> >
On Thu, 2018-05-31 at 14:16 +0200, Petr Mladek wrote:
> On Thu 2018-05-31 15:47:51, Maninder Singh wrote:
> > This patch removes unused flag LOG_NOCONS for printk.
> > usage of this flag is removed long back with below commit.
>
> Make sense.
>
> > "5c2992ee7fd8a29d04125dc0aa3522784c5fa5eb"
> >
Quoting Matti Vaittinen (2018-05-30 01:43:19)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 41492e980ef4..4b045699bb5e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
> ---help---
> Support for
Quoting Matti Vaittinen (2018-05-30 01:43:19)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 41492e980ef4..4b045699bb5e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
> ---help---
> Support for
On 5/31/18 7:12 AM, Greg Kroah-Hartman wrote:
Why is it somehow ok for "future" kernels? You can't break the api in
the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it
needs to be reverted.
This was discussed here:
On 5/31/18 7:12 AM, Greg Kroah-Hartman wrote:
Why is it somehow ok for "future" kernels? You can't break the api in
the future for no reason.
So this needs to be the same everywhere. If it is broken in 4.17-rc, it
needs to be reverted.
This was discussed here:
PCIe downtraining happens when both the device and PCIe port are
capable of a larger bus width or higher speed than negotiated.
Downtraining might be indicative of other problems in the system, and
identifying this from userspace is neither intuitive, nor straigh
forward.
Instead, check for such
PCIe downtraining happens when both the device and PCIe port are
capable of a larger bus width or higher speed than negotiated.
Downtraining might be indicative of other problems in the system, and
identifying this from userspace is neither intuitive, nor straigh
forward.
Instead, check for such
On Thu, 2018-05-31 at 19:11 +0800, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
> Reviewed-by: Mimi Zohar
> Reviewed-by: Andy Shevchenko
> Cc: Mimi Zohar
> Cc: Dmitry Kasatkin
> Cc: James Morris
On Thu, 2018-05-31 at 19:11 +0800, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
> Reviewed-by: Mimi Zohar
> Reviewed-by: Andy Shevchenko
> Cc: Mimi Zohar
> Cc: Dmitry Kasatkin
> Cc: James Morris
On 5/31/18 8:22 AM, Jens Axboe wrote:
> On 5/31/18 8:20 AM, Jens Axboe wrote:
>> On 5/31/18 6:10 AM, Mike Snitzer wrote:
>>> On Thu, May 31 2018 at 12:35am -0400,
>>> Jens Axboe wrote:
>>>
On May 30, 2018, at 10:23 PM, Stephen Rothwell
wrote:
>
> Hi all,
>
> After
On 5/31/18 8:22 AM, Jens Axboe wrote:
> On 5/31/18 8:20 AM, Jens Axboe wrote:
>> On 5/31/18 6:10 AM, Mike Snitzer wrote:
>>> On Thu, May 31 2018 at 12:35am -0400,
>>> Jens Axboe wrote:
>>>
On May 30, 2018, at 10:23 PM, Stephen Rothwell
wrote:
>
> Hi all,
>
> After
From: Jeff Layton
Add a test for new syncfs error reporting behavior. When an inode fails
to be written back, ensure that we report an error to a subsequent call
to syncfs().
Because we don't want to grow struct file in order to support this, we
only do this if the file was opened with O_PATH
From: Jeff Layton
Add a test for new syncfs error reporting behavior. When an inode fails
to be written back, ensure that we report an error to a subsequent call
to syncfs().
Because we don't want to grow struct file in order to support this, we
only do this if the file was opened with O_PATH
On Wed, May 30, 2018 at 2:42 AM Michal Hocko wrote:
>
> That being sad, if you believe that silently fixing up a code like that
> is a good idea we can do the following of course:
Ack.
Except for:
> Linus argues that this just motivates people to do even
> more hacks like
> if (gfp ==
On Wed, May 30, 2018 at 2:42 AM Michal Hocko wrote:
>
> That being sad, if you believe that silently fixing up a code like that
> is a good idea we can do the following of course:
Ack.
Except for:
> Linus argues that this just motivates people to do even
> more hacks like
> if (gfp ==
On Sun, 2018-05-27 at 23:15 +0100, Colin King wrote:
> From: Colin Ian King
>
> The allocation of 'temp' is not kfree'd and hence there is a memory
> leak on each call of evm_read_xattrs. Fix this by kfree'ing it
> after copying data from it back to the user space buffer 'buf'.
>
> Detected by
On Sun, 2018-05-27 at 23:15 +0100, Colin King wrote:
> From: Colin Ian King
>
> The allocation of 'temp' is not kfree'd and hence there is a memory
> leak on each call of evm_read_xattrs. Fix this by kfree'ing it
> after copying data from it back to the user space buffer 'buf'.
>
> Detected by
Quoting Rob Herring (2018-05-31 07:07:24)
> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
> wrote:
> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
> >> Hello Rob,
> >>
> >> Thanks for the review!
> >>
> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
> >> >
Quoting Rob Herring (2018-05-31 07:07:24)
> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
> wrote:
> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
> >> Hello Rob,
> >>
> >> Thanks for the review!
> >>
> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
> >> >
As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
version which can acquire filters is useful. There are at least two reasons
this is preferable, even though it uses ptrace:
1. You can control tasks that aren't cooperating with you
2. You can control tasks whose filters
As an alternative to SECCOMP_FILTER_FLAG_GET_LISTENER, perhaps a ptrace()
version which can acquire filters is useful. There are at least two reasons
this is preferable, even though it uses ptrace:
1. You can control tasks that aren't cooperating with you
2. You can control tasks whose filters
This patch introduces a means for syscalls matched in seccomp to notify
some other task that a particular filter has been triggered.
The motivation for this is primarily for use with containers. For example,
if a container does an init_module(), we obviously don't want to load this
untrusted
This patch introduces a means for syscalls matched in seccomp to notify
some other task that a particular filter has been triggered.
The motivation for this is primarily for use with containers. For example,
if a container does an init_module(), we obviously don't want to load this
untrusted
Hi Lowry,
Small drive-by suggestion. Haven't checked if others have pointed it
out previously :-\
On 30 May 2018 at 12:23, Lowry Li wrote:
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported
Hi Lowry,
Small drive-by suggestion. Haven't checked if others have pointed it
out previously :-\
On 30 May 2018 at 12:23, Lowry Li wrote:
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported
The idea here is that the userspace handler should be able to pass an fd
back to the trapped task, for example so it can be returned from socket().
I've proposed one API here, but I'm open to other options. In particular,
this only lets you return an fd from a syscall, which may not be enough in
The idea here is that the userspace handler should be able to pass an fd
back to the trapped task, for example so it can be returned from socket().
I've proposed one API here, but I'm open to other options. In particular,
this only lets you return an fd from a syscall, which may not be enough in
In the next commit we'll use this same mnemonic to get a listener for the
nth filter, so we need it available outside of CHECKPOINT_RESTORE. This is
slightly looser than necessary, because it really could be
CHECKPOINT_RESTORE || USER_NOTIFICATION, but it's declared static and this
complicates the
In the next commit we'll use this same mnemonic to get a listener for the
nth filter, so we need it available outside of CHECKPOINT_RESTORE. This is
slightly looser than necessary, because it really could be
CHECKPOINT_RESTORE || USER_NOTIFICATION, but it's declared static and this
complicates the
> Il giorno 31 mag 2018, alle ore 16:48, Jens Axboe ha
> scritto:
>
> On 5/31/18 7:23 AM, Paolo Valente wrote:
>> Hi Jens,
>> this series fixes three bugs in bfq_requests_merged. In more detail:
>>
>> - two linked bugs, with the first (critical: wrong lock) hidden by the
>> second (less
> Il giorno 31 mag 2018, alle ore 16:48, Jens Axboe ha
> scritto:
>
> On 5/31/18 7:23 AM, Paolo Valente wrote:
>> Hi Jens,
>> this series fixes three bugs in bfq_requests_merged. In more detail:
>>
>> - two linked bugs, with the first (critical: wrong lock) hidden by the
>> second (less
Hi all,
Here's a v3 of the seccomp trap to userspace, with all the nits from v2
fixed. Open questions from v2 are still:
1. is it ok not to use netlink?
2. what should the fd passing API look like? (see patch notes on this
one for details of why the current one might (?) be a problem)
As an
Hi all,
Here's a v3 of the seccomp trap to userspace, with all the nits from v2
fixed. Open questions from v2 are still:
1. is it ok not to use netlink?
2. what should the fd passing API look like? (see patch notes on this
one for details of why the current one might (?) be a problem)
As an
Hi Dan,
On 31 May 2018 07:24 Dan Carpenter wrote:
> Smatch flags a couple bugs here:
>
> drivers/gpio/gpio-dwapb.c:447 dwapb_configure_irqs() warn: always true
> condition '(pp->irq[i] >= 0) => (0-u32max >= 0)'
> drivers/gpio/gpio-dwapb.c:627 dwapb_gpio_get_pdata() warn: always true
> condition
Hi Dan,
On 31 May 2018 07:24 Dan Carpenter wrote:
> Smatch flags a couple bugs here:
>
> drivers/gpio/gpio-dwapb.c:447 dwapb_configure_irqs() warn: always true
> condition '(pp->irq[i] >= 0) => (0-u32max >= 0)'
> drivers/gpio/gpio-dwapb.c:627 dwapb_gpio_get_pdata() warn: always true
> condition
On Thu, May 31, 2018 at 04:19:14PM +0300, Andy Shevchenko wrote:
> The nbits == 0 is safe to be supplied to the function body, so,
> remove unnecessary checks in bitmap_to_arr32() and bitmap_from_arr32().
>
> Signed-off-by: Andy Shevchenko
Indeed. Thanks for the catch.
> ---
> lib/bitmap.c |
On Thu, May 31, 2018 at 04:19:14PM +0300, Andy Shevchenko wrote:
> The nbits == 0 is safe to be supplied to the function body, so,
> remove unnecessary checks in bitmap_to_arr32() and bitmap_from_arr32().
>
> Signed-off-by: Andy Shevchenko
Indeed. Thanks for the catch.
> ---
> lib/bitmap.c |
From: Davide Sapienza
The maximum possible duration of the weight-raising period for
interactive applications is limited to 13 seconds, as this is the time
needed to load the largest application that we considered when tuning
weight raising. Unfortunately, in such an evaluation, we did not
BFQ computes the duration of weight raising for interactive
applications automatically, using some reference parameters. In
particular, BFQ uses the best durations (see comments in the code for
how these durations have been assessed) for two classes of systems:
slow and fast ones. Examples of slow
From: Davide Sapienza
The maximum possible duration of the weight-raising period for
interactive applications is limited to 13 seconds, as this is the time
needed to load the largest application that we considered when tuning
weight raising. Unfortunately, in such an evaluation, we did not
BFQ computes the duration of weight raising for interactive
applications automatically, using some reference parameters. In
particular, BFQ uses the best durations (see comments in the code for
how these durations have been assessed) for two classes of systems:
slow and fast ones. Examples of slow
On Tue, May 29, 2018 at 4:04 PM, Eric W. Biederman
wrote:
>
> Now that the fuse and the vfs work is complete. Allow the fuse filesystem
> to be mounted by the root user in a user namespace.
Thanks, pushed to for-next branch of the fuse tree toghether with the xattr fix.
Miklos
On Tue, May 29, 2018 at 4:04 PM, Eric W. Biederman
wrote:
>
> Now that the fuse and the vfs work is complete. Allow the fuse filesystem
> to be mounted by the root user in a user namespace.
Thanks, pushed to for-next branch of the fuse tree toghether with the xattr fix.
Miklos
On Wed, May 30, 2018 at 10:27 PM, wrote:
> From: Levin Du
>
> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
> mute control, can also be used for general purpose. It is manipulated by
> the GRF_SOC_CON10 register.
>
> Signed-off-by: Levin Du
>
> ---
>
> Changes in v3:
On Wed, May 30, 2018 at 10:27 PM, wrote:
> From: Levin Du
>
> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
> mute control, can also be used for general purpose. It is manipulated by
> the GRF_SOC_CON10 register.
>
> Signed-off-by: Levin Du
>
> ---
>
> Changes in v3:
On Thu, May 31, 2018 at 08:55:10AM -0500, Rob Herring wrote:
> On Thu, May 31, 2018 at 3:22 AM, Johan Hovold wrote:
> > On Wed, May 30, 2018 at 10:58:05PM -0500, Rob Herring wrote:
> >> On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
> >> > Add binding for u-blox GNSS receivers.
>
On Thu, May 31, 2018 at 08:55:10AM -0500, Rob Herring wrote:
> On Thu, May 31, 2018 at 3:22 AM, Johan Hovold wrote:
> > On Wed, May 30, 2018 at 10:58:05PM -0500, Rob Herring wrote:
> >> On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
> >> > Add binding for u-blox GNSS receivers.
>
On Thu, May 31, 2018 at 5:05 AM Petr Mladek wrote:
>
> Anyway, we need to fix or remove this format. vsprintf-like functions
> are called in any context and nobody expect that they might sleep.
Ack. I guess the argument is that "%pCr" is rare, and none of *those*
users may care, but I do think
On Thu, May 31, 2018 at 5:05 AM Petr Mladek wrote:
>
> Anyway, we need to fix or remove this format. vsprintf-like functions
> are called in any context and nobody expect that they might sleep.
Ack. I guess the argument is that "%pCr" is rare, and none of *those*
users may care, but I do think
On Thu, 31 May 2018, Matthew Wilcox wrote:
> > Freeing a page in the page allocator also was traditionally not sleeping.
> > That has changed?
>
> No. "Your bug" being "The bug in your static analysis tool". It probably
> isn't following the data flow correctly (or deeply enough).
Well ok this
On Thu, 31 May 2018, Matthew Wilcox wrote:
> > Freeing a page in the page allocator also was traditionally not sleeping.
> > That has changed?
>
> No. "Your bug" being "The bug in your static analysis tool". It probably
> isn't following the data flow correctly (or deeply enough).
Well ok this
On Sat, Apr 28, 2018 at 4:29 AM, Tetsuo Handa
wrote:
> From 9f41081f8bd6762a6f629e5e23e6d07a62bba69c Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 28 Apr 2018 11:24:09 +0900
> Subject: [PATCH] fuse: don't keep inode-less dentry at fuse_ctl_add_dentry().
>
> syzbot is reporting NULL
On Sat, Apr 28, 2018 at 4:29 AM, Tetsuo Handa
wrote:
> From 9f41081f8bd6762a6f629e5e23e6d07a62bba69c Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 28 Apr 2018 11:24:09 +0900
> Subject: [PATCH] fuse: don't keep inode-less dentry at fuse_ctl_add_dentry().
>
> syzbot is reporting NULL
On Wed, 30 May 2018, Paul E. McKenney wrote:
> On Wed, May 30, 2018 at 05:01:01PM -0500, Linus Torvalds wrote:
> > On Wed, May 30, 2018 at 2:08 PM Alan Stern
> > wrote:
> > >
> > > Indeed. The very first line Linus quoted in his first reply to me
> > > (elided above) was:
> > >
> > >
On Wed, 30 May 2018, Paul E. McKenney wrote:
> On Wed, May 30, 2018 at 05:01:01PM -0500, Linus Torvalds wrote:
> > On Wed, May 30, 2018 at 2:08 PM Alan Stern
> > wrote:
> > >
> > > Indeed. The very first line Linus quoted in his first reply to me
> > > (elided above) was:
> > >
> > >
On 5/31/18 8:20 AM, Jens Axboe wrote:
> On 5/31/18 6:10 AM, Mike Snitzer wrote:
>> On Thu, May 31 2018 at 12:35am -0400,
>> Jens Axboe wrote:
>>
>>> On May 30, 2018, at 10:23 PM, Stephen Rothwell
>>> wrote:
Hi all,
After merging the device-mapper tree, today's linux-next
On 5/31/18 8:20 AM, Jens Axboe wrote:
> On 5/31/18 6:10 AM, Mike Snitzer wrote:
>> On Thu, May 31 2018 at 12:35am -0400,
>> Jens Axboe wrote:
>>
>>> On May 30, 2018, at 10:23 PM, Stephen Rothwell
>>> wrote:
Hi all,
After merging the device-mapper tree, today's linux-next
On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the
On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the
On Wed 2018-05-30 19:00:37, Sergey Senozhatsky wrote:
> On (05/30/18 18:55), Sergey Senozhatsky wrote:
> > The thing is, we, in fact, already invoke panic() in printk_safe mode.
> > Sometimes.
> >
> > Namely,
> >
> > nmi_panic() -> panic()
> >
> > is invoked while we are in printk_nmi(), so
On Wed 2018-05-30 19:00:37, Sergey Senozhatsky wrote:
> On (05/30/18 18:55), Sergey Senozhatsky wrote:
> > The thing is, we, in fact, already invoke panic() in printk_safe mode.
> > Sometimes.
> >
> > Namely,
> >
> > nmi_panic() -> panic()
> >
> > is invoked while we are in printk_nmi(), so
On 5/31/18 6:10 AM, Mike Snitzer wrote:
> On Thu, May 31 2018 at 12:35am -0400,
> Jens Axboe wrote:
>
>> On May 30, 2018, at 10:23 PM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> After merging the device-mapper tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
On 5/31/18 6:10 AM, Mike Snitzer wrote:
> On Thu, May 31 2018 at 12:35am -0400,
> Jens Axboe wrote:
>
>> On May 30, 2018, at 10:23 PM, Stephen Rothwell wrote:
>>>
>>> Hi all,
>>>
>>> After merging the device-mapper tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
On 05/30/2018 04:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2018-05-30 at 10:47 -0500, Eddie James wrote:
+ if (!list_empty(>ports)) {
My gosh, this is done already in list_for_each*()
No, list_for_each_entry does NOT check if the list is empty or if the
first entry is NULL.
NULL
On 05/30/2018 04:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2018-05-30 at 10:47 -0500, Eddie James wrote:
+ if (!list_empty(>ports)) {
My gosh, this is done already in list_for_each*()
No, list_for_each_entry does NOT check if the list is empty or if the
first entry is NULL.
NULL
* Geert Uytterhoeven [180531 06:45]:
> Yes, they should all be drivers.
>
> Assuming clocksources, clockevents, or primary interrupt controllers are
> special, and thus forcing everyone to use OF_DECLARE for the whole
> subsystem, doesn't fly everywhere.
>
> Clockevents and interrupt
* Geert Uytterhoeven [180531 06:45]:
> Yes, they should all be drivers.
>
> Assuming clocksources, clockevents, or primary interrupt controllers are
> special, and thus forcing everyone to use OF_DECLARE for the whole
> subsystem, doesn't fly everywhere.
>
> Clockevents and interrupt
On Thu, May 31, 2018 at 02:12:00PM +, Christopher Lameter wrote:
> On Thu, 31 May 2018, Matthew Wilcox wrote:
>
> > On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> > > I write a static analysis tool (DSAC), and it finds that kfree() can
> > > sleep.
> > >
> > > Here is the call
On Thu, May 31, 2018 at 02:12:00PM +, Christopher Lameter wrote:
> On Thu, 31 May 2018, Matthew Wilcox wrote:
>
> > On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> > > I write a static analysis tool (DSAC), and it finds that kfree() can
> > > sleep.
> > >
> > > Here is the call
On Thu, 31 May 2018, Matthew Wilcox wrote:
> On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> > I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
> >
> > Here is the call path for kfree().
> > Please look at it *from the bottom up*.
> >
> > [FUNC]
On Thu, 31 May 2018, Matthew Wilcox wrote:
> On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> > I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
> >
> > Here is the call path for kfree().
> > Please look at it *from the bottom up*.
> >
> > [FUNC]
On Thu, 31 May 2018, Jia-Ju Bai wrote:
> I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
> Here is the call path for kfree().
> Please look at it *from the bottom up*.
>
> [FUNC] alloc_pages(GFP_KERNEL)
> arch/x86/mm/pageattr.c, 756:
On Thu, 31 May 2018, Jia-Ju Bai wrote:
> I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
That should not happen.
> Here is the call path for kfree().
> Please look at it *from the bottom up*.
>
> [FUNC] alloc_pages(GFP_KERNEL)
> arch/x86/mm/pageattr.c, 756:
Enable complex event names containing [.:=,] symbols to be encoded into Perf
trace using name= modifier e.g. like this:
perf record -e
cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\
period=0x3567e0,event=0x3c,cmask=0x1/Duk ./futex
Below is how
Enable complex event names containing [.:=,] symbols to be encoded into Perf
trace using name= modifier e.g. like this:
perf record -e
cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\
period=0x3567e0,event=0x3c,cmask=0x1/Duk ./futex
Below is how
On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
>
> Here is the call path for kfree().
> Please look at it *from the bottom up*.
>
> [FUNC] alloc_pages(GFP_KERNEL)
> arch/x86/mm/pageattr.c, 756: alloc_pages
On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
wrote:
> On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> Hello Rob,
>>
>> Thanks for the review!
>>
>> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen
On Thu, May 31, 2018 at 09:10:07PM +0800, Jia-Ju Bai wrote:
> I write a static analysis tool (DSAC), and it finds that kfree() can sleep.
>
> Here is the call path for kfree().
> Please look at it *from the bottom up*.
>
> [FUNC] alloc_pages(GFP_KERNEL)
> arch/x86/mm/pageattr.c, 756: alloc_pages
On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
wrote:
> On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> Hello Rob,
>>
>> Thanks for the review!
>>
>> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen
On Wed 2018-05-30 16:03:50, Sergey Senozhatsky wrote:
> Drop the in_nmi() check from printk_safe_flush_on_panic()
> and attempt to re-init (IOW unlock) locked logbuf spinlock
> from panic CPU regardless of its context. Otherwise,
> theoretically, we can deadlock on logbuf trying to flush
> per-CPU
On Wed 2018-05-30 16:03:50, Sergey Senozhatsky wrote:
> Drop the in_nmi() check from printk_safe_flush_on_panic()
> and attempt to re-init (IOW unlock) locked logbuf spinlock
> from panic CPU regardless of its context. Otherwise,
> theoretically, we can deadlock on logbuf trying to flush
> per-CPU
The si544 driver had a rounding problem that using the result of clk_round_rate
may set the clock to yet another rate, for example:
clk_round_rate(19500) = 19499
clk_round_rate(19499) = 19498
Clients would expect that after clk_set_rate(clk, freq2=clk_round_rate(clk,
freq)) the
The si544 driver had a rounding problem that using the result of clk_round_rate
may set the clock to yet another rate, for example:
clk_round_rate(19500) = 19499
clk_round_rate(19499) = 19498
Clients would expect that after clk_set_rate(clk, freq2=clk_round_rate(clk,
freq)) the
Hi Xiuqi,
On 2018/5/31 20:14, Xie XiuQi wrote:
> A numa system may return node which is not online.
> For example, a numa node:
> 1) without memory
> 2) NR_CPUS is very small, and the cpus on the node are not brought up
I think adding detail info will be easy to be understood:
- NUMA node will
Hi Xiuqi,
On 2018/5/31 20:14, Xie XiuQi wrote:
> A numa system may return node which is not online.
> For example, a numa node:
> 1) without memory
> 2) NR_CPUS is very small, and the cpus on the node are not brought up
I think adding detail info will be easy to be understood:
- NUMA node will
On Thu, May 31, 2018 at 2:21 AM, Matti Vaittinen
wrote:
> On Wed, May 30, 2018 at 10:04:36PM -0500, Rob Herring wrote:
>> On Wed, May 30, 2018 at 11:42:32AM +0300, Matti Vaittinen wrote:
>> > Document devicetree bindings for ROHM BD71837 PMIC regulators.
>> > +ROHM BD71837 Power Management
On Thu, May 31, 2018 at 2:21 AM, Matti Vaittinen
wrote:
> On Wed, May 30, 2018 at 10:04:36PM -0500, Rob Herring wrote:
>> On Wed, May 30, 2018 at 11:42:32AM +0300, Matti Vaittinen wrote:
>> > Document devicetree bindings for ROHM BD71837 PMIC regulators.
>> > +ROHM BD71837 Power Management
601 - 700 of 1222 matches
Mail list logo
