* next technical board meeting, 2017-04-10
From: Yuanhan Liu @ 2017-04-10 6:49 UTC (permalink / raw)
To: dev, techboard; +Cc: Jerin Jacob
In-Reply-To: <20170406100142.GA10609@jerin>
Hi all,
The last techboard meeting was canceled, and it's been rescheduled to
today, 10th Apr, at 3pm UTC. I should have sent it out a bit earlier.
Sorry!
The agenda remains the same (see below).
--yliu
On Thu, Apr 06, 2017 at 03:31:43PM +0530, Jerin Jacob wrote:
> -----Original Message-----
> > Date: Thu, 30 Mar 2017 15:11:07 +0530
> > From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > To: dev@dpdk.org
> > Cc: techboard@dpdk.org
> > Subject: [dpdk-dev] next technical board meeting, 2017-04-06
> > User-Agent: NeoMutt/20170306 (1.8.0)
> >
> > Hello everyone,
> >
> > A meeting of the DPDK technical board will occur next Thursday,
> > April 6th 2017 at 9am UTC?
> >
> > The meeting takes place on the #dpdk-board channel on IRC.
> > This meeting is public, so anybody can join, see below for the agenda.
> >
> > Jerin
>
> The meeting got canceled due to lack of quorum.
> (6 out of 9 members were present, which is less than 70%(minimum quorum))
> # http://dpdk.org/about/techboard#meetings
>
> Yuanhan Liu volunteered to chair the next meeting.
> No particular date was agreed for next meeting.
>
> Yuanhan to follow on mail to select a date/time of next meeting.
>
> >
> > 1) Divergence between DPDK/Linux PF/VF implementations.
> >
> > Discussions:
> > http://dpdk.org/ml/archives/dev/2017-March/060529.html
> > http://dpdk.org/ml/archives/dev/2017-March/060063.html
> > http://dpdk.org/ml/archives/dev/2016-December/053056.html
> >
> > 2) Representative for the DPDK governance board
> >
> > 3) Scope of cmdline and cfgfile libraries in DPDK.
> > Discuss the scope of cmdline and cfgfile libraries in DPDK
> > and see if we allow more libs like that (Keith proposed a CLI lib),
> > or we do not do more,
> > or do we target to replace them by better external equivalents?
> >
> > 4) Community questions/issues
> >
> >
> >
^ permalink raw reply
* [Bug 100618] Dead Island crash after starting a new game
From: bugzilla-daemon @ 2017-04-10 6:49 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-100618-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #3 from at46n@t-online.de ---
I added the crash log of the game. There is no error at the end. The Game seems
to crash while compiling shaders. Let me know if I could do any more to help
with this bug or if you need more infos of my system.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1137 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 6:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel, linux-pm, Linux Kernel Mailing List,
Vincent Guittot, linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <CAJKOXPe_+Y+9ZLE7Jymqc5nULzo+qM4cCMFg2-cV_YnpCFkRCA@mail.gmail.com>
On 10-04-17, 08:45, Krzysztof Kozlowski wrote:
> Yes, keeping both make most sense, I think.
>
> Anyway, I found now the original report thread of Masahiro and I see
> Mark's response about using '-'. In that case I am fine with this. I
> would prefer to take only the exynos part (separated to ARMv7 and
> ARMv8) through my tree but I already sent a pull request so I am fine
> with this going directly to arm-soc.
This may end up going via the PM tree.
> I think you need to update also:
> Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
Oops. I searched for opp@ and missed the complex ones. There are some
DT files as well for TI which I missed. Will send a V2 with all that
fixed.
> With that change:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> (and implied acked-by)
Thanks.
--
viresh
^ permalink raw reply
* [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPe_+Y+9ZLE7Jymqc5nULzo+qM4cCMFg2-cV_YnpCFkRCA@mail.gmail.com>
On 10-04-17, 08:45, Krzysztof Kozlowski wrote:
> Yes, keeping both make most sense, I think.
>
> Anyway, I found now the original report thread of Masahiro and I see
> Mark's response about using '-'. In that case I am fine with this. I
> would prefer to take only the exynos part (separated to ARMv7 and
> ARMv8) through my tree but I already sent a pull request so I am fine
> with this going directly to arm-soc.
This may end up going via the PM tree.
> I think you need to update also:
> Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
Oops. I searched for opp@ and missed the complex ones. There are some
DT files as well for TI which I missed. Will send a V2 with all that
fixed.
> With that change:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> (and implied acked-by)
Thanks.
--
viresh
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-10 6:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List
In-Reply-To: <CAJKOXPe_+Y+9ZLE7Jymqc5nULzo+qM4cCMFg2-cV_YnpCFkRCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10-04-17, 08:45, Krzysztof Kozlowski wrote:
> Yes, keeping both make most sense, I think.
>
> Anyway, I found now the original report thread of Masahiro and I see
> Mark's response about using '-'. In that case I am fine with this. I
> would prefer to take only the exynos part (separated to ARMv7 and
> ARMv8) through my tree but I already sent a pull request so I am fine
> with this going directly to arm-soc.
This may end up going via the PM tree.
> I think you need to update also:
> Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
Oops. I searched for opp@ and missed the complex ones. There are some
DT files as well for TI which I missed. Will send a V2 with all that
fixed.
> With that change:
> Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> (and implied acked-by)
Thanks.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 7/9] net/virtio: Add MTU feature support
From: Tan, Jianfeng @ 2017-04-10 6:48 UTC (permalink / raw)
To: Maxime Coquelin, aconole@redhat.com, sodey@sonusnet.com,
yuanhan.liu@linux.intel.com, thomas.monjalon@6wind.com,
dev@dpdk.org
In-Reply-To: <1e0af6da-cb01-fb91-c0b0-efa08ebd9f21@redhat.com>
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Saturday, April 8, 2017 12:41 AM
> To: Tan, Jianfeng; aconole@redhat.com; sodey@sonusnet.com;
> yuanhan.liu@linux.intel.com; thomas.monjalon@6wind.com; dev@dpdk.org
> Subject: Re: [PATCH v3 7/9] net/virtio: Add MTU feature support
>
> Hi Jianfeng,
>
> On 04/05/2017 04:50 PM, Tan, Jianfeng wrote:
> >
> >
> > On 4/5/2017 9:54 PM, Maxime Coquelin wrote:
> >>
> >>
> >> On 04/05/2017 11:42 AM, Tan, Jianfeng wrote:
> >>> Hi Maxime,
> >>>
> >>> Thank you for replying.
> >>>
> >>> On 4/5/2017 3:11 PM, Maxime Coquelin wrote:
> >>>> Hi Jianfeng,
> >>>>
> >>>> On 04/05/2017 06:52 AM, Tan, Jianfeng wrote:
> >>>>> Hi Maxime,
> >>>>>
> >>>>> Have some confusion about this feature. Please help confirm.
> >>>>>
> >>>>> (1) With this feature, we only support to advertise MTU value which is
> >>>>> defined by QEMU to frontend and backend driver separately. (2) But
> it
> >>>>> does not allow frontend driver to set a different MTU to QEMU and
> then
> >>>>> to vhost backend.
> >>>>>
> >>>>> Correct?
> >>>>> If it's correct, why not MTU works like (2)?
> >>>>
> >>>> Because idea is that the hosts advertises the maximum MTU value it
> >>>> supports. The frontend driver is free to use a smaller value. The goal
> >>>> of this change is to make possible to set a uniform MTU value across
> >>>> the infrastructure, the management tools giving a hint to the guests on
> >>>> the MTU value it should use.
> >>>
> >>> Based on that MTU is the maximum packet size that can be sent instead
> of
> >>> that can be received:
> >>> (1) Why vhost (as a device) does not drop any packets which are longer
> >>> than MTU when dequeue()?
> >> That's a good point.
> >> As when MTU value is negotiated, the guest agrees not to send larger
> >> packets. But we cannot trust the guest, so vhost needs to check the
> >> packet length.
> >>
> >>> (2) See some NICs also use MTU to calculate maximum packet size that
> can
> >>> be received, like ixgbe, i40e, shall we also do that?
> >> Can you give me some pointers to the code?
> >
> > Please refer ixgbe_dev_mtu_set(), and i40e_dev_mtu_set().
>
> Thanks. Yes, we could also do that.
>
> I can send a patch for this and another one to check the size of the
> packet respects negotiated MTU value. Or maybe you want to do this?
I'll help review then.
Thanks,
Jianfeng
^ permalink raw reply
* Re: [kernel-hardening] [PATCH net-next v6 07/11] landlock: Add ptrace restrictions
From: Djalal Harouni @ 2017-04-10 6:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, Jonathan Corbet, Matthew Garrett,
Michael Kerrisk, Kees Cook, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Tejun Heo
In-Reply-To: <20170328234650.19695-8-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün <mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org> wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlocked process must have a subset of the target
> process' rules.
>
> New in v6
>
> Signed-off-by: Mickaël Salaün <mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
> Cc: Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> Cc: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: James Morris <james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> ---
> security/landlock/Makefile | 2 +-
> security/landlock/hooks_ptrace.c | 126 +++++++++++++++++++++++++++++++++++++++
> security/landlock/hooks_ptrace.h | 11 ++++
> security/landlock/init.c | 2 +
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 security/landlock/hooks_ptrace.c
> create mode 100644 security/landlock/hooks_ptrace.h
>
[...]
> +/**
> + * landlock_ptrace_access_check - determine whether the current process may
> + * access another
> + *
> + * @child: the process to be accessed
> + * @mode: the mode of attachment
> + *
> + * If the current task has Landlock rules, then the child must have at least
> + * the same rules. Else denied.
> + *
> + * Determine whether a process may access another, returning 0 if permission
> + * granted, -errno if denied.
> + */
> +static int landlock_ptrace_access_check(struct task_struct *child,
> + unsigned int mode)
> +{
> + if (!landlocked(current))
> + return 0;
> +
> + if (!landlocked(child))
> + return -EPERM;
> +
> + if (landlock_task_has_subset_events(current, child))
> + return 0;
> +
> + return -EPERM;
> +}
> +
Maybe you want to check the mode argument here if it is a
PTRACE_ATTACH which may translate to read/writes ? PTRACE_READ are
normally for reads only. Or also which creds were used if this was a
direct syscall or a filesystem call through procfs.
I'm bringing this, since you may want to make some room for landlock
ptrace events and what others may want to do with it. Also I'm
planning to send another v2 RFC for procfs separate instances [1], the
aim is to give LSMs a security_ptrace_access_check hook path when
dealing with /proc/<pids>/ [2] . Right now LSMs don't really have a
security path there, and the implementation does not guarantee that.
With this Yama ptrace scope or other LSMs may take advantage of it and
check the 'PTRACE_MODE_READ_FSCRED' mode for filesystem accesses.
That's why I think it would be better if the default landlock ptrace
semantics are not that wide.
Thanks!
[1] https://lkml.org/lkml/2017/3/30/670
[2] http://lxr.free-electrons.com/source/fs/proc/base.c#L719
^ permalink raw reply
* [kernel-hardening] [PATCH net-next v6 07/11] landlock: Add ptrace restrictions
From: Djalal Harouni @ 2017-04-10 6:48 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20170328234650.19695-8-mic@digikod.net>
On Wed, Mar 29, 2017 at 1:46 AM, Micka?l Sala?n <mic@digikod.net> wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlocked process must have a subset of the target
> process' rules.
>
> New in v6
>
> Signed-off-by: Micka?l Sala?n <mic@digikod.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: James Morris <james.l.morris@oracle.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> ---
> security/landlock/Makefile | 2 +-
> security/landlock/hooks_ptrace.c | 126 +++++++++++++++++++++++++++++++++++++++
> security/landlock/hooks_ptrace.h | 11 ++++
> security/landlock/init.c | 2 +
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 security/landlock/hooks_ptrace.c
> create mode 100644 security/landlock/hooks_ptrace.h
>
[...]
> +/**
> + * landlock_ptrace_access_check - determine whether the current process may
> + * access another
> + *
> + * @child: the process to be accessed
> + * @mode: the mode of attachment
> + *
> + * If the current task has Landlock rules, then the child must have at least
> + * the same rules. Else denied.
> + *
> + * Determine whether a process may access another, returning 0 if permission
> + * granted, -errno if denied.
> + */
> +static int landlock_ptrace_access_check(struct task_struct *child,
> + unsigned int mode)
> +{
> + if (!landlocked(current))
> + return 0;
> +
> + if (!landlocked(child))
> + return -EPERM;
> +
> + if (landlock_task_has_subset_events(current, child))
> + return 0;
> +
> + return -EPERM;
> +}
> +
Maybe you want to check the mode argument here if it is a
PTRACE_ATTACH which may translate to read/writes ? PTRACE_READ are
normally for reads only. Or also which creds were used if this was a
direct syscall or a filesystem call through procfs.
I'm bringing this, since you may want to make some room for landlock
ptrace events and what others may want to do with it. Also I'm
planning to send another v2 RFC for procfs separate instances [1], the
aim is to give LSMs a security_ptrace_access_check hook path when
dealing with /proc/<pids>/ [2] . Right now LSMs don't really have a
security path there, and the implementation does not guarantee that.
With this Yama ptrace scope or other LSMs may take advantage of it and
check the 'PTRACE_MODE_READ_FSCRED' mode for filesystem accesses.
That's why I think it would be better if the default landlock ptrace
semantics are not that wide.
Thanks!
[1] https://lkml.org/lkml/2017/3/30/670
[2] http://lxr.free-electrons.com/source/fs/proc/base.c#L719
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [kernel-hardening] [PATCH net-next v6 07/11] landlock: Add ptrace restrictions
From: Djalal Harouni @ 2017-04-10 6:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, Jonathan Corbet, Matthew Garrett,
Michael Kerrisk, Kees Cook, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Tejun Heo
In-Reply-To: <20170328234650.19695-8-mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün <mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org> wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlocked process must have a subset of the target
> process' rules.
>
> New in v6
>
> Signed-off-by: Mickaël Salaün <mic-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
> Cc: Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
> Cc: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: James Morris <james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Cc: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
> ---
> security/landlock/Makefile | 2 +-
> security/landlock/hooks_ptrace.c | 126 +++++++++++++++++++++++++++++++++++++++
> security/landlock/hooks_ptrace.h | 11 ++++
> security/landlock/init.c | 2 +
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 security/landlock/hooks_ptrace.c
> create mode 100644 security/landlock/hooks_ptrace.h
>
[...]
> +/**
> + * landlock_ptrace_access_check - determine whether the current process may
> + * access another
> + *
> + * @child: the process to be accessed
> + * @mode: the mode of attachment
> + *
> + * If the current task has Landlock rules, then the child must have at least
> + * the same rules. Else denied.
> + *
> + * Determine whether a process may access another, returning 0 if permission
> + * granted, -errno if denied.
> + */
> +static int landlock_ptrace_access_check(struct task_struct *child,
> + unsigned int mode)
> +{
> + if (!landlocked(current))
> + return 0;
> +
> + if (!landlocked(child))
> + return -EPERM;
> +
> + if (landlock_task_has_subset_events(current, child))
> + return 0;
> +
> + return -EPERM;
> +}
> +
Maybe you want to check the mode argument here if it is a
PTRACE_ATTACH which may translate to read/writes ? PTRACE_READ are
normally for reads only. Or also which creds were used if this was a
direct syscall or a filesystem call through procfs.
I'm bringing this, since you may want to make some room for landlock
ptrace events and what others may want to do with it. Also I'm
planning to send another v2 RFC for procfs separate instances [1], the
aim is to give LSMs a security_ptrace_access_check hook path when
dealing with /proc/<pids>/ [2] . Right now LSMs don't really have a
security path there, and the implementation does not guarantee that.
With this Yama ptrace scope or other LSMs may take advantage of it and
check the 'PTRACE_MODE_READ_FSCRED' mode for filesystem accesses.
That's why I think it would be better if the default landlock ptrace
semantics are not that wide.
Thanks!
[1] https://lkml.org/lkml/2017/3/30/670
[2] http://lxr.free-electrons.com/source/fs/proc/base.c#L719
^ permalink raw reply
* Re: [kernel-hardening] [PATCH net-next v6 07/11] landlock: Add ptrace restrictions
From: Djalal Harouni @ 2017-04-10 6:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Arnaldo Carvalho de Melo, Casey Schaufler, Daniel Borkmann,
David Drysdale, David S . Miller, Eric W . Biederman,
James Morris, Jann Horn, Jonathan Corbet, Matthew Garrett,
Michael Kerrisk, Kees Cook, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Tejun Heo, Thomas Graf, Will Drewry,
kernel-hardening, Linux API, LSM List, netdev
In-Reply-To: <20170328234650.19695-8-mic@digikod.net>
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün <mic@digikod.net> wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlocked process must have a subset of the target
> process' rules.
>
> New in v6
>
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: James Morris <james.l.morris@oracle.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> ---
> security/landlock/Makefile | 2 +-
> security/landlock/hooks_ptrace.c | 126 +++++++++++++++++++++++++++++++++++++++
> security/landlock/hooks_ptrace.h | 11 ++++
> security/landlock/init.c | 2 +
> 4 files changed, 140 insertions(+), 1 deletion(-)
> create mode 100644 security/landlock/hooks_ptrace.c
> create mode 100644 security/landlock/hooks_ptrace.h
>
[...]
> +/**
> + * landlock_ptrace_access_check - determine whether the current process may
> + * access another
> + *
> + * @child: the process to be accessed
> + * @mode: the mode of attachment
> + *
> + * If the current task has Landlock rules, then the child must have at least
> + * the same rules. Else denied.
> + *
> + * Determine whether a process may access another, returning 0 if permission
> + * granted, -errno if denied.
> + */
> +static int landlock_ptrace_access_check(struct task_struct *child,
> + unsigned int mode)
> +{
> + if (!landlocked(current))
> + return 0;
> +
> + if (!landlocked(child))
> + return -EPERM;
> +
> + if (landlock_task_has_subset_events(current, child))
> + return 0;
> +
> + return -EPERM;
> +}
> +
Maybe you want to check the mode argument here if it is a
PTRACE_ATTACH which may translate to read/writes ? PTRACE_READ are
normally for reads only. Or also which creds were used if this was a
direct syscall or a filesystem call through procfs.
I'm bringing this, since you may want to make some room for landlock
ptrace events and what others may want to do with it. Also I'm
planning to send another v2 RFC for procfs separate instances [1], the
aim is to give LSMs a security_ptrace_access_check hook path when
dealing with /proc/<pids>/ [2] . Right now LSMs don't really have a
security path there, and the implementation does not guarantee that.
With this Yama ptrace scope or other LSMs may take advantage of it and
check the 'PTRACE_MODE_READ_FSCRED' mode for filesystem accesses.
That's why I think it would be better if the default landlock ptrace
semantics are not that wide.
Thanks!
[1] https://lkml.org/lkml/2017/3/30/670
[2] http://lxr.free-electrons.com/source/fs/proc/base.c#L719
^ permalink raw reply
* Re: Issue with load across multiple connections
From: Ulrich Speidel @ 2017-04-10 6:35 UTC (permalink / raw)
To: Eric Dumazet, Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <1491000417.8750.44.camel@edumazet-glaptop3.roam.corp.google.com>
Dear Eric,
My apologies for taking so long to get back to you - I had to wait for
some experiments to finish until I could grab hold of two machines that
weren't busy and had a more or less direct connection.
On the server (a Super Micro):
root@serverQ:/home/lei/Desktop/servers-20160311# cat
/proc/sys/net/ipv4/tcp_rmem
4096 87380 6291456
root@serverQ:/home/lei/Desktop/servers-20160311# cat
/proc/sys/net/ipv4/tcp_wmem
4096 16384 4194304
root@serverQ:/home/lei/Desktop/servers-20160311# cat
/proc/sys/net/ipv4/tcp_mem
47337 63117 94674
On the client (a Raspberry Pi):
root@server-controller:/home/lei/20160226/servers-20160226# cat
/proc/sys/net/ipv4/tcp_rmem
4096 87380 6291456
root@server-controller:/home/lei/20160226/servers-20160226# cat
/proc/sys/net/ipv4/tcp_wmem
4096 16384 4194304
root@server-controller:/home/lei/20160226/servers-20160226# cat
/proc/sys/net/ipv4/tcp_mem
22206 29611 44412
nstat output:
On server:
root@serverQ:/home/lei/Desktop/servers-20160311# nstat
#kernel
IpInReceives 223487 0.0
IpInDelivers 223487 0.0
IpOutRequests 242888 0.0
TcpPassiveOpens 2625 0.0
TcpEstabResets 1 0.0
TcpInSegs 217980 0.0
TcpOutSegs 227965 0.0
TcpRetransSegs 14888 0.0
TcpOutRsts 635 0.0
UdpInDatagrams 809 0.0
UdpOutDatagrams 32 0.0
Ip6InReceives 21 0.0
Ip6InDelivers 17 0.0
Ip6OutRequests 4 0.0
Ip6InMcastPkts 17 0.0
Ip6OutMcastPkts 8 0.0
Ip6InOctets 1480 0.0
Ip6OutOctets 288 0.0
Ip6InMcastOctets 1192 0.0
Ip6OutMcastOctets 576 0.0
Ip6InNoECTPkts 21 0.0
Icmp6InMsgs 13 0.0
Icmp6OutMsgs 4 0.0
Icmp6InGroupMembQueries 4 0.0
Icmp6InGroupMembResponses 4 0.0
Icmp6InNeighborAdvertisements 5 0.0
Icmp6OutGroupMembResponses 4 0.0
Icmp6InType130 4 0.0
Icmp6InType131 4 0.0
Icmp6InType136 5 0.0
Icmp6OutType131 4 0.0
TcpExtSyncookiesSent 182 0.0
TcpExtSyncookiesRecv 182 0.0
TcpExtSyncookiesFailed 622 0.0
TcpExtTW 337 0.0
TcpExtPAWSEstab 34317 0.0
TcpExtDelayedACKs 3 0.0
TcpExtDelayedACKLost 7 0.0
TcpExtListenOverflows 8 0.0
TcpExtListenDrops 190 0.0
TcpExtTCPHPHits 2 0.0
TcpExtTCPPureAcks 95602 0.0
TcpExtTCPHPAcks 14 0.0
TcpExtTCPSackRecovery 2784 0.0
TcpExtTCPSACKReorder 1 0.0
TcpExtTCPFullUndo 1901 0.0
TcpExtTCPPartialUndo 883 0.0
TcpExtTCPFastRetrans 1292 0.0
TcpExtTCPForwardRetrans 13592 0.0
TcpExtTCPTimeouts 4 0.0
TcpExtTCPLossProbes 18 0.0
TcpExtTCPDSACKOldSent 7 0.0
TcpExtTCPDSACKRecv 97 0.0
TcpExtTCPDSACKIgnoredNoUndo 97 0.0
TcpExtTCPSackShiftFallback 207045 0.0
TcpExtTCPReqQFullDoCookies 182 0.0
IpExtInMcastPkts 817 0.0
IpExtOutMcastPkts 2 0.0
IpExtInBcastPkts 4690 0.0
IpExtInOctets 15946943 0.0
IpExtOutOctets 295423944 0.0
IpExtInMcastOctets 200946 0.0
IpExtOutMcastOctets 64 0.0
IpExtInBcastOctets 629914 0.0
IpExtInNoECTPkts 223487 0.0
On client:
root@server-controller:/home/lei/20160226/servers-20160226# nstat
#kernel
IpInReceives 249082 0.0
IpInDelivers 249030 0.0
IpOutRequests 218185 0.0
TcpActiveOpens 2641 0.0
TcpInSegs 242884 0.0
TcpOutSegs 217992 0.0
TcpRetransSegs 16 0.0
TcpInErrs 4 0.0
TcpOutRsts 13538 0.0
UdpInDatagrams 8128 0.0
UdpOutDatagrams 177 0.0
UdpIgnoredMulti 1648 0.0
Ip6InReceives 49 0.0
Ip6InDelivers 16 0.0
Ip6OutRequests 5 0.0
Ip6InMcastPkts 44 0.0
Ip6OutMcastPkts 5 0.0
Ip6InOctets 3584 0.0
Ip6OutOctets 360 0.0
Ip6InMcastOctets 3136 0.0
Ip6OutMcastOctets 360 0.0
Ip6InNoECTPkts 49 0.0
Icmp6InMsgs 12 0.0
Icmp6OutMsgs 5 0.0
Icmp6InGroupMembQueries 4 0.0
Icmp6InGroupMembResponses 3 0.0
Icmp6InNeighborAdvertisements 5 0.0
Icmp6OutGroupMembResponses 5 0.0
Icmp6InType130 4 0.0
Icmp6InType131 3 0.0
Icmp6InType136 5 0.0
Icmp6OutType131 5 0.0
TcpExtPAWSEstab 4092 0.0
TcpExtDelayedACKLost 13560 0.0
TcpExtTCPHPHits 4593 0.0
TcpExtTCPPureAcks 29010 0.0
TcpExtTCPHPAcks 10 0.0
TcpExtTCPLossProbes 16 0.0
TcpExtTCPDSACKOldSent 13560 0.0
TcpExtTCPAbortOnData 24 0.0
TcpExtTCPRcvCoalesce 94257 0.0
TcpExtTCPOFOQueue 129737 0.0
TcpExtTCPChallengeACK 4 0.0
TcpExtTCPSYNChallenge 4 0.0
TcpExtTCPAutoCorking 1 0.0
TcpExtTCPOrigDataSent 2682 0.0
TcpExtTCPACKSkippedPAWS 55 0.0
TcpExtTCPACKSkippedSeq 111 0.0
IpExtInMcastPkts 888 0.0
IpExtInBcastPkts 5253 0.0
IpExtOutBcastPkts 67 0.0
IpExtOutOctets 15093500 0.0
IpExtInMcastOctets 214347 0.0
IpExtOutBcastOctets 11456 0.0
IpExtInNoECTPkts 249082 0.0
The experiment here generated flows of 100 kB each on 40 channels, each
channel connecting sequentially as many times as possible for 180
seconds. This run was a bit unusual in that it only had four "hung"
channels: 5, 17, 36 and 40. The rest managed 72-74 connections each. The
run before in the same configuration had 17 channels hang.
Any clues?
Best regards,
Ulrich
On 1/04/2017 11:46 a.m., Eric Dumazet wrote:
> TCP stack has no fairness guarantee, both at sender side and receive
> side.
>
> This smells like some memory tuning to me. Some flows, depending on
> their start time, can grab big receive/send windows, and others might
> hit global memory pressure and fallback to ridiculous windows.
>
> Please provide, on server and client :
>
> cat /proc/sys/net/ipv4/tcp_rmem
> cat /proc/sys/net/ipv4/tcp_wmem
> cat /proc/sys/net/ipv4/tcp_mem
>
> and maybe nstat output
>
> nstats -n >/dev/null ; < run experiment > ; nstat
>
>
> But I guess this is really a receiver problem, with too small amount of
> memory.
>
>
>> ---------- Forwarded message ----------
>> From: Ulrich Speidel <ulrich@cs.auckland.ac.nz>
>> Date: Fri, Mar 31, 2017 at 2:11 AM
>> Subject: Linux kernel query
>> To: tom@quantonium.net
>> Cc: Brian Carpenter <brian@cs.auckland.ac.nz>, Nevil Brownlee
>> <n.brownlee@auckland.ac.nz>, lars@steinwurf.com, Lei Qian
>> <lqia012@gmail.com>
>>
>>
>> Dear Tom,
>>
>> I'm a colleague of Brian Carpenter at the University of Auckland. He
>> has suggested that I contact you about this as I'm not sure that what
>> we have discovered is a bug - it may even be an intended feature but
>> I've failed to find it documented anywhere. From all we can tell, the
>> problem seems related to how socket file descriptor numbers & SKBs are
>> handled in POSIX-compliant kernels. I'm not a kernel hack so apologise
>> in advance if terminology isn't always spot-on.
>>
>> This is how we triggered the effect: We have a setup in which we have
>> multiple physical network clients connect to multiple servers at
>> random. On the client side, we create N "channels" (indexed, say 0 to
>> N-1) on each physical client. Each channel executes the following
>> task:
>>
>> 1) create a fresh TCP socket
>> 2) connect to a randomly chosen server from our pool
>> 3) receive a quantity of data that the server sends (this may be
>> somewhere between 0 bytes and hundreds of MB). In our case, we use the
>> application merely as a network traffic generator, so the receive
>> process consists of recording the number of bytes made available by
>> the socket and freeing the buffer without ever actually reading it.
>> 4) wait for server disconnect
>> 5) free socket (i.e., we're not explicitly re-using the previous
>> connection's socket)
>> 6) jump back to 1)
>>
>> We keep track of the throughput on each channel.
>>
>> Note that the effect is the same regardless of whether we implement
>> each channel in a process of its own, in a threaded application, or
>> whether we use non-blocking sockets and check on them in a loop.
>>
>> What we would normally expect is that the each channel would receive
>> about the same goodput over time, regardless of the value of N. Note
>> that each channel uses a succession of fresh sockets.
>>
>> What actually happens is this: For up to approximately N=20 channels
>> on a single physical client (we've tried Raspbian and Debian, as well
>> as Ubuntu), each channel sees on average substantial and comparable
>> levels of throughput, adding up to values approaching network
>> interface capacity. Once we push N beyond 20, the throughput on any
>> further channels drops to zero very quickly. For N=30, we typically
>> see at least half a dozen channels with no throughput at all beyond
>> the connection handshake. Throughput on the first 20 or so channels
>> remains pretty much unchanged. The sockets on the channels with low or
>> no throughput all manage to connect, but remain in connected state but
>> receive no data.
>>
>> Throughput on the first ~20 channels is sustainable for long periods
>> of time - so we're not dealing with an intermittent bug that causes
>> our sockets to stall: The affected sockets / channels never receive
>> anything (and the sockets around the 20-or-so mark very little). So it
>> seems that subsequent sockets on a channel inherit the ability of
>> their predecessor to receive data at quantity.
>>
>> We also see the issue on a single physical Raspberry client having the
>> sole use of 14 Super Micros on GbE interfaces to download from. So we
>> know we're definitely not overloading the server side (note that we
>> are able to saturate the network to the Pi). Here is some sample data
>> from the Pi (my apologies for the rough format):
>>
>> Channel index/MB transferred/Number of connections completed+attempted
>> 0 2.37 144
>> 1 29.32 92
>> 2 2.71 132
>> 3 10.88 705
>> 4 11.90 513
>> 5 16.045990 571
>> 6 9.631539 598
>> 7 15.420138 362
>> 8 9.854378 106
>> 9 8.975264 315
>> 10 8.020266 526
>> 11 6.369107 582
>> 12 8.877760 277
>> 13 8.148640 406
>> 14 13.536793 301
>> 15 9.804712 55
>> 16 7.643378 292
>> 17 7.970028 393
>> 18 0.000120 1
>> 19 9.359919 415
>> 20 0.000120 1
>> 21 0.000120 1
>> 22 12.937519 314
>> 23 0.000920 2
>> 24 14.561784 362
>> 25 0.000240 2
>> 26 11.005030 535
>> 27 0.000120 1
>> 28 0.000120 1
>> 29 0.000120 1
>>
>> The total data rate in this example was 94.1 Mbps on the 100 Mbps
>> connection of the Pi. Experiment duration was 20 seconds on this
>> occasion, but the effect is stable - we have observed it for many
>> minutes. Once "stuck", a channel remains stuck.
>>
>> The fact that the incoming data rate accrues almost exclusively to the
>> ~20 busy channels suggests that the sockets on the other channel are
>> either advertising a window of 0 bytes or are not generating ACKs for
>> incoming data, or both.
>>
>> We have considered the possibility of FIN packets getting dropped
>> somewhere along the way - not only is this unlikely since they are
>> small, but the effect also happens if we connect a server directly by
>> cable to a client machine with no network equipment inbetween. Also,
>> if lost FINs were to blame, we would see some of the steadfast 20
>> channels stall over time as well, given the network load - and we
>> don't.
>>
>> We then looked at the numerical value of the socket file descriptors
>> in use by each channel and noticed that there was a strong correlation
>> between the average fd value and the goodput, or for that matter
>> between channel index and average fd value.
>>
>> When we artificially throttle the data rate that each server is able
>> to serve a single client connection on, we get data on vastly more of
>> the channels (in fact, that's the workaround we currently use, we're
>> getting up to around 40 workable channels that way).
>>
>> We note that the POSIX specs on file descriptor allocation demand
>> "lowest available first" and that this usually extends to socket fds
>> although POSIX doesn't prescribe this. From what I have been able to
>> glean from the Linux kernel source I have looked at, sockets are
>> entered into a linked list. I presume they are then serviced by the
>> kernel in list order, which seems reasonable. However, I suspect (but
>> haven't been able to locate the relevant piece of kernel code) that
>> the kernel services the list starting at the head up to a point where
>> it runs out of time allocated for this task. When it returns to the
>> task, it then also seems to return to the head of the list again.
>>
>> So it seems that the sockets with lower-numbered fds get serviced with
>> priority, thus get their downloads completed first, which releases the
>> fd to the table, and therefore makes it highly likely that the same
>> channel will be assigned the same low fd when it creates the next
>> socket. Higher-valued fds don't get service, don't complete their
>> downloads, and in consequence their channels never get to return the
>> fds and renew their sockets.
>>
>> During my sabbatical last year, I investigated this scenario together
>> with Aaron Gulliver from the University of Victoria, Canada, and we
>> were able to simulate the effect based on this assumption. The graph
>> from our draft paper below shows our (simplified) model in action - my
>> apologies for the first draft nature of it, I've been waiting for half
>> a year for a free day to complete it. It shows the number of times
>> each socket fd (=socket series) was re-used (=connections completed
>> using this fd value) during the simulation, as well as the bytes
>> received. Ignore the "days" labels - these are a measure of how much
>> "downtime" an fd number gets before it's re-used, read "days = time
>> slices". Note the exponential y axis and the cliff around the 20 mark,
>> i.e., pretty much what we see in practice.
>>
>>
>>
>> We have also tried to find a theoretical approach but now think that
>> it is combinatorially intractable except in very simple cases.
>>
>> I have also copied Lars Nielsen from Steinwurf ApS in Aalborg, who has
>> come across what is probably the same issue in a web crawler
>> application he was developing. He also observed the magical value of
>> about 20 and our "fix" worked for him, too. He has had an indication
>> that the effect is anecdotally known in browser developer circles.
>>
>> We are well aware that our applications (maintaining and continuously
>> renewing a large number of sockets that receive data at
>> all-you-can-eat rates) are somewhat unusual, so I am not sure whether
>> the effect is even known.
>>
>> So, my questions:
>>
>> 1) Does the kernel indeed stop processing part-way down the list and
>> then return to the head again rather than continue processing where it
>> left off?
>> 2) If so, is this a bug, or is it intended? I could imagine that the
>> effect would help protect existing service connections (e.g., SSH
>> logins) in the case of subsequent DDoS attacks, but I'm not sure
>> whether that's by coincidence or design.
>>
>> Any insights would be welcome!
>>
>> Best regards,
>>
>> Ulrich
>>
>> --
>> ****************************************************************
>> Dr. Ulrich Speidel
>>
>> Department of Computer Science
>>
>> Room 303S.594 (City Campus)
>> Ph: (+64-9)-373-7599 ext. 85282
>>
>> The University of Auckland
>> ulrich@cs.auckland.ac.nz
>> http://www.cs.auckland.ac.nz/~ulrich/
>> ****************************************************************
>
--
****************************************************************
Dr. Ulrich Speidel
Department of Computer Science
Room 303S.594 (City Campus)
Ph: (+64-9)-373-7599 ext. 85282
The University of Auckland
ulrich@cs.auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
^ permalink raw reply
* linux-next: build failure after merge of the akpm-current tree
From: Stephen Rothwell @ 2017-04-10 6:45 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/swap_slots.c: In function 'alloc_swap_slot_cache':
mm/swap_slots.c:126:10: error: implicit declaration of function 'kvzalloc' [-Werror=implicit-function-declaration]
slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
^
mm/swap_slots.c:126:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
^
mm/swap_slots.c:131:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
slots_ret = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
^
Caused by commit
22cf2f4616c6 ("mm, swap: U=use kvzalloc to allocate some swap data structure")
The patches adding kvzalloc seem to have vanished :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] drm/amdgpu: Fix firmware UCODE_ID_STORAGE issue
From: Trigger Huang @ 2017-04-10 6:45 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: ray.huang-5C7GfCeVMHo, Trigger Huang
In Tonga's virtualization environment, for firmware UCODE_ID_STORAGE,
there is no actual firmware data, but we still need alloc a BO and
tell the BO's mc address to HW, or world switch will hang on VFs.
Signed-off-by: Trigger Huang <trigger.huang@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index a1891c9..b7307b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -383,7 +383,7 @@ int amdgpu_ucode_init_bo(struct amdgpu_device *adev)
* ucode info here
*/
if (adev->firmware.load_type != AMDGPU_FW_LOAD_PSP)
- adev->firmware.max_ucodes = AMDGPU_UCODE_ID_MAXIMUM - 4;
+ adev->firmware.max_ucodes = AMDGPU_UCODE_ID_MAXIMUM - 3;
else
adev->firmware.max_ucodes = AMDGPU_UCODE_ID_MAXIMUM;
--
2.7.4
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Krzysztof Kozlowski @ 2017-04-10 6:45 UTC (permalink / raw)
To: Viresh Kumar
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel, linux-pm, Linux Kernel Mailing List,
Vincent Guittot, linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <20170410063239.GB24555@vireshk-i7>
On Mon, Apr 10, 2017 at 8:32 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-04-17, 15:30, Masahiro Yamada wrote:
>> 2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
>> > On 10-04-17, 10:46, Viresh Kumar wrote:
>> >> Compiling the DT file with W=1, DTC warns like follows:
>> >>
>> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
>> >> unit name, but no reg property
>> >>
>> >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>> >> "reg" property.
>> >>
>> >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > + Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > --
>> > viresh
>>
>>
>> Given that this had already been reported one year before,
>> the reported-by credit should be given to Krzysztof.
>>
>> Please drop my Reported-by.
>
> I don't think we need to drop any of you. We can very well keep both
> :)
Yes, keeping both make most sense, I think.
Anyway, I found now the original report thread of Masahiro and I see
Mark's response about using '-'. In that case I am fine with this. I
would prefer to take only the exynos part (separated to ARMv7 and
ARMv8) through my tree but I already sent a pull request so I am fine
with this going directly to arm-soc.
I think you need to update also:
Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
With that change:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
(and implied acked-by)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Krzysztof Kozlowski @ 2017-04-10 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410063239.GB24555@vireshk-i7>
On Mon, Apr 10, 2017 at 8:32 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-04-17, 15:30, Masahiro Yamada wrote:
>> 2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
>> > On 10-04-17, 10:46, Viresh Kumar wrote:
>> >> Compiling the DT file with W=1, DTC warns like follows:
>> >>
>> >> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
>> >> unit name, but no reg property
>> >>
>> >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>> >> "reg" property.
>> >>
>> >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > + Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > --
>> > viresh
>>
>>
>> Given that this had already been reported one year before,
>> the reported-by credit should be given to Krzysztof.
>>
>> Please drop my Reported-by.
>
> I don't think we need to drop any of you. We can very well keep both
> :)
Yes, keeping both make most sense, I think.
Anyway, I found now the original report thread of Masahiro and I see
Mark's response about using '-'. In that case I am fine with this. I
would prefer to take only the exynos part (separated to ARMv7 and
ARMv8) through my tree but I already sent a pull request so I am fine
with this going directly to arm-soc.
I think you need to update also:
Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
With that change:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
(and implied acked-by)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Krzysztof Kozlowski @ 2017-04-10 6:45 UTC (permalink / raw)
To: Viresh Kumar
Cc: Masahiro Yamada, Rafael Wysocki, Chanwoo Choi, MyungJoo Ham,
Kyungmin Park, Kukjin Kim, Javier Martinez Canillas, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rob Herring, Mark Rutland,
Daniel Mack, Haojian Zhuang, Robert Jarzmik, Maxime Ripard,
Chen-Yu Tsai, linaro-kernel, linux-pm, Linux Kernel Mailing List
In-Reply-To: <20170410063239.GB24555@vireshk-i7>
On Mon, Apr 10, 2017 at 8:32 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-04-17, 15:30, Masahiro Yamada wrote:
>> 2017-04-10 15:22 GMT+09:00 Viresh Kumar <viresh.kumar@linaro.org>:
>> > On 10-04-17, 10:46, Viresh Kumar wrote:
>> >> Compiling the DT file with W=1, DTC warns like follows:
>> >>
>> >> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
>> >> unit name, but no reg property
>> >>
>> >> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>> >> "reg" property.
>> >>
>> >> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > + Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > --
>> > viresh
>>
>>
>> Given that this had already been reported one year before,
>> the reported-by credit should be given to Krzysztof.
>>
>> Please drop my Reported-by.
>
> I don't think we need to drop any of you. We can very well keep both
> :)
Yes, keeping both make most sense, I think.
Anyway, I found now the original report thread of Masahiro and I see
Mark's response about using '-'. In that case I am fine with this. I
would prefer to take only the exynos part (separated to ARMv7 and
ARMv8) through my tree but I already sent a pull request so I am fine
with this going directly to arm-soc.
I think you need to update also:
Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
With that change:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
(and implied acked-by)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] logrotate: replace fedorahosted.org SRC_URI with github.com source
From: yin.thong.choong @ 2017-04-09 23:33 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1491780798-1591-1-git-send-email-yin.thong.choong@intel.com>
From: Choong YinThong <yin.thong.choong@intel.com>
fedorahosted.org was retired on March 1st, 2017. This is to
update the SRC_URI to point to github.com.
Update the ${PN} to ${BPN} in order to pass the autobuilder
mulitlib enable configuration.
[YOCTO #11226]
Signed-off-by: Choong YinThong <yin.thong.choong@intel.com>
---
meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
index 9c2dfe0..a871b45 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.9.1.bb
@@ -1,6 +1,6 @@
SUMMARY = "Rotates, compresses, removes and mails system log files"
SECTION = "console/utils"
-HOMEPAGE = "https://fedorahosted.org/logrotate/"
+HOMEPAGE = "https://github.com/logrotate/logrotate/issues"
LICENSE = "GPLv2"
# TODO: logrotate 3.8.8 adds autotools/automake support, update recipe to use it.
@@ -10,14 +10,25 @@ DEPENDS="coreutils popt"
LIC_FILES_CHKSUM = "file://COPYING;md5=18810669f13b87348459e611d31ab760"
-SRC_URI = "https://fedorahosted.org/releases/l/o/logrotate/logrotate-${PV}.tar.gz \
+# When updating logrotate to latest upstream, SRC_URI should point to
+# a proper release tarball from https://github.com/logrotate/logrotate/releases
+# and we have to take the snapshot for now because there is no such
+# tarball available for 3.9.1.
+
+S = "${WORKDIR}/${BPN}-r3-9-1"
+
+UPSTREAM_CHECK_URI = "https://github.com/${BPN}/${BPN}/releases"
+
+SRC_URI = "https://github.com/${BPN}/${BPN}/archive/r3-9-1.tar.gz \
file://act-as-mv-when-rotate.patch \
file://update-the-manual.patch \
file://disable-check-different-filesystems.patch \
"
-SRC_URI[md5sum] = "4492b145b6d542e4a2f41e77fa199ab0"
-SRC_URI[sha256sum] = "022769e3288c80981559a8421703c88e8438b447235e36dd3c8e97cd94c52545"
+# Checksum changed due to tarball source folder changes in upstream
+
+SRC_URI[md5sum] = "8572b7c2cf9ade09a8a8e10098500fb3"
+SRC_URI[sha256sum] = "5bf8e478c428e7744fefa465118f8296e7e771c981fb6dffb7527856a0ea3617"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.7.4
^ permalink raw reply related
* [PATCH] Replace fedorahosted.org SRC_URI with github.com source
From: yin.thong.choong @ 2017-04-09 23:33 UTC (permalink / raw)
To: openembedded-core
From: Choong YinThong <yin.thong.choong@intel.com>
Fedorahosted.org was retired on March 1st, 2017.
Replace all fedorahosted.org SRC_URI with source pagure.io and github.com.
Update the ${PN} to ${BPN} in order to pass the autobuilder mulitlib
enable configuration.
Choong YinThong (1):
logrotate: replace fedorahosted.org SRC_URI with github.com source
meta/recipes-extended/logrotate/logrotate_3.9.1.bb | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* [Bug 100618] Dead Island crash after starting a new game
From: bugzilla-daemon @ 2017-04-10 6:43 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-100618-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 302 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=100618
--- Comment #2 from at46n@t-online.de ---
Created attachment 130769
--> https://bugs.freedesktop.org/attachment.cgi?id=130769&action=edit
crash log of Dead Island
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/5] drm/amdgpu/vce4: workaround multi vce engine encoding hang issue
From: Christian König @ 2017-04-10 6:43 UTC (permalink / raw)
To: Xiangliang Yu, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW; +Cc: Frank Min
In-Reply-To: <1491741075-23827-1-git-send-email-Xiangliang.Yu-5C7GfCeVMHo@public.gmane.org>
Am 09.04.2017 um 14:31 schrieb Xiangliang Yu:
> For SRIOV, multi vce engine will hang when encoding. Add VMHUB
> flush to workaround it, will continue to find the root cause later.
NAK, that won't work and can cause hangs as well.
The hang you experience could be a known issue with old libdrm, do you
have updated to the latest version?
Regards,
Christian.
>
> Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
> Signed-off-by: Frank Min <Frank.Min@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> index d3448d0..b4e36f3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
> @@ -31,6 +31,7 @@
> #include "soc15d.h"
> #include "soc15_common.h"
> #include "mmsch_v1_0.h"
> +#include "gmc_v9_0.h"
>
> #include "vega10/soc15ip.h"
> #include "vega10/VCE/vce_4_0_offset.h"
> @@ -971,6 +972,7 @@ static void vce_v4_0_emit_vm_flush(struct amdgpu_ring *ring,
> uint32_t req = ring->adev->gart.gart_funcs->get_invalidate_req(vm_id);
> unsigned eng = ring->idx;
> unsigned i;
> + struct amdgpu_device *adev = ring->adev;
>
> pd_addr = pd_addr | 0x1; /* valid bit */
> /* now only use physical base address of PDE and valid */
> @@ -979,6 +981,15 @@ static void vce_v4_0_emit_vm_flush(struct amdgpu_ring *ring,
> for (i = 0; i < AMDGPU_MAX_VMHUBS; ++i) {
> struct amdgpu_vmhub *hub = &ring->adev->vmhub[i];
>
> + /* Workaround multi vce engine encoding hang issue */
> + if (i && amdgpu_sriov_vf(adev)) {
> + WREG32_NO_KIQ(hub->ctx0_ptb_addr_lo32 + vm_id * 2,
> + lower_32_bits(pd_addr));
> + WREG32_NO_KIQ(hub->ctx0_ptb_addr_hi32 + vm_id * 2,
> + upper_32_bits(pd_addr));
> + gmc_v9_0_flush_vmhub(adev, hub, eng, vm_id);
> + }
> +
> amdgpu_ring_write(ring, VCE_CMD_REG_WRITE);
> amdgpu_ring_write(ring,
> (hub->ctx0_ptb_addr_hi32 + vm_id * 2) << 2);
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: NULL pointer dereference in the kernel 3.10
From: Hillf Danton @ 2017-04-10 6:42 UTC (permalink / raw)
To: 'zhong jiang', 'Michal Hocko',
'Johannes Weiner', vdavydov.dev, mgorman,
'Vlastimil Babka'
Cc: 'Linux Memory Management List', 'LKML'
In-Reply-To: <58E8E81E.6090304@huawei.com>
On April 08, 2017 9:40 PM zhong Jiang wrote:
>
> when runing the stabile docker cases in the vm. The following issue will come up.
>
> #40 [ffff8801b57ffb30] async_page_fault at ffffffff8165c9f8
> [exception RIP: down_read_trylock+5]
> RIP: ffffffff810aca65 RSP: ffff8801b57ffbe8 RFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff88018ae858c1 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000008
> RBP: ffff8801b57ffc10 R8: ffffea0006903de0 R9: ffff8800b3c61810
> R10: 00000000000022cb R11: 0000000000000000 R12: ffff88018ae858c0
> R13: ffffea0006903dc0 R14: 0000000000000008 R15: ffffea0006903dc0
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000
> #41 [ffff8801b57ffbe8] page_lock_anon_vma_read at ffffffff811b241c
> #42 [ffff8801b57ffc18] page_referenced at ffffffff811b26a7
> #43 [ffff8801b57ffc90] shrink_active_list at ffffffff8118d634
> #44 [ffff8801b57ffd48] balance_pgdat at ffffffff8118f088
> #45 [ffff8801b57ffe20] kswapd at ffffffff8118f633
> #46 [ffff8801b57ffec8] kthread at ffffffff810a795f
> #47 [ffff8801b57fff50] ret_from_fork at ffffffff81665398
> crash> struct page.mapping ffffea0006903dc0
> mapping = 0xffff88018ae858c1
> crash> struct anon_vma 0xffff88018ae858c0
> struct anon_vma {
> root = 0x0,
> rwsem = {
> count = 0,
> wait_lock = {
> raw_lock = {
> {
> head_tail = 1,
> tickets = {
> head = 1,
> tail = 0
> }
> }
> }
> },
> wait_list = {
> next = 0x0,
> prev = 0x0
> }
> },
> refcount = {
> counter = 0
> },
> rb_root = {
> rb_node = 0x0
> }
> }
>
> This maks me wonder, the anon_vma do not come from slab structure.
> and the content is abnormal. IMO, At least anon_vma->root will not NULL.
> The issue can be reproduced every other week.
>
Check please if commit
624483f3ea8 ("mm: rmap: fix use-after-free in __put_anon_vma")
is included in the 3.10 you are running.
btw, why not run the mainline?
Hillf
^ permalink raw reply
* Re: NULL pointer dereference in the kernel 3.10
From: Hillf Danton @ 2017-04-10 6:42 UTC (permalink / raw)
To: 'zhong jiang', 'Michal Hocko',
'Johannes Weiner', vdavydov.dev, mgorman,
'Vlastimil Babka'
Cc: 'Linux Memory Management List', 'LKML'
In-Reply-To: <58E8E81E.6090304@huawei.com>
On April 08, 2017 9:40 PM zhong Jiang wrote:
>
> when runing the stabile docker cases in the vm. The following issue will come up.
>
> #40 [ffff8801b57ffb30] async_page_fault at ffffffff8165c9f8
> [exception RIP: down_read_trylock+5]
> RIP: ffffffff810aca65 RSP: ffff8801b57ffbe8 RFLAGS: 00010202
> RAX: 0000000000000000 RBX: ffff88018ae858c1 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000008
> RBP: ffff8801b57ffc10 R8: ffffea0006903de0 R9: ffff8800b3c61810
> R10: 00000000000022cb R11: 0000000000000000 R12: ffff88018ae858c0
> R13: ffffea0006903dc0 R14: 0000000000000008 R15: ffffea0006903dc0
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000
> #41 [ffff8801b57ffbe8] page_lock_anon_vma_read at ffffffff811b241c
> #42 [ffff8801b57ffc18] page_referenced at ffffffff811b26a7
> #43 [ffff8801b57ffc90] shrink_active_list at ffffffff8118d634
> #44 [ffff8801b57ffd48] balance_pgdat at ffffffff8118f088
> #45 [ffff8801b57ffe20] kswapd at ffffffff8118f633
> #46 [ffff8801b57ffec8] kthread at ffffffff810a795f
> #47 [ffff8801b57fff50] ret_from_fork at ffffffff81665398
> crash> struct page.mapping ffffea0006903dc0
> mapping = 0xffff88018ae858c1
> crash> struct anon_vma 0xffff88018ae858c0
> struct anon_vma {
> root = 0x0,
> rwsem = {
> count = 0,
> wait_lock = {
> raw_lock = {
> {
> head_tail = 1,
> tickets = {
> head = 1,
> tail = 0
> }
> }
> }
> },
> wait_list = {
> next = 0x0,
> prev = 0x0
> }
> },
> refcount = {
> counter = 0
> },
> rb_root = {
> rb_node = 0x0
> }
> }
>
> This maks me wonder, the anon_vma do not come from slab structure.
> and the content is abnormal. IMO, At least anon_vma->root will not NULL.
> The issue can be reproduced every other week.
>
Check please if commit
624483f3ea8 ("mm: rmap: fix use-after-free in __put_anon_vma")
is included in the 3.10 you are running.
btw, why not run the mainline?
Hillf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Chanwoo Choi @ 2017-04-10 6:42 UTC (permalink / raw)
To: Viresh Kumar, Rafael Wysocki, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Rob Herring,
Mark Rutland, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Maxime Ripard, Chen-Yu Tsai, Masahiro Yamada
Cc: linaro-kernel, linux-pm, linux-kernel, Vincent Guittot,
linux-samsung-soc, devicetree, linux-arm-kernel
In-Reply-To: <5ce1fbbc7cd37a6cfe54e93eeca311a7a52093ff.1491801395.git.viresh.kumar@linaro.org>
Hi,
On 2017년 04월 10일 14:16, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
> arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> arch/arm/boot/dts/pxa25x.dtsi | 8 +--
> arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
> arch/arm/boot/dts/sun8i-a33.dtsi | 8 +--
> arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
> arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
> 18 files changed, 280 insertions(+), 280 deletions(-)
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
[snip]
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH] PM / OPP: Use - instead of @ for DT entries
From: Chanwoo Choi @ 2017-04-10 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ce1fbbc7cd37a6cfe54e93eeca311a7a52093ff.1491801395.git.viresh.kumar@linaro.org>
Hi,
On 2017? 04? 10? 14:16, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> Documentation/devicetree/bindings/opp/opp.txt | 38 ++++++-------
> arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> arch/arm/boot/dts/pxa25x.dtsi | 8 +--
> arch/arm/boot/dts/pxa27x.dtsi | 14 ++---
> arch/arm/boot/dts/sun8i-a33.dtsi | 8 +--
> arch/arm/boot/dts/uniphier-pro5.dtsi | 32 +++++------
> arch/arm/boot/dts/uniphier-pxs2.dtsi | 16 +++---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 14 ++---
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 32 +++++------
> arch/arm64/boot/dts/zte/zx296718.dtsi | 10 ++--
> 18 files changed, 280 insertions(+), 280 deletions(-)
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
[snip]
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [RFC/RFT][PATCH 2/2] cpufreq: schedutil: Utilization aggregation
From: Joel Fernandes @ 2017-04-10 6:39 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM, Juri Lelli, LKML, Peter Zijlstra, Srinivas Pandruvada,
Viresh Kumar, Vincent Guittot, Patrick Bellasi, Morten Rasmussen
In-Reply-To: <2242635.g1ACnTm5vK@aspire.rjw.lan>
Hi Rafael,
On Sun, Apr 9, 2017 at 5:11 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Due to the limitation of the rate of frequency changes the schedutil
> governor only estimates the CPU utilization entirely when it is about
> to update the frequency for the corresponding cpufreq policy. As a
> result, the intermediate utilization values are discarded by it,
> but that is not appropriate in general (like, for example, when
> tasks migrate from one CPU to another or exit, in which cases the
> utilization measured by PELT may change abruptly between frequency
> updates).
>
> For this reason, modify schedutil to estimate CPU utilization
> completely whenever it is invoked for the given CPU and store the
> maximum encountered value of it as input for subsequent new frequency
> computations. This way the new frequency is always based on the
> maximum utilization value seen by the governor after the previous
> frequency update which effectively prevents intermittent utilization
> variations from causing it to be reduced unnecessarily.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> kernel/sched/cpufreq_schedutil.c | 90 +++++++++++++++++++++------------------
> 1 file changed, 50 insertions(+), 40 deletions(-)
>
> Index: linux-pm/kernel/sched/cpufreq_schedutil.c
> ===================================================================
> --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c
> +++ linux-pm/kernel/sched/cpufreq_schedutil.c
> @@ -57,7 +57,6 @@ struct sugov_cpu {
> unsigned long iowait_boost_max;
> u64 last_update;
>
> - /* The fields below are only needed when sharing a policy. */
> unsigned long util;
> unsigned long max;
> unsigned int flags;
> @@ -154,22 +153,30 @@ static unsigned int get_next_freq(struct
> return cpufreq_driver_resolve_freq(policy, freq);
> }
>
> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(struct sugov_cpu *sg_cpu, unsigned int flags)
> {
> + unsigned long cfs_util, cfs_max;
> struct rq *rq = this_rq();
> - unsigned long cfs_max;
>
> - cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> + sg_cpu->flags |= flags & SCHED_CPUFREQ_RT_DL;
> + if (sg_cpu->flags & SCHED_CPUFREQ_RT_DL)
> + return;
>
> - *util = min(rq->cfs.avg.util_avg, cfs_max);
> - *max = cfs_max;
> + cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> + cfs_util = min(rq->cfs.avg.util_avg, cfs_max);
> + if (sg_cpu->util * cfs_max < sg_cpu->max * cfs_util) {
Assuming all CPUs have equal compute capacity, doesn't this mean that
sg_cpu->util is updated only if cfs_util > sg_cpu->util?
Maybe I missed something, but wouldn't we want sg_cpu->util to be
reduced as well when cfs_util reduces? Doesn't this condition
basically discard all updates to sg_cpu->util that could have reduced
it?
> + sg_cpu->util = cfs_util;
> + sg_cpu->max = cfs_max;
> + }
> }
Thanks,
Joel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.