Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

[Davidlohr Bueso]

On Mon, 04 Sep 2017, Peter Zijlstra wrote:


For testing its trivial to hack your kernel and I don't feel this is
something an Admin can make reasonable decisions about.

So why? In general less knobs is better.


+1.

Also, note how b8fa70b51aa (xen, pvticketlocks: Add xen_nopvspin parameter
to disable xen pv ticketlocks) has no justification as to why its wanted
in the first place. The only thing I could find was from 15a3eac0784
(xen/spinlock: Document the xen_nopvspin parameter):

"Useful for diagnosing issues and comparing benchmarks in over-commit CPU 
scenarios."

So I vote for no additional knobs, specially for such core code.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] docs-rst: media: Don't use \small for V4L2_PIX_FMT_SRGGB10 documentation

[Mauro Carvalho Chehab]

From: Sakari Ailus 

There appears to be an issue in using \small in certain cases on Sphinx
1.4 and 1.5. Other format documents don't use \small either, remove it
from here as well.

[mche...@s-opensource.com: kept tabularcolumns - readjusted - and
 add a few blank lines for it to display better]
Signed-off-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/pixfmt-srggb10p.rst | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
index 9e52610aa954..d9e07a4b8b31 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb10p.rst
@@ -33,12 +33,7 @@ of a small V4L2_PIX_FMT_SBGGR10P image:
 **Byte Order.**
 Each cell is one byte.
 
-
-.. raw:: latex
-
-\newline\small
-
-.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{10.0cm}|
+.. tabularcolumns:: |p{2.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{1.0cm}|p{5.4cm}|
 
 .. flat-table::
 :header-rows:  0
@@ -51,6 +46,7 @@ Each cell is one byte.
   - B\ :sub:`02high`
   - G\ :sub:`03high`
   - G\ :sub:`03low`\ (bits 7--6) B\ :sub:`02low`\ (bits 5--4)
+
G\ :sub:`01low`\ (bits 3--2) B\ :sub:`00low`\ (bits 1--0)
 * - start + 5:
   - G\ :sub:`10high`
@@ -58,6 +54,7 @@ Each cell is one byte.
   - G\ :sub:`12high`
   - R\ :sub:`13high`
   - R\ :sub:`13low`\ (bits 7--6) G\ :sub:`12low`\ (bits 5--4)
+
R\ :sub:`11low`\ (bits 3--2) G\ :sub:`10low`\ (bits 1--0)
 * - start + 10:
   - B\ :sub:`20high`
@@ -65,6 +62,7 @@ Each cell is one byte.
   - B\ :sub:`22high`
   - G\ :sub:`23high`
   - G\ :sub:`23low`\ (bits 7--6) B\ :sub:`22low`\ (bits 5--4)
+
G\ :sub:`21low`\ (bits 3--2) B\ :sub:`20low`\ (bits 1--0)
 * - start + 15:
   - G\ :sub:`30high`
@@ -72,8 +70,5 @@ Each cell is one byte.
   - G\ :sub:`32high`
   - R\ :sub:`33high`
   - R\ :sub:`33low`\ (bits 7--6) G\ :sub:`32low`\ (bits 5--4)
+
R\ :sub:`31low`\ (bits 3--2) G\ :sub:`30low`\ (bits 1--0)
-
-.. raw:: latex
-
-\normalsize
-- 
2.13.5


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] media: pixfmt-srggb12p.rst: better format the table for PDF output

[Mauro Carvalho Chehab]

Adjust the table to be better displayed on PDF output.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/pixfmt-srggb12p.rst | 59 +---
 1 file changed, 21 insertions(+), 38 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst 
b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
index c0541e5acd01..59918a7913fe 100644
--- a/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-srggb12p.rst
@@ -30,6 +30,7 @@ Below is an example of a small V4L2_PIX_FMT_SBGGR12P image:
 **Byte Order.**
 Each cell is one byte.
 
+.. tabularcolumns:: 
|p{2.0cm}|p{1.0cm}|p{1.0cm}|p{2.7cm}|p{1.0cm}|p{1.0cm}|p{2.7cm}|
 
 
 .. flat-table::
@@ -38,66 +39,48 @@ Each cell is one byte.
 :widths:   2 1 1 1 1 1 1
 
 
--  .. row 1
-
-   -  start + 0:
-
+-  -  start + 0:
-  B\ :sub:`00high`
-
-  G\ :sub:`01high`
+   -  G\ :sub:`01low`\ (bits 7--4)
 
-   -  G\ :sub:`01low`\ (bits 7--4) B\ :sub:`00low`\ (bits 3--0)
-
+  B\ :sub:`00low`\ (bits 3--0)
-  B\ :sub:`02high`
-
-  G\ :sub:`03high`
+   -  G\ :sub:`03low`\ (bits 7--4)
 
-   -  G\ :sub:`03low`\ (bits 7--4) B\ :sub:`02low`\ (bits 3--0)
-
--  .. row 2
-
-   -  start + 6:
+  B\ :sub:`02low`\ (bits 3--0)
 
+-  -  start + 6:
-  G\ :sub:`10high`
-
-  R\ :sub:`11high`
+   -  R\ :sub:`11low`\ (bits 7--4)
 
-   -  R\ :sub:`11low`\ (bits 7--4) G\ :sub:`10low`\ (bits 3--0)
-
+  G\ :sub:`10low`\ (bits 3--0)
-  G\ :sub:`12high`
-
-  R\ :sub:`13high`
+   -  R\ :sub:`13low`\ (bits 3--2)
 
-   -  R\ :sub:`13low`\ (bits 3--2) G\ :sub:`12low`\ (bits 3--0)
-
--  .. row 3
-
-   -  start + 12:
-
+  G\ :sub:`12low`\ (bits 3--0)
+-  -  start + 12:
-  B\ :sub:`20high`
-
-  G\ :sub:`21high`
+   -  G\ :sub:`21low`\ (bits 7--4)
 
-   -  G\ :sub:`21low`\ (bits 7--4) B\ :sub:`20low`\ (bits 3--0)
-
+  B\ :sub:`20low`\ (bits 3--0)
-  B\ :sub:`22high`
-
-  G\ :sub:`23high`
+   -  G\ :sub:`23low`\ (bits 7--4)
 
-   -  G\ :sub:`23low`\ (bits 7--4) B\ :sub:`22low`\ (bits 3--0)
-
--  .. row 4
-
-   -  start + 18:
-
+  B\ :sub:`22low`\ (bits 3--0)
+-  -  start + 18:
-  G\ :sub:`30high`
-
-  R\ :sub:`31high`
+   -  R\ :sub:`31low`\ (bits 7--4)
 
-   -  R\ :sub:`31low`\ (bits 7--4) G\ :sub:`30low`\ (bits 3--0)
-
+  G\ :sub:`30low`\ (bits 3--0)
-  G\ :sub:`32high`
-
-  R\ :sub:`33high`
+   -  R\ :sub:`33low`\ (bits 3--2)
 
-   -  R\ :sub:`33low`\ (bits 3--2) G\ :sub:`32low`\ (bits 3--0)
+  G\ :sub:`32low`\ (bits 3--0)
-- 
2.13.5


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

[Waiman Long]

On 09/04/2017 10:40 AM, Peter Zijlstra wrote:
> On Mon, Sep 04, 2017 at 04:28:36PM +0200, Oscar Salvador wrote:
>> This is just a resend of Waiman Long's patch.
>> I could not find why it was not merged to upstream, so I thought
>> to give it another chance.
>> What follows is what Waiman Long wrote.
>>
>> Xen has an kernel command line argument "xen_nopvspin" to disable
>> paravirtual spinlocks. This patch adds a similar "kvm_nopvspin"
>> argument to disable paravirtual spinlocks for KVM. This can be useful
>> for testing as well as allowing administrators to choose unfair lock
>> for their KVM guests if they want to.
> For testing its trivial to hack your kernel and I don't feel this is
> something an Admin can make reasonable decisions about.

I almost forgot about this patch that I sent quite a while ago. I was
sending this patch out mainly to maintain consistency between KVM and
Xen. This patch is not that important to me, and that is why I didn't
push it further.

Cheers,
Longman
 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

[Roman Gushchin]

On Mon, Sep 04, 2017 at 10:32:37AM -0700, Shakeel Butt wrote:
> On Mon, Sep 4, 2017 at 7:21 AM, Roman Gushchin  wrote:
> > Introducing of cgroup-aware OOM killer changes the victim selection
> > algorithm used by default: instead of picking the largest process,
> > it will pick the largest memcg and then the largest process inside.
> >
> > This affects only cgroup v2 users.
> >
> > To provide a way to use cgroups v2 if the old OOM victim selection
> > algorithm is preferred for some reason, the nogroupoom mount option
> > is added.
> 
> Is this mount option or boot parameter? From the code, it seems like a
> boot parameter.

Sure, you're right.

Fixed version below.

Thank you!

--

>From 0b4757ec8d339fa883e17d4e25a92f45bf5565e0 Mon Sep 17 00:00:00 2001
From: Roman Gushchin 
Date: Mon, 4 Sep 2017 12:08:52 +0100
Subject: [v7 5/5] mm, oom: allow disabling cgroup-aware OOM killer

Introducing of cgroup-aware OOM killer changes the victim selection
algorithm used by default: instead of picking the largest process,
it will pick the largest memcg and then the largest process inside.

This affects only cgroup v2 users.

To provide a way to use cgroups v2 if the old OOM victim selection
algorithm is preferred for some reason, the cgroup.memory=nogroupoom
boot option is added.

If set, the OOM selection is performed in a "traditional" per-process
way. Both oom_priority and oom_group memcg knobs are ignored.

Signed-off-by: Roman Gushchin 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Tetsuo Handa 
Cc: David Rientjes 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
---
 Documentation/admin-guide/kernel-parameters.txt | 1 +
 mm/memcontrol.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 28f1a0f84456..07891f1030aa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -489,6 +489,7 @@
Format: 
nosocket -- Disable socket memory accounting.
nokmem -- Disable kernel memory accounting.
+   nogroupoom -- Disable cgroup-aware OOM killer.
 
checkreqprot[SELINUX] Set initial checkreqprot flag value.
Format: { "0" | "1" }
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index d7dd293897ca..6a8235dc41f6 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -87,6 +87,9 @@ static bool cgroup_memory_nosocket;
 /* Kernel memory accounting disabled? */
 static bool cgroup_memory_nokmem;
 
+/* Cgroup-aware OOM  disabled? */
+static bool cgroup_memory_nogroupoom;
+
 /* Whether the swap controller is active */
 #ifdef CONFIG_MEMCG_SWAP
 int do_swap_account __read_mostly;
@@ -2822,6 +2825,9 @@ bool mem_cgroup_select_oom_victim(struct oom_control *oc)
if (mem_cgroup_disabled())
return false;
 
+   if (cgroup_memory_nogroupoom)
+   return false;
+
if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
return false;
 
@@ -6188,6 +6194,8 @@ static int __init cgroup_memory(char *s)
cgroup_memory_nosocket = true;
if (!strcmp(token, "nokmem"))
cgroup_memory_nokmem = true;
+   if (!strcmp(token, "nogroupoom"))
+   cgroup_memory_nogroupoom = true;
}
return 0;
 }
-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

[Shakeel Butt]

On Mon, Sep 4, 2017 at 7:21 AM, Roman Gushchin  wrote:
> Introducing of cgroup-aware OOM killer changes the victim selection
> algorithm used by default: instead of picking the largest process,
> it will pick the largest memcg and then the largest process inside.
>
> This affects only cgroup v2 users.
>
> To provide a way to use cgroups v2 if the old OOM victim selection
> algorithm is preferred for some reason, the nogroupoom mount option
> is added.

Is this mount option or boot parameter? From the code, it seems like a
boot parameter.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

[Peter Zijlstra]

On Mon, Sep 04, 2017 at 04:28:36PM +0200, Oscar Salvador wrote:
> This is just a resend of Waiman Long's patch.
> I could not find why it was not merged to upstream, so I thought
> to give it another chance.
> What follows is what Waiman Long wrote.
> 
> Xen has an kernel command line argument "xen_nopvspin" to disable
> paravirtual spinlocks. This patch adds a similar "kvm_nopvspin"
> argument to disable paravirtual spinlocks for KVM. This can be useful
> for testing as well as allowing administrators to choose unfair lock
> for their KVM guests if they want to.

For testing its trivial to hack your kernel and I don't feel this is
something an Admin can make reasonable decisions about.

So why? In general less knobs is better.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

[Oscar Salvador]

This is just a resend of Waiman Long's patch.
I could not find why it was not merged to upstream, so I thought
to give it another chance.
What follows is what Waiman Long wrote.

Xen has an kernel command line argument "xen_nopvspin" to disable
paravirtual spinlocks. This patch adds a similar "kvm_nopvspin"
argument to disable paravirtual spinlocks for KVM. This can be useful
for testing as well as allowing administrators to choose unfair lock
for their KVM guests if they want to.

Signed-off-by: Waiman Long 
Signed-off-by: Oscar Salvador 
---
 Documentation/admin-guide/kernel-parameters.txt |  6 +-
 arch/x86/kernel/kvm.c   | 14 +-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index d9c171ce4190..56c6e3acdf8e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1899,6 +1899,10 @@
feature (tagged TLBs) on capable Intel chips.
Default is 1 (enabled)
 
+   kvm_nopvspin[X86,KVM]
+   Disables the paravirtualized spinlock slowpath
+   optimizations for KVM.
+
l2cr=   [PPC]
 
l3cr=   [PPC]
@@ -4533,7 +4537,7 @@
never -- do not unplug even if version check succeeds
 
xen_nopvspin[X86,XEN]
-   Disables the ticketlock slowpath using Xen PV
+   Disables the spinlock slowpath using Xen PV
optimizations.
 
xen_nopv[X86]
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index d04e30e3c0ff..51addf874fc1 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -568,6 +568,18 @@ static void kvm_kick_cpu(int cpu)
kvm_hypercall2(KVM_HC_KICK_CPU, flags, apicid);
 }
 
+static bool kvm_pvspin = true;
+
+/*
+ * Allow disabling of PV spinlock in kernel command line
+ */
+static __init int kvm_parse_nopvspin(char *arg)
+{
+   kvm_pvspin = false;
+   return 0;
+}
+early_param("kvm_nopvspin", kvm_parse_nopvspin);
+
 #include 
 
 static void kvm_wait(u8 *ptr, u8 val)
@@ -633,7 +645,7 @@ asm(
  */
 void __init kvm_spinlock_init(void)
 {
-   if (!kvm_para_available())
+   if (!kvm_para_available() || !kvm_pvspin)
return;
/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v7 4/5] mm, oom, docs: describe the cgroup-aware OOM killer

[Roman Gushchin]

Update cgroups v2 docs.

Signed-off-by: Roman Gushchin 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Tetsuo Handa 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
---
 Documentation/cgroup-v2.txt | 56 +
 1 file changed, 56 insertions(+)

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index a86f3cb88125..5d21bd2e7d55 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -44,6 +44,7 @@ CONTENTS
 5-2-1. Memory Interface Files
 5-2-2. Usage Guidelines
 5-2-3. Memory Ownership
+5-2-4. OOM Killer
   5-3. IO
 5-3-1. IO Interface Files
 5-3-2. Writeback
@@ -799,6 +800,33 @@ PAGE_SIZE multiple when read back.
high limit is used and monitored properly, this limit's
utility is limited to providing the final safety net.
 
+  memory.oom_group
+
+   A read-write single value file which exists on non-root
+   cgroups.  The default is "0".
+
+   If set, OOM killer will kill all processes attached to the cgroup
+   if selected as an OOM victim.
+
+   OOM killer respects the /proc/pid/oom_score_adj value -1000,
+   and will never kill the unkillable task, even if memory.oom_group
+   is set.
+
+  memory.oom_priority
+
+   A read-write single value file which exists on non-root
+   cgroups.  The default is "0".
+
+   An integer number, which defines the order in which
+   the OOM killer selects victim memory cgroups.
+
+   OOM killer prefers memory cgroups with larger priority if they
+   are populated with eligible tasks.
+
+   The oom_priority value is compared within sibling cgroups.
+
+   The root cgroup has the oom_priority 0, which cannot be changed.
+
   memory.events
 
A read-only flat-keyed file which exists on non-root cgroups.
@@ -1028,6 +1056,34 @@ POSIX_FADV_DONTNEED to relinquish the ownership of 
memory areas
 belonging to the affected files to ensure correct memory ownership.
 
 
+5-2-4. OOM Killer
+
+Cgroup v2 memory controller implements a cgroup-aware OOM killer.
+It means that it treats cgroups as first class OOM entities.
+
+Under OOM conditions the memory controller tries to make the best
+choice of a victim, hierarchically looking for a cgroup with the
+largest oom_priority. If sibling cgroups have the same priority,
+the OOM killer selects one which is the largest memory consumer.
+
+By default, OOM killer will kill the biggest task in the selected
+memory cgroup. A user can change this behavior by enabling
+the per-cgroup oom_group option. If set, it causes the OOM killer
+to kill all processes attached to the cgroup.
+
+Tasks in the root cgroup are treated as independent memory consumers,
+and are compared with other memory consumers (memory cgroups and
+other tasks in root cgroup).
+The root cgroup doesn't support the oom_group feature.
+
+This affects both system- and cgroup-wide OOMs. For a cgroup-wide OOM
+the memory controller considers only cgroups belonging to the sub-tree
+of the OOM'ing cgroup.
+
+If there are no cgroups with the enabled memory controller,
+the OOM killer is using the "traditional" process-based approach.
+
+
 5-3. IO
 
 The "io" controller regulates the distribution of IO resources.  This
-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v7 1/5] mm, oom: refactor the oom_kill_process() function

[Roman Gushchin]

The oom_kill_process() function consists of two logical parts:
the first one is responsible for considering task's children as
a potential victim and printing the debug information.
The second half is responsible for sending SIGKILL to all
tasks sharing the mm struct with the given victim.

This commit splits the oom_kill_process() function with
an intention to re-use the the second half: __oom_kill_process().

The cgroup-aware OOM killer will kill multiple tasks
belonging to the victim cgroup. We don't need to print
the debug information for the each task, as well as play
with task selection (considering task's children),
so we can't use the existing oom_kill_process().

Signed-off-by: Roman Gushchin 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Tetsuo Handa 
Cc: David Rientjes 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
---
 mm/oom_kill.c | 123 +++---
 1 file changed, 65 insertions(+), 58 deletions(-)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 99736e026712..f061b627092c 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -804,68 +804,12 @@ static bool task_will_free_mem(struct task_struct *task)
return ret;
 }
 
-static void oom_kill_process(struct oom_control *oc, const char *message)
+static void __oom_kill_process(struct task_struct *victim)
 {
-   struct task_struct *p = oc->chosen;
-   unsigned int points = oc->chosen_points;
-   struct task_struct *victim = p;
-   struct task_struct *child;
-   struct task_struct *t;
+   struct task_struct *p;
struct mm_struct *mm;
-   unsigned int victim_points = 0;
-   static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
- DEFAULT_RATELIMIT_BURST);
bool can_oom_reap = true;
 
-   /*
-* If the task is already exiting, don't alarm the sysadmin or kill
-* its children or threads, just give it access to memory reserves
-* so it can die quickly
-*/
-   task_lock(p);
-   if (task_will_free_mem(p)) {
-   mark_oom_victim(p);
-   wake_oom_reaper(p);
-   task_unlock(p);
-   put_task_struct(p);
-   return;
-   }
-   task_unlock(p);
-
-   if (__ratelimit(_rs))
-   dump_header(oc, p);
-
-   pr_err("%s: Kill process %d (%s) score %u or sacrifice child\n",
-   message, task_pid_nr(p), p->comm, points);
-
-   /*
-* If any of p's children has a different mm and is eligible for kill,
-* the one with the highest oom_badness() score is sacrificed for its
-* parent.  This attempts to lose the minimal amount of work done while
-* still freeing memory.
-*/
-   read_lock(_lock);
-   for_each_thread(p, t) {
-   list_for_each_entry(child, >children, sibling) {
-   unsigned int child_points;
-
-   if (process_shares_mm(child, p->mm))
-   continue;
-   /*
-* oom_badness() returns 0 if the thread is unkillable
-*/
-   child_points = oom_badness(child,
-   oc->memcg, oc->nodemask, oc->totalpages);
-   if (child_points > victim_points) {
-   put_task_struct(victim);
-   victim = child;
-   victim_points = child_points;
-   get_task_struct(victim);
-   }
-   }
-   }
-   read_unlock(_lock);
-
p = find_lock_task_mm(victim);
if (!p) {
put_task_struct(victim);
@@ -939,6 +883,69 @@ static void oom_kill_process(struct oom_control *oc, const 
char *message)
 }
 #undef K
 
+static void oom_kill_process(struct oom_control *oc, const char *message)
+{
+   struct task_struct *p = oc->chosen;
+   unsigned int points = oc->chosen_points;
+   struct task_struct *victim = p;
+   struct task_struct *child;
+   struct task_struct *t;
+   unsigned int victim_points = 0;
+   static DEFINE_RATELIMIT_STATE(oom_rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
+
+   /*
+* If the task is already exiting, don't alarm the sysadmin or kill
+* its children or threads, just give it access to memory reserves
+* so it can die quickly
+*/
+   task_lock(p);
+   if (task_will_free_mem(p)) {
+   mark_oom_victim(p);
+  

[v7 0/5] cgroup-aware OOM killer

[Roman Gushchin]

This patchset makes the OOM killer cgroup-aware.

v7:
  - __oom_kill_process() drops reference to the victim task
  - oom_score_adj -1000 is always respected
  - Renamed oom_kill_all to oom_group
  - Dropped oom_prio range, converted from short to int
  - Added a cgroup v2 mount option to disable cgroup-aware OOM killer
  - Docs updated
  - Rebased on top of mmotm

v6:
  - Renamed oom_control.chosen to oom_control.chosen_task
  - Renamed oom_kill_all_tasks to oom_kill_all
  - Per-node NR_SLAB_UNRECLAIMABLE accounting
  - Several minor fixes and cleanups
  - Docs updated

v5:
  - Rebased on top of Michal Hocko's patches, which have changed the
way how OOM victims becoming an access to the memory
reserves. Dropped corresponding part of this patchset
  - Separated the oom_kill_process() splitting into a standalone commit
  - Added debug output (suggested by David Rientjes)
  - Some minor fixes

v4:
  - Reworked per-cgroup oom_score_adj into oom_priority
(based on ideas by David Rientjes)
  - Tasks with oom_score_adj -1000 are never selected if
oom_kill_all_tasks is not set
  - Memcg victim selection code is reworked, and
synchronization is based on finding tasks with OOM victim marker,
rather then on global counter
  - Debug output is dropped
  - Refactored TIF_MEMDIE usage

v3:
  - Merged commits 1-4 into 6
  - Separated oom_score_adj logic and debug output into separate commits
  - Fixed swap accounting

v2:
  - Reworked victim selection based on feedback
from Michal Hocko, Vladimir Davydov and Johannes Weiner
  - "Kill all tasks" is now an opt-in option, by default
only one process will be killed
  - Added per-cgroup oom_score_adj
  - Refined oom score calculations, suggested by Vladimir Davydov
  - Converted to a patchset

v1:
  https://lkml.org/lkml/2017/5/18/969


Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Tetsuo Handa 
Cc: David Rientjes 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org

Roman Gushchin (5):
  mm, oom: refactor the oom_kill_process() function
  mm, oom: cgroup-aware OOM killer
  mm, oom: introduce oom_priority for memory cgroups
  mm, oom, docs: describe the cgroup-aware OOM killer
  mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

 Documentation/admin-guide/kernel-parameters.txt |   1 +
 Documentation/cgroup-v2.txt |  56 +
 include/linux/memcontrol.h  |  36 +++
 include/linux/oom.h |  12 +-
 mm/memcontrol.c | 293 
 mm/oom_kill.c   | 209 +++--
 6 files changed, 537 insertions(+), 70 deletions(-)

-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[v7 3/5] mm, oom: introduce oom_priority for memory cgroups

[Roman Gushchin]

Introduce a per-memory-cgroup oom_priority setting: an integer number,
which defines the order in which the OOM killer selects victim memory
cgroups.

OOM killer prefers memory cgroups with larger priority if they are
populated with eligible tasks.

The oom_priority value is compared within sibling cgroups.

If two or more sibling cgroups have the same oom_priority,
the decision is based on their memory footprint.

The root cgroup has the oom_priority 0, which cannot be changed.

Signed-off-by: Roman Gushchin 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: David Rientjes 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: Tetsuo Handa 
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@kvack.org
---
 include/linux/memcontrol.h |  3 +++
 mm/memcontrol.c| 49 --
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 5b5c2b89968e..73a0291948fd 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -206,6 +206,9 @@ struct mem_cgroup {
/* cached OOM score */
long oom_score;
 
+   /* OOM killer priority */
+   int oom_priority;
+
/* handle for "memory.events" */
struct cgroup_file events_file;
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 97813c56163b..d7dd293897ca 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2757,6 +2757,7 @@ static void select_victim_memcg(struct mem_cgroup *root, 
struct oom_control *oc)
for (;;) {
struct cgroup_subsys_state *css;
struct mem_cgroup *memcg = NULL;
+   int prio = INT_MIN;
long score = LONG_MIN;
 
css_for_each_child(css, >css) {
@@ -2768,7 +2769,12 @@ static void select_victim_memcg(struct mem_cgroup *root, 
struct oom_control *oc)
if (iter->oom_score == 0)
continue;
 
-   if (iter->oom_score > score) {
+   if (iter->oom_priority > prio) {
+   memcg = iter;
+   prio = iter->oom_priority;
+   score = iter->oom_score;
+   } else if (iter->oom_priority == prio &&
+  iter->oom_score > score) {
memcg = iter;
score = iter->oom_score;
}
@@ -2838,7 +2844,15 @@ bool mem_cgroup_select_oom_victim(struct oom_control *oc)
 * For system-wide OOMs we should consider tasks in the root cgroup
 * with oom_score larger than oc->chosen_points.
 */
-   if (!oc->memcg) {
+   if (!oc->memcg && !(oc->chosen_memcg &&
+   oc->chosen_memcg->oom_priority > 0)) {
+   /*
+* Root memcg has priority 0, so if chosen memcg has lower
+* priority, any task in root cgroup is preferable.
+*/
+   if (oc->chosen_memcg && oc->chosen_memcg->oom_priority < 0)
+   oc->chosen_points = 0;
+
select_victim_root_cgroup_task(oc);
 
if (oc->chosen_task && oc->chosen_memcg) {
@@ -5480,6 +5494,31 @@ static ssize_t memory_oom_group_write(struct 
kernfs_open_file *of,
return nbytes;
 }
 
+static int memory_oom_priority_show(struct seq_file *m, void *v)
+{
+   struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
+
+   seq_printf(m, "%d\n", memcg->oom_priority);
+
+   return 0;
+}
+
+static ssize_t memory_oom_priority_write(struct kernfs_open_file *of,
+   char *buf, size_t nbytes, loff_t off)
+{
+   struct mem_cgroup *memcg = mem_cgroup_from_css(of_css(of));
+   int oom_priority;
+   int err;
+
+   err = kstrtoint(strstrip(buf), 0, _priority);
+   if (err)
+   return err;
+
+   memcg->oom_priority = oom_priority;
+
+   return nbytes;
+}
+
 static int memory_events_show(struct seq_file *m, void *v)
 {
struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
@@ -5606,6 +5645,12 @@ static struct cftype memory_files[] = {
.write = memory_oom_group_write,
},
{
+   .name = "oom_priority",
+   .flags = CFTYPE_NOT_ON_ROOT,
+   .seq_show = memory_oom_priority_show,
+   .write = memory_oom_priority_write,
+   },
+   {
.name = "events",
.flags = CFTYPE_NOT_ON_ROOT,
.file_offset = offsetof(struct mem_cgroup, events_file),
-- 
2.13.5

--
To unsubscribe from this list: send the 

[PATCH 1/2] media: ca docs: document CA_SET_DESCR ioctl and structs

[Mauro Carvalho Chehab]

The av7110 driver uses CA_SET_DESCR to store the descrambler
control words at the CA descrambler slots.

Document it.

Thanks-to: Honza Petrouš 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/ca-set-descr.rst | 15 ++-
 include/uapi/linux/dvb/ca.h   |  9 -
 2 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst 
b/Documentation/media/uapi/dvb/ca-set-descr.rst
index 9c484317d55c..a6c47205ffd8 100644
--- a/Documentation/media/uapi/dvb/ca-set-descr.rst
+++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
@@ -28,22 +28,11 @@ Arguments
 ``msg``
   Pointer to struct :c:type:`ca_descr`.
 
-.. c:type:: ca_descr
-
-.. code-block:: c
-
-struct ca_descr {
-   unsigned int index;
-   unsigned int parity;
-   unsigned char cw[8];
-};
-
-
 Description
 ---
 
-.. note:: This ioctl is undocumented. Documentation is welcome.
-
+CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
+keys (refered as control words).
 
 Return Value
 
diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
index f66ed53f4dc7..a62ddf0cebcd 100644
--- a/include/uapi/linux/dvb/ca.h
+++ b/include/uapi/linux/dvb/ca.h
@@ -109,9 +109,16 @@ struct ca_msg {
unsigned char msg[256];
 };
 
+/**
+ * struct ca_descr - CA descrambler control words info
+ *
+ * @index: CA Descrambler slot
+ * @parity: control words parity, where 0 means even and 1 means odd
+ * @cw: CA Descrambler control words
+ */
 struct ca_descr {
unsigned int index;
-   unsigned int parity;/* 0 == even, 1 == odd */
+   unsigned int parity;
unsigned char cw[8];
 };
 
-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] media: ca.h: document ca_msg and the corresponding ioctls

[Mauro Carvalho Chehab]

Usually, CA messages are sent/received via reading/writing at
the CA device node. However, two drivers (dst_ca and firedtv-ci)
also implement it via ioctls.

Apparently, on both cases, the net result is the same.

Anyway, let's document it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/dvb/ca-get-msg.rst  | 19 ++-
 Documentation/media/uapi/dvb/ca-send-msg.rst |  6 +-
 include/uapi/linux/dvb/ca.h  | 11 ++-
 3 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/Documentation/media/uapi/dvb/ca-get-msg.rst 
b/Documentation/media/uapi/dvb/ca-get-msg.rst
index bdb116552068..ceeda623ce93 100644
--- a/Documentation/media/uapi/dvb/ca-get-msg.rst
+++ b/Documentation/media/uapi/dvb/ca-get-msg.rst
@@ -28,22 +28,15 @@ Arguments
 ``msg``
   Pointer to struct :c:type:`ca_msg`.
 
-.. c:type:: ca_msg
-
-.. code-block:: c
-
-/* a message to/from a CI-CAM */
-struct ca_msg {
-   unsigned int index;
-   unsigned int type;
-   unsigned int length;
-   unsigned char msg[256];
-};
-
 Description
 ---
 
-.. note:: This ioctl is undocumented. Documentation is welcome.
+Receives a message via a CI CA module.
+
+.. note::
+
+   Please notice that, on most drivers, this is done by reading from
+   the /dev/adapter?/ca? device node.
 
 
 Return Value
diff --git a/Documentation/media/uapi/dvb/ca-send-msg.rst 
b/Documentation/media/uapi/dvb/ca-send-msg.rst
index 644b6bda1aea..9e91287b7bbc 100644
--- a/Documentation/media/uapi/dvb/ca-send-msg.rst
+++ b/Documentation/media/uapi/dvb/ca-send-msg.rst
@@ -32,8 +32,12 @@ Arguments
 Description
 ---
 
-.. note:: This ioctl is undocumented. Documentation is welcome.
+Sends a message via a CI CA module.
 
+.. note::
+
+   Please notice that, on most drivers, this is done by writing
+   to the /dev/adapter?/ca? device node.
 
 Return Value
 
diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
index a62ddf0cebcd..9bcd4cad497b 100644
--- a/include/uapi/linux/dvb/ca.h
+++ b/include/uapi/linux/dvb/ca.h
@@ -101,7 +101,16 @@ struct ca_caps {
unsigned int descr_type;
 };
 
-/* a message to/from a CI-CAM */
+/**
+ * struct ca_msg - a message to/from a CI-CAM
+ *
+ * @index: unused
+ * @type:  unused
+ * @length:length of the message
+ * @msg:   message
+ *
+ * This struct carries a message to be send/received from a CI CA module.
+ */
 struct ca_msg {
unsigned int index;
unsigned int type;
-- 
2.13.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

On Mon, Aug 21, 2017 at 01:21:24PM +0300, Yury Norov wrote:
> On Tue, Aug 08, 2017 at 02:34:11PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 24, 2017 at 02:26:24PM +0300, Yury Norov wrote:
> > > This is the 4.12 and linux-next - based kernel patches:
> > > https://github.com/norov/linux/tree/ilp32-4.12
> > > https://github.com/norov/linux/tree/ilp32-20170724
> > 
> > I published the 4.12 branch here:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=staging/ilp32-4.12
> > 
> > (or git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> > staging/ilp32-4.12)
> > 
> > There are two patches on top, one to fix SET_PERSONALITY and the other
> > to make ILP32 default y since you'd expect people using this branch to
> > need such option enabled.
> > 
> > I'll publish a 4.13-based branch when the corresponding kernel version
> > is released.
> 
> Hi Catalin,
> 
> This is the rc-6 based ilp32 series:
> https://github.com/norov/linux/tree/ilp32-4.13-rc6
> 
> It includes latest version of SET_PERSONALITY() rework:
> https://www.spinics.net/lists/arm-kernel/msg602005.html
> 
> All patches prior to 3fc85ee96eb8 ("arm64: ilp32: add documentation on
> the ILP32 ABI for ARM64") are looking not ilp32-specific and may be
> applied independently.
> 
> It also includes your patch "arm64: ilp32: Make the Kconfig option
> default y" on the top of series.
> 
> Yury

Hi Catalin, all,

This is 4.13-based and next-20170901-based ilp32 patches. 
https://github.com/norov/linux/tree/ilp32-4.13
https://github.com/norov/linux/tree/ilp32-20170901

Next-based series includes the patch that moves TASK_* definitions to


Also, Szabolcs has created arm/ilp32 branch for glibc.
https://sourceware.org/glibc/wiki/GlibcGit/arm_namespace

Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

Em Mon, 4 Sep 2017 11:40:59 +0200
Honza Petrouš  escreveu:

> > So, IMHO, the interface is broken by design. Perhaps that's
> > the reason why no upstream driver uses it.  
> 
> I have the same feeling regarding brokenness.
> 
> >
> > What seems to be a much better design would be to use the demux
> > set filter ioctls and route the PIDs to the right CA.
> >  
> 
> I don't have access to any programmer reference documentation
> for any modern DVB-enabled SoC, but I see two possible scenario
> of connecting descramblers to the demuxes (most of modern SoCs
> have more then one demux) - static one, when every demux has
> predefined descramblers already connected to it and dynamic ones,
> when any descrambler can be connected to the any demux.

I don't have access to the documentation either, but I know
some designs that have multiple demods that are dynamically set.
Some hardware even allow to dynamically change the maximum amount
of filters per demod at runtime.

> From that reason I vote to have some descrambler specific ioctl,
> which allow more flexibility then if we add it to the filter set ioctl.

I suspect that doing it at the demod does a lot more sense.

Anyway, someone should come with a driver requiring it upstream
for us to discuss and find the better alternatives to support.

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/15] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

Em Mon, 4 Sep 2017 02:55:15 +0200
Soeren Moch  escreveu:

> Hi Mauro,
> 
> On 01.09.2017 11:32, Mauro Carvalho Chehab wrote:
> > Em Fri, 1 Sep 2017 10:40:28 +0200
> > Honza Petrouš  escreveu:
> >  
> >> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab 
> >> :  
> >>> The DVB documentation was negligected for a long time, with
> >>> resulted on several gaps between the API description and its
> >>> documentation.
> >>>
> >>> I'm doing a new reading at the documentation. As result of it,
> >>> this series:
> >>>
> >>> - improves the introductory chapter, making it more generic;
> >>> - Do some adjustments at the frontend API, using kernel-doc
> >>>   when possible.
> >>> - Remove unused APIs at DVB demux. I suspect that the drivers
> >>>   implementing such APIs were either never merged upstream,
> >>>   or the API itself  were never used or was deprecated a long
> >>>   time ago. In any case, it doesn't make any sense to carry
> >>>   on APIs that aren't properly documented, nor are used on the
> >>>   upstream Kernel.
> >>>
> >>> With this patch series, the gap between documentation and
> >>> code is solved for 3 DVB APIs:
> >>>
> >>>   - Frontend API;
> >>>   - Demux API;
> >>>   - Net API.
> >>>
> >>> There is still a gap at the CA API that I'll try to address when I
> >>> have some time[1].
> >>>
> >>> [1] There's a gap also on the legacy audio, video and OSD APIs,
> >>> but, as those are used only by a single very old deprecated
> >>> hardware (av7110), it is probably not worth the efforts.
> >>>
> av7110 cards may be old, but there are still users of these cards. 
> For instance I'm watching TV received and decoded with such card in this 
> moment.
> So what do you mean with "deprecated hardware"?

Nobody is telling otherwise. What I mean by "deprecated" is that it is
not a product that you could got to a shop and buy a new one. Its 
production stopped a long time ago.

> >> I agree that av7110 is very very old piece of hw (but it is already
> >> in my hall of fame because of its Skystar 1 incarnation as
> >> first implementation of DVB in Linux) and it is sad that we still
> >> don't have at least one driver for any SoC with embedded DVB
> >> devices.  
> > Yeah, av7110 made history. Please notice that this series doesn't
> > remove any API that it is used by it. All it removes are the APIs
> > that there's no Kernel driver using.
> >
> > Carry on APIs without client is usually a very bad idea, as nobody
> > could be certain about how to use it. It is even worse when such
> > APIs are not properly documented (with is the case here).
> >  
> >> I understand that the main issue is that no any DVB-enabled
> >> SoC vendor is interested in upstreaming theirs code, but I still hope
> >> it will change in near future(*)  
> > We have one driver for a SoC DVB hardware at:
> > drivers/media/platform/sti/c8sectpfe/
> >
> > I guess it still doesn't cover the entire SoC, but this is a WiP. If I
> > remember well, at the midia part of the SoC, they started by submitting
> > the Remote Controller code.
> >  
> >> Without having full-featured DVB device in vanilla, we surely don't
> >> get some parts of DVB API covered. I can imagine that  when
> >> somebody comes with such full-featured device he wants to reinvent
> >> just removed bits.  
> > Re-adding the removed bits is easy. However, the API defined for
> > av7110 is old and it is showing its age: it assumes a limited number
> > of possible inputs/outputs. Modern SoC has a lot more ways link the
> > audio/video IP blocks than what the API provides. On a modern SoC,
> > not only DVB is supported, but also analog inputs (to support things
> > like composite input), cameras, HDMI inputs and even analog TV.
> > All of them interconnected to a media ISP. The current FF API can't
> > represent such hardware.
> >
> > The best API to represent those pipelines that exist on SoC for
> > multimedia is the media controller, where all IP blocks and their
> > links (whatever they are) can be represented, if needed.
> >
> > The audio and video DVB API is also too limited: it hasn't
> > evolved since when it was added. For audio, the ALSA API
> > allows a way more control of the hardware; for video, the
> > V4L2 API nowadays has all the bits to control video decoding
> > and encoding. Both APIs provide support for audio and video
> > inputs commonly found on those devices.  
> The real advantage of the DVB audio/video/osd API is the possibility
> of frame synchronous audio/video/overlay output for high-quality
> audio/video playback, maybe with picture-in-picture functionality.
> 
> Especially audio synchronization is not easy when the audio format
> changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on
> HDMI output. While HDMI output hardware usually takes video frames and
> audio packets (and AVI info frames for audio/video format signalization)
> synchronously, V4L2 and ALSA rip these 

Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap

[Honza Petrouš]

2017-09-04 11:06 GMT+02:00 Mauro Carvalho Chehab :
> Em Mon, 4 Sep 2017 09:12:49 +0200
> Honza Petrouš  escreveu:
>
>> 2017-09-04 2:54 GMT+02:00 Mauro Carvalho Chehab :
>> > Em Sun, 3 Sep 2017 22:05:23 +0200
>> > Honza Petrouš  escreveu:
>> >
>> >> 1) #define CA_SET_DESCR  _IOW('o', 134, ca_descr_t)
>> >> 
>> >>
>> >> CA_SET_DESCR is used for feeding descrambler device
>> >> with correct keys (called here "control words") what
>> >> allows to get services unscrambled.
>> >>
>> >> The best docu is:
>> >>
>> >> "Digital Video Broadcasting (DVB);
>> >> Support for use of the DVB Scrambling Algorithm version 3
>> >> within digital broadcasting systems"
>> >>
>> >> Defined as DVB Document A125 and publicly
>> >> available here:
>> >>
>> >> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
>> >>
>> >>
>> >> typedef struct ca_descr {
>> >> unsigned int index;
>> >> unsigned int parity;/* 0 == even, 1 == odd */
>> >> unsigned char cw[8];
>> >> } ca_descr_t;
>> >>
>> >> The 'index' is adress of the descrambler instance, as there exist
>> >> limited number of them (retieved by CA_GET_DESCR_INFO).
>> >
>> > Thanks for the info. If I understood well, the enclosed patch should
>> > be documenting it.
>> >
>> >
>> > Thanks,
>> > Mauro
>> >
>> > [PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
>> >
>> > The av7110 driver uses CA_SET_DESCR to store the descrambler
>> > control words at the CA descrambler slots.
>> >
>> > Document it.
>> >
>> > Thanks-to: Honza Petrouš 
>> > Signed-off-by: Mauro Carvalho Chehab 
>> >
>> > diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst 
>> > b/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > index 9c484317d55c..a6c47205ffd8 100644
>> > --- a/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
>> > @@ -28,22 +28,11 @@ Arguments
>> >  ``msg``
>> >Pointer to struct :c:type:`ca_descr`.
>> >
>> > -.. c:type:: ca_descr
>> > -
>> > -.. code-block:: c
>> > -
>> > -struct ca_descr {
>> > -   unsigned int index;
>> > -   unsigned int parity;
>> > -   unsigned char cw[8];
>> > -};
>> > -
>> > -
>> >  Description
>> >  ---
>> >
>> > -.. note:: This ioctl is undocumented. Documentation is welcome.
>> > -
>> > +CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
>> > +keys (refered as control words).
>> >
>> >  Return Value
>> >  
>> > diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
>> > index f66ed53f4dc7..a62ddf0cebcd 100644
>> > --- a/include/uapi/linux/dvb/ca.h
>> > +++ b/include/uapi/linux/dvb/ca.h
>> > @@ -109,9 +109,16 @@ struct ca_msg {
>> > unsigned char msg[256];
>> >  };
>> >
>> > +/**
>> > + * struct ca_descr - CA descrambler control words info
>> > + *
>> > + * @index: CA Descrambler slot
>> > + * @parity: control words parity, where 0 means even and 1 means odd
>> > + * @cw: CA Descrambler control words
>> > + */
>> >  struct ca_descr {
>> > unsigned int index;
>> > -   unsigned int parity;/* 0 == even, 1 == odd */
>> > +   unsigned int parity;
>> > unsigned char cw[8];
>> >  };
>> >
>> >
>>
>> Yeh, it should be that way.
>
> Good! I'll add this patch to the series.
>
>> BTW, the only issue I have in mind is how to link particular
>> descrambler with the PID
>> after your removal of the CA_SET_PID. And yes, I know that currently we have
>> no any user of such ioctl in our driver base :)
>
> Well, I don't think that an ioctl like CA_SET_PID would solve it.
>
> On a generic case with is quite common nowadays on embedded hardware,
> We have K demods and M CIs (where K may be different than M).
>
> Also, You may need to route N PIDs to O descramblers.

TBH that is exactly most common use-case = most Digital TV
vendors are scrambling per-service, what requires one descrambler
for all scrambled PIDs (usually only A/V PIDs are scrambled)
for particular service. So we have to add more PIDs to one descrambler

What was possible by multiple call of CA_SET_PID (I agree that much
better would be name like CA_ADD_PID)
>
> As user switch channels, the N PIDs should be unset, and another
> set of N' pids will be routed.
>
> CA_SET_PID allows to set just one PID, without identifying from
> what demod it would be received, and doesn't have a "reset"
> function to undo.

Here I can agree - it looks like the value -1 in 'index' should
do the job, but it, unfortunately, looses info from which descrambler
it should be removed (see note in struct ca_pid for value -1)

>
> So, IMHO, the interface is broken by design. Perhaps that's
> the reason why no upstream driver uses it.

I have the same feeling regarding brokenness.

>
> What seems to be a much better design would be to use the 

Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap

[Mauro Carvalho Chehab]

Em Mon, 4 Sep 2017 09:12:49 +0200
Honza Petrouš  escreveu:

> 2017-09-04 2:54 GMT+02:00 Mauro Carvalho Chehab :
> > Em Sun, 3 Sep 2017 22:05:23 +0200
> > Honza Petrouš  escreveu:
> >  
> >> 1) #define CA_SET_DESCR  _IOW('o', 134, ca_descr_t)
> >> 
> >>
> >> CA_SET_DESCR is used for feeding descrambler device
> >> with correct keys (called here "control words") what
> >> allows to get services unscrambled.
> >>
> >> The best docu is:
> >>
> >> "Digital Video Broadcasting (DVB);
> >> Support for use of the DVB Scrambling Algorithm version 3
> >> within digital broadcasting systems"
> >>
> >> Defined as DVB Document A125 and publicly
> >> available here:
> >>
> >> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
> >>
> >>
> >> typedef struct ca_descr {
> >> unsigned int index;
> >> unsigned int parity;/* 0 == even, 1 == odd */
> >> unsigned char cw[8];
> >> } ca_descr_t;
> >>
> >> The 'index' is adress of the descrambler instance, as there exist
> >> limited number of them (retieved by CA_GET_DESCR_INFO).  
> >
> > Thanks for the info. If I understood well, the enclosed patch should
> > be documenting it.
> >
> >
> > Thanks,
> > Mauro
> >
> > [PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
> >
> > The av7110 driver uses CA_SET_DESCR to store the descrambler
> > control words at the CA descrambler slots.
> >
> > Document it.
> >
> > Thanks-to: Honza Petrouš 
> > Signed-off-by: Mauro Carvalho Chehab 
> >
> > diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst 
> > b/Documentation/media/uapi/dvb/ca-set-descr.rst
> > index 9c484317d55c..a6c47205ffd8 100644
> > --- a/Documentation/media/uapi/dvb/ca-set-descr.rst
> > +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
> > @@ -28,22 +28,11 @@ Arguments
> >  ``msg``
> >Pointer to struct :c:type:`ca_descr`.
> >
> > -.. c:type:: ca_descr
> > -
> > -.. code-block:: c
> > -
> > -struct ca_descr {
> > -   unsigned int index;
> > -   unsigned int parity;
> > -   unsigned char cw[8];
> > -};
> > -
> > -
> >  Description
> >  ---
> >
> > -.. note:: This ioctl is undocumented. Documentation is welcome.
> > -
> > +CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
> > +keys (refered as control words).
> >
> >  Return Value
> >  
> > diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
> > index f66ed53f4dc7..a62ddf0cebcd 100644
> > --- a/include/uapi/linux/dvb/ca.h
> > +++ b/include/uapi/linux/dvb/ca.h
> > @@ -109,9 +109,16 @@ struct ca_msg {
> > unsigned char msg[256];
> >  };
> >
> > +/**
> > + * struct ca_descr - CA descrambler control words info
> > + *
> > + * @index: CA Descrambler slot
> > + * @parity: control words parity, where 0 means even and 1 means odd
> > + * @cw: CA Descrambler control words
> > + */
> >  struct ca_descr {
> > unsigned int index;
> > -   unsigned int parity;/* 0 == even, 1 == odd */
> > +   unsigned int parity;
> > unsigned char cw[8];
> >  };
> >
> >  
> 
> Yeh, it should be that way.

Good! I'll add this patch to the series.

> BTW, the only issue I have in mind is how to link particular
> descrambler with the PID
> after your removal of the CA_SET_PID. And yes, I know that currently we have
> no any user of such ioctl in our driver base :)

Well, I don't think that an ioctl like CA_SET_PID would solve it.

On a generic case with is quite common nowadays on embedded hardware,
We have K demods and M CIs (where K may be different than M).

Also, You may need to route N PIDs to O descramblers.

As user switch channels, the N PIDs should be unset, and another
set of N' pids will be routed.

CA_SET_PID allows to set just one PID, without identifying from
what demod it would be received, and doesn't have a "reset" 
function to undo.

So, IMHO, the interface is broken by design. Perhaps that's
the reason why no upstream driver uses it.

What seems to be a much better design would be to use the demux
set filter ioctls and route the PIDs to the right CA.


Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC

[icenowy]

在 2017-08-22 13:23，Icenowy Zheng 写道：

The compatible string for Allwinner V3s SoC used to be missing.

Add it to the binding document.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 


Maxime, Chen-Yu, ping.

Could you queue this patchset to 4.15?


---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
b/Documentation/devicetree/bindings/arm/sunxi.txt
index d2c46449b4eb..f35c6ada5a65 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
   nextthing,gr8

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/26] Improve DVB documentation and reduce its gap

[Honza Petrouš]

2017-09-04 2:54 GMT+02:00 Mauro Carvalho Chehab :
> Em Sun, 3 Sep 2017 22:05:23 +0200
> Honza Petrouš  escreveu:
>
>> 1) #define CA_SET_DESCR  _IOW('o', 134, ca_descr_t)
>> 
>>
>> CA_SET_DESCR is used for feeding descrambler device
>> with correct keys (called here "control words") what
>> allows to get services unscrambled.
>>
>> The best docu is:
>>
>> "Digital Video Broadcasting (DVB);
>> Support for use of the DVB Scrambling Algorithm version 3
>> within digital broadcasting systems"
>>
>> Defined as DVB Document A125 and publicly
>> available here:
>>
>> https://www.dvb.org/resources/public/standards/a125_dvb-csa3.pdf
>>
>>
>> typedef struct ca_descr {
>> unsigned int index;
>> unsigned int parity;/* 0 == even, 1 == odd */
>> unsigned char cw[8];
>> } ca_descr_t;
>>
>> The 'index' is adress of the descrambler instance, as there exist
>> limited number of them (retieved by CA_GET_DESCR_INFO).
>
> Thanks for the info. If I understood well, the enclosed patch should
> be documenting it.
>
>
> Thanks,
> Mauro
>
> [PATCH] media: ca docs: document CA_SET_DESCR ioctl and structs
>
> The av7110 driver uses CA_SET_DESCR to store the descrambler
> control words at the CA descrambler slots.
>
> Document it.
>
> Thanks-to: Honza Petrouš 
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/Documentation/media/uapi/dvb/ca-set-descr.rst 
> b/Documentation/media/uapi/dvb/ca-set-descr.rst
> index 9c484317d55c..a6c47205ffd8 100644
> --- a/Documentation/media/uapi/dvb/ca-set-descr.rst
> +++ b/Documentation/media/uapi/dvb/ca-set-descr.rst
> @@ -28,22 +28,11 @@ Arguments
>  ``msg``
>Pointer to struct :c:type:`ca_descr`.
>
> -.. c:type:: ca_descr
> -
> -.. code-block:: c
> -
> -struct ca_descr {
> -   unsigned int index;
> -   unsigned int parity;
> -   unsigned char cw[8];
> -};
> -
> -
>  Description
>  ---
>
> -.. note:: This ioctl is undocumented. Documentation is welcome.
> -
> +CA_SET_DESCR is used for feeding descrambler CA slots with descrambling
> +keys (refered as control words).
>
>  Return Value
>  
> diff --git a/include/uapi/linux/dvb/ca.h b/include/uapi/linux/dvb/ca.h
> index f66ed53f4dc7..a62ddf0cebcd 100644
> --- a/include/uapi/linux/dvb/ca.h
> +++ b/include/uapi/linux/dvb/ca.h
> @@ -109,9 +109,16 @@ struct ca_msg {
> unsigned char msg[256];
>  };
>
> +/**
> + * struct ca_descr - CA descrambler control words info
> + *
> + * @index: CA Descrambler slot
> + * @parity: control words parity, where 0 means even and 1 means odd
> + * @cw: CA Descrambler control words
> + */
>  struct ca_descr {
> unsigned int index;
> -   unsigned int parity;/* 0 == even, 1 == odd */
> +   unsigned int parity;
> unsigned char cw[8];
>  };
>
>

Yeh, it should be that way.

BTW, the only issue I have in mind is how to link particular
descrambler with the PID
after your removal of the CA_SET_PID. And yes, I know that currently we have
no any user of such ioctl in our driver base :)

/Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html