* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Eric Dumazet @ 2020-02-14 23:12 UTC (permalink / raw)
To: Shakeel Butt
Cc: Johannes Weiner, Tejun Heo, Greg Thelen, Michal Hocko,
Vladimir Davydov, Andrew Morton, Cgroups, linux-mm,
Roman Gushchin, LKML
In-Reply-To: <CALvZod5RoE3V7HteKqqDEfCgY8pDok6PWHrpu8trB1vyuK2UHA@mail.gmail.com>
On Fri, Feb 14, 2020 at 2:48 PM Shakeel Butt <shakeelb@google.com> wrote:
>
> I think in the current code if the association is skipped at
> allocation time then the sock will remain unassociated for its
> lifetime.
>
> Maybe we can add the association in the later stages but it seems like
> it is not a simple task i.e. edbe69ef2c90f ("Revert "defer call to
> mem_cgroup_sk_alloc()"").
Half TCP sockets are passive, so this means that 50% of TCP sockets
won't be charged.
(the socket cloning always happens from BH context)
I think this deserves a comment in the changelog or documentation,
otherwise some people might think
using memcg will make them safe.
^ permalink raw reply
* Re: [PATCH v4 6/6] coresight: docs: Add information about the topology representations.
From: Mathieu Poirier @ 2020-02-14 23:10 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, suzuki.poulose, linux-arm-kernel, linux-doc
In-Reply-To: <20200211105808.27884-7-mike.leach@linaro.org>
On Tue, Feb 11, 2020 at 10:58:08AM +0000, Mike Leach wrote:
> Update the CoreSight documents to describe the new connections directory
> and the links between CoreSight devices in this directory.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../trace/coresight/coresight-ect.rst | 5 +-
> Documentation/trace/coresight/coresight.rst | 85 +++++++++++++++++++
> 2 files changed, 89 insertions(+), 1 deletion(-)
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/Documentation/trace/coresight/coresight-ect.rst b/Documentation/trace/coresight/coresight-ect.rst
> index 067cee91c857..3539af895832 100644
> --- a/Documentation/trace/coresight/coresight-ect.rst
> +++ b/Documentation/trace/coresight/coresight-ect.rst
> @@ -71,7 +71,7 @@ capable of generating or using trigger signals.::
>
> >$ ls /sys/bus/coresight/devices/etm0/cti_cpu0
> channels ctmid enable nr_trigger_cons mgmt power regs subsystem
> - triggers0 triggers1 uevent
> + connections triggers0 triggers1 uevent
>
> *Key file items are:-*
> * ``enable``: enables/disables the CTI.
> @@ -84,6 +84,9 @@ capable of generating or using trigger signals.::
> * ``channels``: Contains the channel API - CTI main programming interface.
> * ``regs``: Gives access to the raw programmable CTI regs.
> * ``mgmt``: the standard CoreSight management registers.
> + * ``connections``: Links to connected *CoreSight* devices. The number of
> + links can be 0 to ``nr_trigger_cons``. Actual number given by ``nr_links``
> + in this directory.
>
>
> triggers<N> directories
> diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
> index 108600ee1e12..0b73acb44efa 100644
> --- a/Documentation/trace/coresight/coresight.rst
> +++ b/Documentation/trace/coresight/coresight.rst
> @@ -241,6 +241,91 @@ to the newer scheme, to give a confirmation that what you see on your
> system is not unexpected. One must use the "names" as they appear on
> the system under specified locations.
>
> +Topology Representation
> +-----------------------
> +
> +Each CoreSight component has a ``connections`` directory which will contain
> +links to other CoreSight components. This allows the user to explore the trace
> +topology and for larger systems, determine the most appropriate sink for a
> +given source. The connection information can also be used to establish
> +which CTI devices are connected to a given component. This directory contains a
> +``nr_links`` attribute detailing the number of links in the directory.
> +
> +For an ETM source, in this case ``etm0`` on a Juno platform, a typical
> +arrangement will be::
> +
> + linaro-developer:~# ls - l /sys/bus/coresight/devices/etm0/connections
> + <file details> cti_cpu0 -> ../../../23020000.cti/cti_cpu0
> + <file details> nr_links
> + <file details> out:0 -> ../../../230c0000.funnel/funnel2
> +
> +Following the out port to ``funnel2``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel2/connections
> + <file details> in:0 -> ../../../23040000.etm/etm0
> + <file details> in:1 -> ../../../23140000.etm/etm3
> + <file details> in:2 -> ../../../23240000.etm/etm4
> + <file details> in:3 -> ../../../23340000.etm/etm5
> + <file details> nr_links
> + <file details> out:0 -> ../../../20040000.funnel/funnel0
> +
> +And again to ``funnel0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel0/connections
> + <file details> in:0 -> ../../../220c0000.funnel/funnel1
> + <file details> in:1 -> ../../../230c0000.funnel/funnel2
> + <file details> nr_links
> + <file details> out:0 -> ../../../20010000.etf/tmc_etf0
> +
> +Finding the first sink ``tmc_etf0``. This can be used to collect data
> +as a sink, or as a link to propagate further along the chain::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etf0/connections
> + <file details> cti_sys0 -> ../../../20020000.cti/cti_sys0
> + <file details> in:0 -> ../../../20040000.funnel/funnel0
> + <file details> nr_links
> + <file details> out:0 -> ../../../20150000.funnel/funnel4
> +
> +via ``funnel4``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel4/connections
> + <file details> in:0 -> ../../../20010000.etf/tmc_etf0
> + <file details> in:1 -> ../../../20140000.etf/tmc_etf1
> + <file details> nr_links
> + <file details> out:0 -> ../../../20120000.replicator/replicator0
> +
> +and a ``replicator0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/replicator0/connections
> + <file details> in:0 -> ../../../20150000.funnel/funnel4
> + <file details> nr_links
> + <file details> out:0 -> ../../../20030000.tpiu/tpiu0
> + <file details> out:1 -> ../../../20070000.etr/tmc_etr0
> +
> +Arriving at the final sink in the chain, ``tmc_etr0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etr0/connections
> + <file details> cti_sys0 -> ../../../20020000.cti/cti_sys0
> + <file details> in:0 -> ../../../20120000.replicator/replicator0
> + <file details> nr_links
> +
> +As described below, when using sysfs it is sufficient to enable a sink and
> +a source for successful trace. The framework will correctly enable all
> +intermediate links as required.
> +
> +Note: ``cti_sys0`` appears in two of the connections lists above.
> +CTIs can connect to multiple devices and are arranged in a star topology
> +via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details.
> +Looking at this device we see 4 connections::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections
> + <file details> nr_links
> + <file details> stm0 -> ../../../20100000.stm/stm0
> + <file details> tmc_etf0 -> ../../../20010000.etf/tmc_etf0
> + <file details> tmc_etr0 -> ../../../20070000.etr/tmc_etr0
> + <file details> tpiu0 -> ../../../20030000.tpiu/tpiu0
> +
> +
> How to use the tracer modules
> -----------------------------
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 6/6] coresight: docs: Add information about the topology representations.
From: Mathieu Poirier @ 2020-02-14 23:10 UTC (permalink / raw)
To: Mike Leach; +Cc: linux-arm-kernel, coresight, linux-doc, suzuki.poulose
In-Reply-To: <20200211105808.27884-7-mike.leach@linaro.org>
On Tue, Feb 11, 2020 at 10:58:08AM +0000, Mike Leach wrote:
> Update the CoreSight documents to describe the new connections directory
> and the links between CoreSight devices in this directory.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../trace/coresight/coresight-ect.rst | 5 +-
> Documentation/trace/coresight/coresight.rst | 85 +++++++++++++++++++
> 2 files changed, 89 insertions(+), 1 deletion(-)
>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> diff --git a/Documentation/trace/coresight/coresight-ect.rst b/Documentation/trace/coresight/coresight-ect.rst
> index 067cee91c857..3539af895832 100644
> --- a/Documentation/trace/coresight/coresight-ect.rst
> +++ b/Documentation/trace/coresight/coresight-ect.rst
> @@ -71,7 +71,7 @@ capable of generating or using trigger signals.::
>
> >$ ls /sys/bus/coresight/devices/etm0/cti_cpu0
> channels ctmid enable nr_trigger_cons mgmt power regs subsystem
> - triggers0 triggers1 uevent
> + connections triggers0 triggers1 uevent
>
> *Key file items are:-*
> * ``enable``: enables/disables the CTI.
> @@ -84,6 +84,9 @@ capable of generating or using trigger signals.::
> * ``channels``: Contains the channel API - CTI main programming interface.
> * ``regs``: Gives access to the raw programmable CTI regs.
> * ``mgmt``: the standard CoreSight management registers.
> + * ``connections``: Links to connected *CoreSight* devices. The number of
> + links can be 0 to ``nr_trigger_cons``. Actual number given by ``nr_links``
> + in this directory.
>
>
> triggers<N> directories
> diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst
> index 108600ee1e12..0b73acb44efa 100644
> --- a/Documentation/trace/coresight/coresight.rst
> +++ b/Documentation/trace/coresight/coresight.rst
> @@ -241,6 +241,91 @@ to the newer scheme, to give a confirmation that what you see on your
> system is not unexpected. One must use the "names" as they appear on
> the system under specified locations.
>
> +Topology Representation
> +-----------------------
> +
> +Each CoreSight component has a ``connections`` directory which will contain
> +links to other CoreSight components. This allows the user to explore the trace
> +topology and for larger systems, determine the most appropriate sink for a
> +given source. The connection information can also be used to establish
> +which CTI devices are connected to a given component. This directory contains a
> +``nr_links`` attribute detailing the number of links in the directory.
> +
> +For an ETM source, in this case ``etm0`` on a Juno platform, a typical
> +arrangement will be::
> +
> + linaro-developer:~# ls - l /sys/bus/coresight/devices/etm0/connections
> + <file details> cti_cpu0 -> ../../../23020000.cti/cti_cpu0
> + <file details> nr_links
> + <file details> out:0 -> ../../../230c0000.funnel/funnel2
> +
> +Following the out port to ``funnel2``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel2/connections
> + <file details> in:0 -> ../../../23040000.etm/etm0
> + <file details> in:1 -> ../../../23140000.etm/etm3
> + <file details> in:2 -> ../../../23240000.etm/etm4
> + <file details> in:3 -> ../../../23340000.etm/etm5
> + <file details> nr_links
> + <file details> out:0 -> ../../../20040000.funnel/funnel0
> +
> +And again to ``funnel0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel0/connections
> + <file details> in:0 -> ../../../220c0000.funnel/funnel1
> + <file details> in:1 -> ../../../230c0000.funnel/funnel2
> + <file details> nr_links
> + <file details> out:0 -> ../../../20010000.etf/tmc_etf0
> +
> +Finding the first sink ``tmc_etf0``. This can be used to collect data
> +as a sink, or as a link to propagate further along the chain::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etf0/connections
> + <file details> cti_sys0 -> ../../../20020000.cti/cti_sys0
> + <file details> in:0 -> ../../../20040000.funnel/funnel0
> + <file details> nr_links
> + <file details> out:0 -> ../../../20150000.funnel/funnel4
> +
> +via ``funnel4``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel4/connections
> + <file details> in:0 -> ../../../20010000.etf/tmc_etf0
> + <file details> in:1 -> ../../../20140000.etf/tmc_etf1
> + <file details> nr_links
> + <file details> out:0 -> ../../../20120000.replicator/replicator0
> +
> +and a ``replicator0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/replicator0/connections
> + <file details> in:0 -> ../../../20150000.funnel/funnel4
> + <file details> nr_links
> + <file details> out:0 -> ../../../20030000.tpiu/tpiu0
> + <file details> out:1 -> ../../../20070000.etr/tmc_etr0
> +
> +Arriving at the final sink in the chain, ``tmc_etr0``::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etr0/connections
> + <file details> cti_sys0 -> ../../../20020000.cti/cti_sys0
> + <file details> in:0 -> ../../../20120000.replicator/replicator0
> + <file details> nr_links
> +
> +As described below, when using sysfs it is sufficient to enable a sink and
> +a source for successful trace. The framework will correctly enable all
> +intermediate links as required.
> +
> +Note: ``cti_sys0`` appears in two of the connections lists above.
> +CTIs can connect to multiple devices and are arranged in a star topology
> +via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details.
> +Looking at this device we see 4 connections::
> +
> + linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections
> + <file details> nr_links
> + <file details> stm0 -> ../../../20100000.stm/stm0
> + <file details> tmc_etf0 -> ../../../20010000.etf/tmc_etf0
> + <file details> tmc_etr0 -> ../../../20070000.etr/tmc_etr0
> + <file details> tpiu0 -> ../../../20030000.tpiu/tpiu0
> +
> +
> How to use the tracer modules
> -----------------------------
>
> --
> 2.17.1
>
^ permalink raw reply
* [meta-python][PATCH v2] python3-cffi: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 23:08 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-cffi.inc | 17 -----------------
.../python/python3-cffi_1.14.0.bb | 19 ++++++++++++++++++-
2 files changed, 18 insertions(+), 18 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-cffi.inc
diff --git a/meta-python/recipes-devtools/python/python-cffi.inc b/meta-python/recipes-devtools/python/python-cffi.inc
deleted file mode 100644
index af10c5f36d..0000000000
--- a/meta-python/recipes-devtools/python/python-cffi.inc
+++ /dev/null
@@ -1,17 +0,0 @@
-SUMMARY = "Foreign Function Interface for Python calling C code"
-HOMEPAGE = "http://cffi.readthedocs.org/"
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
-DEPENDS += "libffi ${PYTHON_PN}-pycparser"
-
-SRC_URI[md5sum] = "74845f8d2b7b583dd9a3574f402edf39"
-SRC_URI[sha256sum] = "2d384f4a127a15ba701207f7639d94106693b6cd64173d6c8988e2c25f3ac2b6"
-
-RDEPENDS_${PN}_class-target = " \
- ${PYTHON_PN}-ctypes \
- ${PYTHON_PN}-io \
- ${PYTHON_PN}-pycparser \
- ${PYTHON_PN}-shell \
-"
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-cffi_1.14.0.bb b/meta-python/recipes-devtools/python/python3-cffi_1.14.0.bb
index e888084347..53c8ee2650 100644
--- a/meta-python/recipes-devtools/python/python3-cffi_1.14.0.bb
+++ b/meta-python/recipes-devtools/python/python3-cffi_1.14.0.bb
@@ -1,2 +1,19 @@
+SUMMARY = "Foreign Function Interface for Python calling C code"
+HOMEPAGE = "http://cffi.readthedocs.org/"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
+DEPENDS += "libffi ${PYTHON_PN}-pycparser"
+
+SRC_URI[md5sum] = "74845f8d2b7b583dd9a3574f402edf39"
+SRC_URI[sha256sum] = "2d384f4a127a15ba701207f7639d94106693b6cd64173d6c8988e2c25f3ac2b6"
+
inherit pypi setuptools3
-require python-cffi.inc
+
+RDEPENDS_${PN}_class-target = " \
+ ${PYTHON_PN}-ctypes \
+ ${PYTHON_PN}-io \
+ ${PYTHON_PN}-pycparser \
+ ${PYTHON_PN}-shell \
+"
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* [PATCH 3/3] credential: allow wildcard patterns when matching config
From: brian m. carlson @ 2020-02-14 22:59 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20200214225929.541306-1-sandals@crustytoothpaste.net>
From: brian m. carlson <bk2204@github.com>
In some cases, a user will want to use a specific credential helper for
a wildcard pattern, such as https://*.corp.example.com. Use the urlmatch
code to match a pattern for a URL to allow this behavior.
Since we are handling URLs using urlmatch, remove the custom code to
match URLs, since it is no longer needed.
Signed-off-by: brian m. carlson <bk2204@github.com>
---
Documentation/gitcredentials.txt | 4 +++-
credential.c | 41 +++++++++++++++++---------------
t/t0300-credentials.sh | 20 ++++++++++++++++
3 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt
index ea759fdee5..12cb032352 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/gitcredentials.txt
@@ -131,7 +131,9 @@ context would not match:
because the hostnames differ. Nor would it match `foo.example.com`; Git
compares hostnames exactly, without considering whether two hosts are part of
the same domain. Likewise, a config entry for `http://example.com` would not
-match: Git compares the protocols exactly.
+match: Git compares the protocols exactly. However, you may use wildcards in
+the domain name and other pattern matching techniques as with the `http.<url>.*`
+options.
If the "pattern" URL does include a path component, then this too must match
exactly: the context `https://example.com/bar/baz.git` will match a config
diff --git a/credential.c b/credential.c
index 62be651b03..08904e247f 100644
--- a/credential.c
+++ b/credential.c
@@ -6,6 +6,7 @@
#include "url.h"
#include "prompt.h"
#include "sigchain.h"
+#include "urlmatch.h"
void credential_init(struct credential *c)
{
@@ -40,7 +41,7 @@ static int credential_config_callback(const char *var, const char *value,
void *data)
{
struct credential *c = data;
- const char *key, *dot;
+ const char *key;
if (!skip_prefix(var, "credential.", &key))
return 0;
@@ -48,23 +49,6 @@ static int credential_config_callback(const char *var, const char *value,
if (!value)
return config_error_nonbool(var);
- dot = strrchr(key, '.');
- if (dot) {
- struct credential want = CREDENTIAL_INIT;
- char *url = xmemdupz(key, dot - key);
- int matched;
-
- credential_from_url(&want, url);
- matched = credential_match(&want, c);
-
- credential_clear(&want);
- free(url);
-
- if (!matched)
- return 0;
- key = dot + 1;
- }
-
if (!strcmp(key, "helper")) {
if (*value)
string_list_append(&c->helpers, value);
@@ -87,11 +71,30 @@ static int proto_is_http(const char *s)
return !strcmp(s, "https") || !strcmp(s, "http");
}
+static void credential_describe(struct credential *c, struct strbuf *out);
+
static void credential_apply_config(struct credential *c)
{
+ char *normalized_url;
+ struct urlmatch_config config = { STRING_LIST_INIT_DUP };
+ struct strbuf url = STRBUF_INIT;
+
if (c->configured)
return;
- git_config(credential_config_callback, c);
+
+ config.section = "credential";
+ config.key = NULL;
+ config.collect_fn = credential_config_callback;
+ config.cascade_fn = git_default_config;
+ config.cb = c;
+
+ credential_describe(c, &url);
+ normalized_url = url_normalize(url.buf, &config.url);
+
+ git_config(urlmatch_config_entry, &config);
+ free(normalized_url);
+ strbuf_release(&url);
+
c->configured = 1;
if (!c->use_http_path && proto_is_http(c->protocol)) {
diff --git a/t/t0300-credentials.sh b/t/t0300-credentials.sh
index 82eaaea0f4..516b3268f9 100755
--- a/t/t0300-credentials.sh
+++ b/t/t0300-credentials.sh
@@ -289,6 +289,26 @@ test_expect_success 'http paths can be part of context' '
EOF
'
+test_expect_success 'context uses urlmatch' '
+ test_config "credential.https://*.org.useHttpPath" true &&
+ check fill "verbatim foo bar" <<-\EOF
+ protocol=https
+ host=example.org
+ path=foo.git
+ --
+ protocol=https
+ host=example.org
+ path=foo.git
+ username=foo
+ password=bar
+ --
+ verbatim: get
+ verbatim: protocol=https
+ verbatim: host=example.org
+ verbatim: path=foo.git
+ EOF
+'
+
test_expect_success 'helpers can abort the process' '
test_must_fail git \
-c credential.helper="!f() { echo quit=1; }; f" \
^ permalink raw reply related
* [PATCH 2/3] t1300: add test for urlmatch with multiple wildcards
From: brian m. carlson @ 2020-02-14 22:59 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20200214225929.541306-1-sandals@crustytoothpaste.net>
From: brian m. carlson <bk2204@github.com>
Our urlmatch code handles multiple wildcards, but we don't currently
have a test that checks this code path. Add a test that we handle this
case correctly to avoid any regressions.
Signed-off-by: brian m. carlson <bk2204@github.com>
---
t/t1300-config.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 983a0a1583..8b0cac80a3 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -1408,6 +1408,8 @@ test_expect_success 'urlmatch favors more specific URLs' '
cookieFile = /tmp/wildcard.txt
[http "https://*.example.com/wildcardwithsubdomain"]
cookieFile = /tmp/wildcardwithsubdomain.txt
+ [http "https://*.example.*"]
+ cookieFile = /tmp/multiwildcard.txt
[http "https://trailing.example.com"]
cookieFile = /tmp/trailing.txt
[http "https://user@*.example.com/"]
@@ -1454,6 +1456,10 @@ test_expect_success 'urlmatch favors more specific URLs' '
echo http.cookiefile /tmp/sub.txt >expect &&
git config --get-urlmatch HTTP https://user@sub.example.com >actual &&
+ test_cmp expect actual &&
+
+ echo http.cookiefile /tmp/multiwildcard.txt >expect &&
+ git config --get-urlmatch HTTP https://wildcard.example.org >actual &&
test_cmp expect actual
'
^ permalink raw reply related
* [PATCH 0/3] Wildcard matching for credentials
From: brian m. carlson @ 2020-02-14 22:59 UTC (permalink / raw)
To: git; +Cc: Jeff King
This series introduces wildcard matching (that is, urlmatch support) for
credential config options, just like for the http options. This is
helpful in corporate environments where custom credentials should be
used across a wide variety of subdomains.
In addition, there's an additional test for urlmatch behavior with
multiple subdomains and a mailmap update for the email address used in
this series.
brian m. carlson (3):
mailmap: add an additional email address for brian m. carlson
t1300: add test for urlmatch with multiple wildcards
credential: allow wildcard patterns when matching config
.mailmap | 1 +
Documentation/gitcredentials.txt | 4 +++-
credential.c | 41 +++++++++++++++++---------------
t/t0300-credentials.sh | 20 ++++++++++++++++
t/t1300-config.sh | 6 +++++
5 files changed, 52 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH 1/3] mailmap: add an additional email address for brian m. carlson
From: brian m. carlson @ 2020-02-14 22:59 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20200214225929.541306-1-sandals@crustytoothpaste.net>
From: brian m. carlson <bk2204@github.com>
To more accurately track the provenance of contributions, brian uses a
work email address for commits created at work. Add this email address
to .mailmap so that contributions are properly attributed to the same
person.
Signed-off-by: brian m. carlson <bk2204@github.com>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 73fd92e192..bde7aba756 100644
--- a/.mailmap
+++ b/.mailmap
@@ -31,6 +31,7 @@ Brandon Casey <drafnel@gmail.com> <casey@nrlssc.navy.mil>
Brandon Williams <bwilliams.eng@gmail.com> <bmwill@google.com>
brian m. carlson <sandals@crustytoothpaste.net>
brian m. carlson <sandals@crustytoothpaste.net> <sandals@crustytoothpaste.ath.cx>
+brian m. carlson <sandals@crustytoothpaste.net> <bk2204@github.com>
Bryan Larsen <bryan@larsen.st> <bryan.larsen@gmail.com>
Bryan Larsen <bryan@larsen.st> <bryanlarsen@yahoo.com>
Cheng Renquan <crquan@gmail.com>
^ permalink raw reply related
* Re: [yocto] #sdk #toolchain #yocto
From: Khem Raj @ 2020-02-14 23:07 UTC (permalink / raw)
To: amern2k16, yocto
In-Reply-To: <Igxp.1581697611359538979.oZvW@lists.yoctoproject.org>
On 2/14/20 8:26 AM, amern2k16@att.net wrote:
> In Yocto Project Application Development and the Extensible Software
> Development Kit(eSDK) Manual, Appendix A.2. 6. Building an SDK
> Installer says the following:
> "To build the SDK installer for a standard SDK and populate the SDK image"
> what do they mean by "populate the SDK image" ?
> After running 'bitbake image -c populate_sdk' command, sdk folder was
> created in my build/tmp/deploy/sdk. In this folder there is .sh
> script. This script
> is SDK installer but what do they mean by 'and populate the SDK
> image'? What SDK image?
>
sdk installer - The container ( .sh file)
SDK image - Content inside the installer ( SDK files which you see upon
SDK installation)
>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
From: Dan Williams @ 2020-02-14 23:05 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-nvdimm, Aneesh Kumar K.V, Linux Kernel Mailing List,
Paul Mackerras, Vishal L Verma, linuxppc-dev
In-Reply-To: <x49k14odgwz.fsf@segfault.boston.devel.redhat.com>
On Fri, Feb 14, 2020 at 12:59 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> >> I have just a couple of questions.
> >>
> >> First, can you please add a comment above the generic implementation of
> >> memremap_compat_align describing its purpose, and why a platform might
> >> want to override it?
> >
> > Sure, how about:
> >
> > /*
> > * The memremap() and memremap_pages() interfaces are alternately used
> > * to map persistent memory namespaces. These interfaces place different
> > * constraints on the alignment and size of the mapping (namespace).
> > * memremap() can map individual PAGE_SIZE pages. memremap_pages() can
> > * only map subsections (2MB), and at least one architecture (PowerPC)
> > * the minimum mapping granularity of memremap_pages() is 16MB.
> > *
> > * The role of memremap_compat_align() is to communicate the minimum
> > * arch supported alignment of a namespace such that it can freely
> > * switch modes without violating the arch constraint. Namely, do not
> > * allow a namespace to be PAGE_SIZE aligned since that namespace may be
> > * reconfigured into a mode that requires SUBSECTION_SIZE alignment.
> > */
>
> Well, if we modify the x86 variant to be PAGE_SIZE, I think that text
> won't work. How about:
...but I'm not looking to change it to PAGE_SIZE, I'm going to fix the
alignment check to skip if the namespace has "inner" alignment
padding, i.e. "start_pad" and/or "end_trunc" are non-zero.
^ permalink raw reply
* [RFC PATCH] iommu/iova: Add a best-fit algorithm
From: Isaac J. Manjarres @ 2020-02-14 23:06 UTC (permalink / raw)
To: iommu, linux-kernel; +Cc: Isaac J. Manjarres, kernel-team, pratikp, Liam Mark
From: Liam Mark <lmark@codeaurora.org>
Using the best-fit algorithm, instead of the first-fit
algorithm, may reduce fragmentation when allocating
IOVAs.
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
---
drivers/iommu/dma-iommu.c | 17 +++++++++++
drivers/iommu/iova.c | 73 +++++++++++++++++++++++++++++++++++++++++++++--
include/linux/dma-iommu.h | 7 +++++
include/linux/iova.h | 1 +
4 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a2e96a5..af08770 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -364,9 +364,26 @@ static int iommu_dma_deferred_attach(struct device *dev,
if (unlikely(ops->is_attach_deferred &&
ops->is_attach_deferred(domain, dev)))
return iommu_attach_device(domain, dev);
+ return 0;
+}
+
+/*
+ * Should be called prior to using dma-apis.
+ */
+int iommu_dma_enable_best_fit_algo(struct device *dev)
+{
+ struct iommu_domain *domain;
+ struct iova_domain *iovad;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain || !domain->iova_cookie)
+ return -EINVAL;
+ iovad = &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad;
+ iovad->best_fit = true;
return 0;
}
+EXPORT_SYMBOL(iommu_dma_enable_best_fit_algo);
/**
* dma_info_to_prot - Translate DMA API directions and attributes to IOMMU API
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a953..716b05f 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -50,6 +50,7 @@ static unsigned long iova_rcache_get(struct iova_domain *iovad,
iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR;
rb_link_node(&iovad->anchor.node, NULL, &iovad->rbroot.rb_node);
rb_insert_color(&iovad->anchor.node, &iovad->rbroot);
+ iovad->best_fit = false;
init_iova_rcaches(iovad);
}
EXPORT_SYMBOL_GPL(init_iova_domain);
@@ -227,6 +228,69 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
return -ENOMEM;
}
+static int __alloc_and_insert_iova_best_fit(struct iova_domain *iovad,
+ unsigned long size, unsigned long limit_pfn,
+ struct iova *new, bool size_aligned)
+{
+ struct rb_node *curr, *prev;
+ struct iova *curr_iova, *prev_iova;
+ unsigned long flags;
+ unsigned long align_mask = ~0UL;
+ struct rb_node *candidate_rb_parent;
+ unsigned long new_pfn, candidate_pfn = ~0UL;
+ unsigned long gap, candidate_gap = ~0UL;
+
+ if (size_aligned)
+ align_mask <<= limit_align(iovad, fls_long(size - 1));
+
+ /* Walk the tree backwards */
+ spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
+ curr = &iovad->anchor.node;
+ prev = rb_prev(curr);
+ for (; prev; curr = prev, prev = rb_prev(curr)) {
+ curr_iova = rb_entry(curr, struct iova, node);
+ prev_iova = rb_entry(prev, struct iova, node);
+
+ limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
+ new_pfn = (limit_pfn - size) & align_mask;
+ gap = curr_iova->pfn_lo - prev_iova->pfn_hi - 1;
+ if ((limit_pfn >= size) && (new_pfn > prev_iova->pfn_hi)
+ && (gap < candidate_gap)) {
+ candidate_gap = gap;
+ candidate_pfn = new_pfn;
+ candidate_rb_parent = curr;
+ if (gap == size)
+ goto insert;
+ }
+ }
+
+ curr_iova = rb_entry(curr, struct iova, node);
+ limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
+ new_pfn = (limit_pfn - size) & align_mask;
+ gap = curr_iova->pfn_lo - iovad->start_pfn;
+ if (limit_pfn >= size && new_pfn >= iovad->start_pfn &&
+ gap < candidate_gap) {
+ candidate_gap = gap;
+ candidate_pfn = new_pfn;
+ candidate_rb_parent = curr;
+ }
+
+insert:
+ if (candidate_pfn == ~0UL) {
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return -ENOMEM;
+ }
+
+ /* pfn_lo will point to size aligned address if size_aligned is set */
+ new->pfn_lo = candidate_pfn;
+ new->pfn_hi = new->pfn_lo + size - 1;
+
+ /* If we have 'prev', it's a valid place to start the insertion. */
+ iova_insert_rbtree(&iovad->rbroot, new, candidate_rb_parent);
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return 0;
+}
+
static struct kmem_cache *iova_cache;
static unsigned int iova_cache_users;
static DEFINE_MUTEX(iova_cache_mutex);
@@ -302,8 +366,13 @@ struct iova *
if (!new_iova)
return NULL;
- ret = __alloc_and_insert_iova_range(iovad, size, limit_pfn + 1,
- new_iova, size_aligned);
+ if (iovad->best_fit) {
+ ret = __alloc_and_insert_iova_best_fit(iovad, size,
+ limit_pfn + 1, new_iova, size_aligned);
+ } else {
+ ret = __alloc_and_insert_iova_range(iovad, size, limit_pfn + 1,
+ new_iova, size_aligned);
+ }
if (ret) {
free_iova_mem(new_iova);
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 2112f21..b01a31a 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -37,6 +37,8 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc,
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
+int iommu_dma_enable_best_fit_algo(struct device *dev);
+
#else /* CONFIG_IOMMU_DMA */
struct iommu_domain;
@@ -78,5 +80,10 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
{
}
+static inline int iommu_dma_enable_best_fit_algo(struct device *dev)
+{
+ return -ENODEV;
+}
+
#endif /* CONFIG_IOMMU_DMA */
#endif /* __DMA_IOMMU_H */
diff --git a/include/linux/iova.h b/include/linux/iova.h
index a0637ab..58713bb 100644
--- a/include/linux/iova.h
+++ b/include/linux/iova.h
@@ -95,6 +95,7 @@ struct iova_domain {
flush-queues */
atomic_t fq_timer_on; /* 1 when timer is active, 0
when not */
+ bool best_fit;
};
static inline unsigned long iova_size(struct iova *iova)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related
* [RFC PATCH] iommu/iova: Add a best-fit algorithm
From: Isaac J. Manjarres @ 2020-02-14 23:06 UTC (permalink / raw)
To: iommu, linux-kernel
Cc: Liam Mark, joro, pratikp, kernel-team, Isaac J. Manjarres
From: Liam Mark <lmark@codeaurora.org>
Using the best-fit algorithm, instead of the first-fit
algorithm, may reduce fragmentation when allocating
IOVAs.
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
---
drivers/iommu/dma-iommu.c | 17 +++++++++++
drivers/iommu/iova.c | 73 +++++++++++++++++++++++++++++++++++++++++++++--
include/linux/dma-iommu.h | 7 +++++
include/linux/iova.h | 1 +
4 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index a2e96a5..af08770 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -364,9 +364,26 @@ static int iommu_dma_deferred_attach(struct device *dev,
if (unlikely(ops->is_attach_deferred &&
ops->is_attach_deferred(domain, dev)))
return iommu_attach_device(domain, dev);
+ return 0;
+}
+
+/*
+ * Should be called prior to using dma-apis.
+ */
+int iommu_dma_enable_best_fit_algo(struct device *dev)
+{
+ struct iommu_domain *domain;
+ struct iova_domain *iovad;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain || !domain->iova_cookie)
+ return -EINVAL;
+ iovad = &((struct iommu_dma_cookie *)domain->iova_cookie)->iovad;
+ iovad->best_fit = true;
return 0;
}
+EXPORT_SYMBOL(iommu_dma_enable_best_fit_algo);
/**
* dma_info_to_prot - Translate DMA API directions and attributes to IOMMU API
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0e6a953..716b05f 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -50,6 +50,7 @@ static unsigned long iova_rcache_get(struct iova_domain *iovad,
iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR;
rb_link_node(&iovad->anchor.node, NULL, &iovad->rbroot.rb_node);
rb_insert_color(&iovad->anchor.node, &iovad->rbroot);
+ iovad->best_fit = false;
init_iova_rcaches(iovad);
}
EXPORT_SYMBOL_GPL(init_iova_domain);
@@ -227,6 +228,69 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
return -ENOMEM;
}
+static int __alloc_and_insert_iova_best_fit(struct iova_domain *iovad,
+ unsigned long size, unsigned long limit_pfn,
+ struct iova *new, bool size_aligned)
+{
+ struct rb_node *curr, *prev;
+ struct iova *curr_iova, *prev_iova;
+ unsigned long flags;
+ unsigned long align_mask = ~0UL;
+ struct rb_node *candidate_rb_parent;
+ unsigned long new_pfn, candidate_pfn = ~0UL;
+ unsigned long gap, candidate_gap = ~0UL;
+
+ if (size_aligned)
+ align_mask <<= limit_align(iovad, fls_long(size - 1));
+
+ /* Walk the tree backwards */
+ spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
+ curr = &iovad->anchor.node;
+ prev = rb_prev(curr);
+ for (; prev; curr = prev, prev = rb_prev(curr)) {
+ curr_iova = rb_entry(curr, struct iova, node);
+ prev_iova = rb_entry(prev, struct iova, node);
+
+ limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
+ new_pfn = (limit_pfn - size) & align_mask;
+ gap = curr_iova->pfn_lo - prev_iova->pfn_hi - 1;
+ if ((limit_pfn >= size) && (new_pfn > prev_iova->pfn_hi)
+ && (gap < candidate_gap)) {
+ candidate_gap = gap;
+ candidate_pfn = new_pfn;
+ candidate_rb_parent = curr;
+ if (gap == size)
+ goto insert;
+ }
+ }
+
+ curr_iova = rb_entry(curr, struct iova, node);
+ limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
+ new_pfn = (limit_pfn - size) & align_mask;
+ gap = curr_iova->pfn_lo - iovad->start_pfn;
+ if (limit_pfn >= size && new_pfn >= iovad->start_pfn &&
+ gap < candidate_gap) {
+ candidate_gap = gap;
+ candidate_pfn = new_pfn;
+ candidate_rb_parent = curr;
+ }
+
+insert:
+ if (candidate_pfn == ~0UL) {
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return -ENOMEM;
+ }
+
+ /* pfn_lo will point to size aligned address if size_aligned is set */
+ new->pfn_lo = candidate_pfn;
+ new->pfn_hi = new->pfn_lo + size - 1;
+
+ /* If we have 'prev', it's a valid place to start the insertion. */
+ iova_insert_rbtree(&iovad->rbroot, new, candidate_rb_parent);
+ spin_unlock_irqrestore(&iovad->iova_rbtree_lock, flags);
+ return 0;
+}
+
static struct kmem_cache *iova_cache;
static unsigned int iova_cache_users;
static DEFINE_MUTEX(iova_cache_mutex);
@@ -302,8 +366,13 @@ struct iova *
if (!new_iova)
return NULL;
- ret = __alloc_and_insert_iova_range(iovad, size, limit_pfn + 1,
- new_iova, size_aligned);
+ if (iovad->best_fit) {
+ ret = __alloc_and_insert_iova_best_fit(iovad, size,
+ limit_pfn + 1, new_iova, size_aligned);
+ } else {
+ ret = __alloc_and_insert_iova_range(iovad, size, limit_pfn + 1,
+ new_iova, size_aligned);
+ }
if (ret) {
free_iova_mem(new_iova);
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 2112f21..b01a31a 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -37,6 +37,8 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc,
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
+int iommu_dma_enable_best_fit_algo(struct device *dev);
+
#else /* CONFIG_IOMMU_DMA */
struct iommu_domain;
@@ -78,5 +80,10 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
{
}
+static inline int iommu_dma_enable_best_fit_algo(struct device *dev)
+{
+ return -ENODEV;
+}
+
#endif /* CONFIG_IOMMU_DMA */
#endif /* __DMA_IOMMU_H */
diff --git a/include/linux/iova.h b/include/linux/iova.h
index a0637ab..58713bb 100644
--- a/include/linux/iova.h
+++ b/include/linux/iova.h
@@ -95,6 +95,7 @@ struct iova_domain {
flush-queues */
atomic_t fq_timer_on; /* 1 when timer is active, 0
when not */
+ bool best_fit;
};
static inline unsigned long iova_size(struct iova *iova)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [meta-python][PATCH] python3-bitarray: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 23:06 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Derek Straka <derek@asterius.io>
---
.../recipes-devtools/python/python-bitarray.inc | 11 -----------
.../python/python3-bitarray_1.2.1.bb | 13 +++++++++++--
2 files changed, 11 insertions(+), 13 deletions(-)
delete mode 100644 meta-python/recipes-devtools/python/python-bitarray.inc
diff --git a/meta-python/recipes-devtools/python/python-bitarray.inc b/meta-python/recipes-devtools/python/python-bitarray.inc
deleted file mode 100644
index 32da348c41..0000000000
--- a/meta-python/recipes-devtools/python/python-bitarray.inc
+++ /dev/null
@@ -1,11 +0,0 @@
-SUMMARY = "A high-level Python efficient arrays of booleans -- C extension"
-HOMEPAGE = "https://github.com/ilanschnell/bitarray"
-LICENSE = "PSF"
-LIC_FILES_CHKSUM = "file://PKG-INFO;md5=dc301a25ebe210dcc53b0a2d5a038eae"
-
-SRC_URI[md5sum] = "a46bf869f6adf34f5b0dc82b469793b7"
-SRC_URI[sha256sum] = "2ed675f460bb0d3d66fd8042a6f1f0d36cf213e52e72a745283ddb245da7b9cf"
-
-inherit pypi
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta-python/recipes-devtools/python/python3-bitarray_1.2.1.bb b/meta-python/recipes-devtools/python/python3-bitarray_1.2.1.bb
index 7ee444dc9e..7970da43f2 100644
--- a/meta-python/recipes-devtools/python/python3-bitarray_1.2.1.bb
+++ b/meta-python/recipes-devtools/python/python3-bitarray_1.2.1.bb
@@ -1,2 +1,11 @@
-inherit setuptools3
-require python-bitarray.inc
+SUMMARY = "A high-level Python efficient arrays of booleans -- C extension"
+HOMEPAGE = "https://github.com/ilanschnell/bitarray"
+LICENSE = "PSF"
+LIC_FILES_CHKSUM = "file://PKG-INFO;md5=dc301a25ebe210dcc53b0a2d5a038eae"
+
+SRC_URI[md5sum] = "a46bf869f6adf34f5b0dc82b469793b7"
+SRC_URI[sha256sum] = "2ed675f460bb0d3d66fd8042a6f1f0d36cf213e52e72a745283ddb245da7b9cf"
+
+inherit pypi setuptools3
+
+BBCLASSEXTEND = "native nativesdk"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH nf-next v4 5/9] nf_tables: Add set type for arbitrary concatenation of ranges
From: Stefano Brivio @ 2020-02-14 23:06 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, Florian Westphal, Kadlecsik József,
Eric Garver, Phil Sutter
In-Reply-To: <20200214204225.dh3ubs67vorh2ail@salvia>
On Fri, 14 Feb 2020 21:42:25 +0100
Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Fri, Feb 14, 2020 at 08:42:13PM +0100, Stefano Brivio wrote:
> > On Fri, 14 Feb 2020 19:16:34 +0100
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> [...]
> > > You refer to a property that says that you can split a range into a
> > > 2*n netmasks IIRC. Do you know what is the worst case when splitting
> > > ranges?
> >
> > I'm not sure I got your question: that is exactly the worst case, i.e.
> > we can have _up to_ 2 * n netmasks (hence rules) given a range of n
> > bits. There's an additional upper bound on this, given by the address
> > space, but single fields in a concatenation can overlap.
> >
> > For example, we can have up to 128 rules for an IPv6 range where at
> > least 64 bits differ between the endpoints, and which would contain
> > 2 ^ 64 addresses. Or, say, the IPv4 range 1.2.3.4 - 255.255.0.2 is
> > expressed by 42 rules.
> >
> > By the way, 0.0.0.1 - 255.255.255.254 takes 62 rules, so we can
> > *probably* say it's 2 * n - 2, but I don't have a formal proof for that.
>
> By "splitting" I was actually refering to "expanding", so you're
> replying here to my worst-case range-to-rules expansion question.
>
> > I have a couple of ways in mind to get that down to n / 2, but it's not
> > straightforward and it will take me some time (assuming it makes
> > sense). For the n bound, we can introduce negations (proof in
> > literature), and I have some kind of ugly prototype. For the n / 2
> > bound, I'd need some auxiliary data structure to keep insertion
> > invertible.
>
> OK, so there is room to improve the "rule expansion" logic. I didn't
> spend much time on that front yet.
I wrote some (barely understandable if at all) notes here:
https://pipapo.lameexcu.se/pipapo/tree/pipapo.c#n271
but I can't guarantee at this stage that it can all be implemented, or
not necessarily in that way. Should you ever (try to) read it, take it
as a rough, buggy draft.
> > In practice, the "average" case is much less, but to define it we would
> > first need to agree on what are the actual components of the
> > multivariate distribution... size and start? Is it a Poisson
> > distribution then? After spending some time on this and disagreeing
> > with myself I'd shyly recommend to skip the topic. :)
>
> Yes, I agree to stick to something relatively simple and good is just
> fine.
>
> > > There is no ipset set like this, but I agree usecase might happen.
> >
> > Actually, for ipset, a "net,port,net,port" type was proposed
> > (netfilter-devel <20181216213039.399-1-oliver@uptheinter.net>), but when
> > József enquired about the intended use case, none was given. So maybe
> > this whole "net,net,port,mac" story makes even less sense.
>
> Would it make sense to you to restrict pipapo to 3 fields until there
> is someone with a usecase for this?
I wouldn't. I'd rather implement the dynamic switch of bucket size if
this is the alternative. I think the current version is rather generic,
doesn't use too much memory, and is also reasonably tested, so I don't
feel like taking working functionality away.
> [...]
> > > The per-cpu scratch index is only required if we cannot fit in the
> > > "result bitmap" into the stack, right?
> >
> > Right.
> >
> > > Probably up to 256 bytes result bitmap in the stack is reasonable?
> > > That makes 8192 pipapo rules. There will be no need to disable bh and
> > > make use of the percpu scratchpad area in that case.
> >
> > Right -- the question is whether that would mean yet another
> > implementation for the lookup function.
>
> This would need another lookup function that can be selected from
> control plane path. The set size and the range-to-rule expansion
> worst-case can tell us if it would fit into the stack. It's would be
> just one extra lookup function for this case, ~80-100 LOC.
Ah, you're right, it's not much. On the other hand, advantages seems to
be:
- dropping the local_bh_{disable,enable}() pair: I can't find numbers
right now, but the difference in pps between v2 (when Florian pointed
out it was needed) and v1 wasn't statistically relevant
- avoiding the access to per-cpu allocated areas, here I have
before/after numbers just for net,mac with 1000 entries on the AVX2
implementation (AMD 7351, one thread), it didn't look significant,
3.99Mpps instead of 3.90Mpps. Maybe it would make a difference when
tested on more threads though (as a reference, same CPU, 10 threads,
as of v2: 38.02Mpps) or with smaller L2
- memory usage (and how that affects locality on some archs), but if we
do this for cases with small numbers of entries, it's probably not a
big difference either
Anyway, I guess it's worth a try -- I'll try to find some time for it.
> > > If adjusting the code to deal with variable length "pipapo word" size
> > > is not too convoluted, then you could just deal with the variable word
> > > size from the insert / delete / get (slow) path and register one
> > > lookup function for the version that is optimized for this pipapo word
> > > size.
> >
> > Yes, I like this a lot -- we would also need one function to rebuild
> > tables when the word size changes, but that sounds almost trivial.
> > Changes for the slow path are actually rather simple.
> >
> > Still, I start doubting quite heavily that my original worst case is
> > reasonable. If we stick to the one you mentioned, or even something in
> > between, it makes no sense to keep 4-bit buckets.
>
> OK, then moving to 8-bits will probably remove a bit of code which is
> dealing with "nibbles".
Right now I have:
1 file changed, 16 insertions(+), 37 deletions(-)
but okay, I'll give the dynamic switch a try, first.
> > By the way, I went ahead and tried the 8-bit bucket version of the C
> > implementation only, on my usual x86_64 box (one thread, AMD Epyc 7351).
> > I think it's worth it:
> >
> > 4-bit 8-bit
> > net,port
> > 1000 entries 2304165pps 2901299pps
> > port,net
> > 100 entries 4131471pps 4751247pps
> > net6,port
> > 1000 entries 1092557pps 1651037pps
> > port,proto
> > 30000 entries 284147pps 449665pps
> > net6,port,mac
> > 10 entries 2082880pps 2762291pps
> > net6,port,mac,proto
> > 1000 entries 783810pps 1195823pps
> > net,mac
> > 1000 entries 1279122pps 1934003pps
>
> Assuming the same concatenation type, larger bucket size makes pps
> drop in the C implementation?
Uh, no, they go up with larger buckets, in the figures above we have
+26%, +15%, +51%, +58%, +33%, +53%, +51%.
> > I would now proceed extending this to the AVX2 implementation and (once
> > I finish it) to the NEON one, I actually expect bigger gains there.
>
> Good. BTW, probably you can add a new NFT_SET_CLASS_JIT class that
> comes becomes NFT_SET_CLASS_O_1 to make the set routine that selects
> the set pick the jit version instead.
It's not exactly JIT though :) it's hand-written assembly. It's coming
up a bit nicer for NEON as I can use compiler intrinsics there.
Maybe I didn't understand your point, but I don't think this is needed.
In 9/9 of v4 I simply had, in nft_pipapo_avx2_estimate():
if (!boot_cpu_has(X86_FEATURE_AVX2) || !boot_cpu_has(X86_FEATURE_AVX))
return false;
> > > Probably adding helper function to deal with pipapo words would help
> > > to prepare for such update in the future. There is the ->estimate
> > > function that allows to calculate for the best word size depending on
> > > all the information this gets from the set definition.
> >
> > Hm, I really think it should be kind of painless to make this dynamic
> > on insertion/deletion.
>
> OK, good. How would you like to proceed?
Let me give a shot at the dynamic bucket size switching. If that looks
reasonable, I'd proceed extending that to the AVX2 implementation,
finish the NEON implementation including it right away, and prepare a
series. If it doesn't, I'll report back :)
--
Stefano
^ permalink raw reply
* Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
From: Dan Williams @ 2020-02-14 23:05 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-nvdimm, Aneesh Kumar K.V, Benjamin Herrenschmidt,
Paul Mackerras, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <x49k14odgwz.fsf@segfault.boston.devel.redhat.com>
On Fri, Feb 14, 2020 at 12:59 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> >> I have just a couple of questions.
> >>
> >> First, can you please add a comment above the generic implementation of
> >> memremap_compat_align describing its purpose, and why a platform might
> >> want to override it?
> >
> > Sure, how about:
> >
> > /*
> > * The memremap() and memremap_pages() interfaces are alternately used
> > * to map persistent memory namespaces. These interfaces place different
> > * constraints on the alignment and size of the mapping (namespace).
> > * memremap() can map individual PAGE_SIZE pages. memremap_pages() can
> > * only map subsections (2MB), and at least one architecture (PowerPC)
> > * the minimum mapping granularity of memremap_pages() is 16MB.
> > *
> > * The role of memremap_compat_align() is to communicate the minimum
> > * arch supported alignment of a namespace such that it can freely
> > * switch modes without violating the arch constraint. Namely, do not
> > * allow a namespace to be PAGE_SIZE aligned since that namespace may be
> > * reconfigured into a mode that requires SUBSECTION_SIZE alignment.
> > */
>
> Well, if we modify the x86 variant to be PAGE_SIZE, I think that text
> won't work. How about:
...but I'm not looking to change it to PAGE_SIZE, I'm going to fix the
alignment check to skip if the namespace has "inner" alignment
padding, i.e. "start_pad" and/or "end_trunc" are non-zero.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 1/4] mm/memremap_pages: Introduce memremap_compat_align()
From: Dan Williams @ 2020-02-14 23:05 UTC (permalink / raw)
To: Jeff Moyer
Cc: linux-nvdimm, Aneesh Kumar K.V, Benjamin Herrenschmidt,
Paul Mackerras, Vishal L Verma, Linux Kernel Mailing List,
linuxppc-dev
In-Reply-To: <x49k14odgwz.fsf@segfault.boston.devel.redhat.com>
On Fri, Feb 14, 2020 at 12:59 PM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> Dan Williams <dan.j.williams@intel.com> writes:
>
> > On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer <jmoyer@redhat.com> wrote:
>
> >> I have just a couple of questions.
> >>
> >> First, can you please add a comment above the generic implementation of
> >> memremap_compat_align describing its purpose, and why a platform might
> >> want to override it?
> >
> > Sure, how about:
> >
> > /*
> > * The memremap() and memremap_pages() interfaces are alternately used
> > * to map persistent memory namespaces. These interfaces place different
> > * constraints on the alignment and size of the mapping (namespace).
> > * memremap() can map individual PAGE_SIZE pages. memremap_pages() can
> > * only map subsections (2MB), and at least one architecture (PowerPC)
> > * the minimum mapping granularity of memremap_pages() is 16MB.
> > *
> > * The role of memremap_compat_align() is to communicate the minimum
> > * arch supported alignment of a namespace such that it can freely
> > * switch modes without violating the arch constraint. Namely, do not
> > * allow a namespace to be PAGE_SIZE aligned since that namespace may be
> > * reconfigured into a mode that requires SUBSECTION_SIZE alignment.
> > */
>
> Well, if we modify the x86 variant to be PAGE_SIZE, I think that text
> won't work. How about:
...but I'm not looking to change it to PAGE_SIZE, I'm going to fix the
alignment check to skip if the namespace has "inner" alignment
padding, i.e. "start_pad" and/or "end_trunc" are non-zero.
^ permalink raw reply
* [igt-dev] ✗ Fi.CI.BAT: failure for lib: Update selftests to use dynamic subtests
From: Patchwork @ 2020-02-14 23:05 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200214214829.4054673-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: lib: Update selftests to use dynamic subtests
URL : https://patchwork.freedesktop.org/series/73486/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7943 -> IGTPW_4158
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_4158 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_4158, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_4158:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live_evict:
- fi-cml-u2: [PASS][1] -> [SKIP][2] +31 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cml-u2/igt@i915_selftest@live_evict.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-cml-u2/igt@i915_selftest@live_evict.html
* igt@i915_selftest@live_gt_contexts:
- fi-icl-guc: [PASS][3] -> [SKIP][4] +30 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-guc/igt@i915_selftest@live_gt_contexts.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-guc/igt@i915_selftest@live_gt_contexts.html
* igt@i915_selftest@live_gt_mocs:
- fi-icl-y: [PASS][5] -> [SKIP][6] +29 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-y/igt@i915_selftest@live_gt_mocs.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-y/igt@i915_selftest@live_gt_mocs.html
* igt@i915_selftest@live_hugepages:
- fi-icl-u2: [PASS][7] -> [SKIP][8] +30 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-u2/igt@i915_selftest@live_hugepages.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-u2/igt@i915_selftest@live_hugepages.html
* igt@i915_selftest@live_reset:
- fi-icl-dsi: [PASS][9] -> [SKIP][10] +30 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-dsi/igt@i915_selftest@live_reset.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [PASS][11] -> [SKIP][12] +30 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@i915_selftest@live_uncore:
- fi-cml-s: [PASS][13] -> [SKIP][14] +31 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cml-s/igt@i915_selftest@live_uncore.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-cml-s/igt@i915_selftest@live_uncore.html
* igt@runner@aborted:
- fi-kbl-7500u: NOTRUN -> [FAIL][15]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-kbl-7500u/igt@runner@aborted.html
#### Warnings ####
* igt@i915_selftest@live_active:
- fi-icl-y: [DMESG-FAIL][16] ([i915#765]) -> [SKIP][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-y/igt@i915_selftest@live_active.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-y/igt@i915_selftest@live_active.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_client:
- {fi-tgl-u}: [PASS][18] -> [SKIP][19] +31 similar issues
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-tgl-u/igt@i915_selftest@live_client.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-tgl-u/igt@i915_selftest@live_client.html
* igt@i915_selftest@live_execlists:
- {fi-tgl-dsi}: [PASS][20] -> [SKIP][21] +31 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
Known issues
------------
Here are the changes found in IGTPW_4158 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@dmabuf@dma_fence:
- fi-ilk-650: [PASS][22] -> [SKIP][23] ([fdo#109271]) +31 similar issues
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-ilk-650/igt@dmabuf@dma_fence.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-ilk-650/igt@dmabuf@dma_fence.html
* igt@dmabuf@sanitycheck:
- fi-kbl-x1275: [PASS][24] -> [SKIP][25] ([fdo#109271]) +31 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-kbl-x1275/igt@dmabuf@sanitycheck.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-kbl-x1275/igt@dmabuf@sanitycheck.html
* igt@i915_selftest@live_active:
- fi-bdw-5557u: [PASS][26] -> [SKIP][27] ([fdo#109271]) +31 similar issues
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-bdw-5557u/igt@i915_selftest@live_active.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-bdw-5557u/igt@i915_selftest@live_active.html
* igt@i915_selftest@live_coherency:
- fi-hsw-4770: [PASS][28] -> [SKIP][29] ([fdo#109271]) +31 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-hsw-4770/igt@i915_selftest@live_coherency.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-hsw-4770/igt@i915_selftest@live_coherency.html
* igt@i915_selftest@live_dmabuf:
- fi-hsw-4770r: [PASS][30] -> [SKIP][31] ([fdo#109271]) +31 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-hsw-4770r/igt@i915_selftest@live_dmabuf.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-hsw-4770r/igt@i915_selftest@live_dmabuf.html
* igt@i915_selftest@live_execlists:
- fi-glk-dsi: [PASS][32] -> [SKIP][33] ([fdo#109271]) +31 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-glk-dsi/igt@i915_selftest@live_execlists.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-glk-dsi/igt@i915_selftest@live_execlists.html
- fi-gdg-551: [PASS][34] -> [SKIP][35] ([fdo#109271]) +31 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-gdg-551/igt@i915_selftest@live_execlists.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-gdg-551/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-apl-guc: [PASS][36] -> [SKIP][37] ([fdo#109271]) +31 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-apl-guc/igt@i915_selftest@live_gem_contexts.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-apl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gt_contexts:
- fi-kbl-r: [PASS][38] -> [SKIP][39] ([fdo#109271]) +31 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-kbl-r/igt@i915_selftest@live_gt_contexts.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-kbl-r/igt@i915_selftest@live_gt_contexts.html
* igt@i915_selftest@live_gt_engines:
- fi-kbl-guc: [PASS][40] -> [SKIP][41] ([fdo#109271]) +31 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-kbl-guc/igt@i915_selftest@live_gt_engines.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-kbl-guc/igt@i915_selftest@live_gt_engines.html
* igt@i915_selftest@live_gt_heartbeat:
- fi-pnv-d510: [PASS][42] -> [SKIP][43] ([fdo#109271]) +31 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-pnv-d510/igt@i915_selftest@live_gt_heartbeat.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-pnv-d510/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_gt_pm:
- fi-cfl-8700k: [PASS][44] -> [SKIP][45] ([fdo#109271]) +31 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cfl-8700k/igt@i915_selftest@live_gt_pm.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-cfl-8700k/igt@i915_selftest@live_gt_pm.html
* igt@i915_selftest@live_gt_timelines:
- fi-cfl-guc: [PASS][46] -> [SKIP][47] ([fdo#109271]) +31 similar issues
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cfl-guc/igt@i915_selftest@live_gt_timelines.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-cfl-guc/igt@i915_selftest@live_gt_timelines.html
* igt@i915_selftest@live_gtt:
- fi-bwr-2160: [PASS][48] -> [SKIP][49] ([fdo#109271]) +31 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-bwr-2160/igt@i915_selftest@live_gtt.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-bwr-2160/igt@i915_selftest@live_gtt.html
- fi-skl-guc: [PASS][50] -> [SKIP][51] ([fdo#109271]) +31 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-skl-guc/igt@i915_selftest@live_gtt.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-skl-guc/igt@i915_selftest@live_gtt.html
* igt@i915_selftest@live_late_gt_pm:
- fi-bsw-kefka: [PASS][52] -> [SKIP][53] ([fdo#109271]) +31 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-bsw-kefka/igt@i915_selftest@live_late_gt_pm.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-bsw-kefka/igt@i915_selftest@live_late_gt_pm.html
* igt@i915_selftest@live_mman:
- fi-bxt-dsi: [PASS][54] -> [SKIP][55] ([fdo#109271]) +31 similar issues
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-bxt-dsi/igt@i915_selftest@live_mman.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-bxt-dsi/igt@i915_selftest@live_mman.html
* igt@i915_selftest@live_objects:
- fi-snb-2600: [PASS][56] -> [SKIP][57] ([fdo#109271]) +31 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-snb-2600/igt@i915_selftest@live_objects.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-snb-2600/igt@i915_selftest@live_objects.html
* igt@i915_selftest@live_perf:
- fi-skl-6700k2: [PASS][58] -> [SKIP][59] ([fdo#109271]) +31 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-skl-6700k2/igt@i915_selftest@live_perf.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-skl-6700k2/igt@i915_selftest@live_perf.html
* igt@i915_selftest@live_requests:
- fi-icl-guc: [PASS][60] -> [SKIP][61] ([fdo#109644] / [fdo#110464])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-guc/igt@i915_selftest@live_requests.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-guc/igt@i915_selftest@live_requests.html
- fi-icl-dsi: [PASS][62] -> [SKIP][63] ([fdo#109644] / [fdo#110464])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-dsi/igt@i915_selftest@live_requests.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-dsi/igt@i915_selftest@live_requests.html
- fi-icl-u2: [PASS][64] -> [SKIP][65] ([fdo#109644] / [fdo#110464])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-u2/igt@i915_selftest@live_requests.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-u2/igt@i915_selftest@live_requests.html
- fi-icl-y: [PASS][66] -> [SKIP][67] ([fdo#109644] / [fdo#110464])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-y/igt@i915_selftest@live_requests.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-y/igt@i915_selftest@live_requests.html
- fi-icl-u3: [PASS][68] -> [SKIP][69] ([fdo#109644] / [fdo#110464])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-u3/igt@i915_selftest@live_requests.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-icl-u3/igt@i915_selftest@live_requests.html
* igt@i915_selftest@live_reset:
- fi-snb-2520m: [PASS][70] -> [SKIP][71] ([fdo#109271]) +31 similar issues
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-snb-2520m/igt@i915_selftest@live_reset.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-snb-2520m/igt@i915_selftest@live_reset.html
#### Possible fixes ####
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [INCOMPLETE][72] ([i915#45]) -> [PASS][73]
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@gem_exec_parallel@basic:
- {fi-ehl-1}: [FAIL][74] ([i915#996]) -> [PASS][75]
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-ehl-1/igt@gem_exec_parallel@basic.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/fi-ehl-1/igt@gem_exec_parallel@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644
[fdo#110464]: https://bugs.freedesktop.org/show_bug.cgi?id=110464
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765
[i915#996]: https://gitlab.freedesktop.org/drm/intel/issues/996
Participating hosts (41 -> 44)
------------------------------
Additional (9): fi-kbl-soraka fi-bsw-n3050 fi-hsw-peppy fi-ivb-3770 fi-cfl-8109u fi-skl-lmem fi-blb-e6850 fi-bsw-nick fi-skl-6600u
Missing (6): fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5442 -> IGTPW_4158
CI-20190529: 20190529
CI_DRM_7943: 865945b076689b2e99bc1c52fad95cec05cff9ed @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4158: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/index.html
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Testlist changes ==
+igt@dmabuf@all
+igt@drm_mm@all
+igt@i915_selftest@live
+igt@i915_selftest@mock
+igt@i915_selftest@perf
+igt@kms_selftest@all
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4158/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [meta-python2][PATCH] python-grpcio: Upgrade to 1.27.1
From: Khem Raj @ 2020-02-14 23:04 UTC (permalink / raw)
To: Tim Orling; +Cc: openembedded-devel@lists.openembedded.org
In-Reply-To: <CANx9H-CONadAvBOw-HF+HqcMm+8+_aXaQKfz07A171PDW7mpGA@mail.gmail.com>
On 2/14/20 8:06 AM, Tim Orling wrote:
> Thank you. I've merged this, but noticed 1.27.2 was released to patch
> python. Can you have a look?
> https://github.com/grpc/grpc/releases/tag/v1.27.2
>
interesting timing. My intention was to get 64bit time_t fixes only.
> On Wed, Feb 12, 2020 at 9:55 PM Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
>
> Delete gettid patch, fixed differenty upstream
> Add code to use cross compiler in setup.py
>
> Define GRPC_PYTHON_DISABLE_LIBC_COMPATIBILITY so it does not use
> SYS_clock_gettime syscalls since it does not work when 64bit time_t is
> used on 32bit arches
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
> ---
> ...-Do-not-mix-C-and-C-compiler-options.patch | 44 ++++++++++++++-----
> .../python/python-grpcio/gettid.patch | 26 -----------
> .../python-grpcio/ppc-boringssl-support.patch | 2 +-
> .../python-grpcio/riscv64_support.patch | 2 +-
> ...pcio_1.19.0.bb <http://pcio_1.19.0.bb> =>
> python-grpcio_1.27.1.bb <http://python-grpcio_1.27.1.bb>} | 11 ++---
> 5 files changed, 40 insertions(+), 45 deletions(-)
> delete mode 100644 recipes-devtools/python/python-grpcio/gettid.patch
> rename recipes-devtools/python/{python-grpcio_1.19.0.bb
> <http://python-grpcio_1.19.0.bb> => python-grpcio_1.27.1.bb
> <http://python-grpcio_1.27.1.bb>} (74%)
>
> <snip>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> <mailto:Openembedded-devel@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* [ANNOUNCE] wireguard-linux-compat v0.0.20200215 released
From: Jason A. Donenfeld @ 2020-02-14 23:03 UTC (permalink / raw)
To: WireGuard mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
A new version, v0.0.20200215, of the backported WireGuard kernel module for
3.10 <= Linux <= 5.5.y has been tagged in the git repository.
Please note that until Linux 5.6 is released, this snapshot is a
snapshot rather than a secure final release.
== Changes ==
* send: cleanup skb padding calculation
* socket: remove useless synchronize_net
Sorry for the back-to-back releases. This fixes a regression spotted by Eric
Dumazet.
This release contains commits from: Jason A. Donenfeld.
As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/
and information about the project is available at https://www.wireguard.com/ .
This snapshot is available in compressed tarball form here:
https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-0.0.20200215.tar.xz
SHA2-256: 0def6f3608ec06f6dfc454aa5281a7c38b06ff27096cb341448d20602da4e923
A PGP signature of that file decompressed is available here:
https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-0.0.20200215.tar.asc
Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
Remember to unxz the tarball before verifying the signature.
If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.
Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/
Thank you,
Jason Donenfeld
-----BEGIN PGP SIGNATURE-----
iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl5HJy8QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrkecEADDiaWXMlsxqEowxnVsZpB3Nl+7gPct4ZMA
KaV6Nj64EFmLLTIpVpLUkttHhWVPlr2Av8lcNO1HE4GeMfQJSgQKhd6ft6a3HYTT
Uq4B8c9+B5Fe++9ROC+NUsJHb1wb1VldKo9x38wAS5U8MKLYP2LTiWwAXbVnDNvk
h+uHpkrGdlXJ9D9d1asjpFQekuemzZ7qdf1W8W5S+6f5rfcH3eAIn0cVghb/iKvW
w9J0lEV8Yny0hq2k24rv6+dzAEHQCALINriZGS0MdNnkwpbcpxvxkQO87jBIVBZz
CNTYWW63JYj/LQagSKBXYMb0jstYMRbdHx37nrmhPFLB27ZwsxtZXDG+ci7MWyqb
hNPHOJQ2HG5OIcjaK+iuXzom+HN/OvwjboTGD3dD0NFuVrjm5zDOaYwjaLW62ijd
/ujys5DxeE0++KBMQ6TMcn+Zakdu5SGmyKcyYrlofTNydY/EsKxdoVdrJrjTUUFg
HN2tjIL6essPLgDyHwJURl2d8y1Jg+unYJb/xKb6CJEVsALpJnbHgJ/CmBjENbGE
GzPWupkuW5ybo4nnMWGzbz3u9sj/sXyTpE2YWRh1UMqMB5BQHqMkXvA0/GUz/EHz
sHdMdSS7+lQgrMQsktxI8E3a9PdxrUCPgZTG+1IyTmR1p4FaClQXvKtQ+eMqHBlT
BGPhnREXpQ==
=RTSb
-----END PGP SIGNATURE-----
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: [PATCH v3 00/12] Enable per-file/directory DAX operations V3
From: Jeff Moyer @ 2020-02-14 23:03 UTC (permalink / raw)
To: Ira Weiny
Cc: Dan Williams, Darrick J. Wong, Linux Kernel Mailing List,
Alexander Viro, Dave Chinner, Christoph Hellwig,
Theodore Y. Ts'o, Jan Kara, linux-ext4, linux-xfs,
linux-fsdevel
In-Reply-To: <x49tv3sbwu5.fsf@segfault.boston.devel.redhat.com>
Jeff Moyer <jmoyer@redhat.com> writes:
> Hi, Ira,
>
> Jeff Moyer <jmoyer@redhat.com> writes:
>
>> I'll try to get some testing in on this series, now.
>
> This series panics in xfstests generic/013, when run like so:
>
> MKFS_OPTIONS="-m reflink=0" MOUNT_OPTIONS="-o dax" ./check -g auto
>
> I'd dig in further, but it's late on a Friday. You understand. :)
Sorry, I should have at least given you a clue. Below is the stack
trace. We're going down the buffered I/O path, even though the fs is
mounted with -o dax. Somewhere the inode isn't getting marked properly.
-Jeff
[ 549.461099] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 549.468053] #PF: supervisor instruction fetch in kernel mode
[ 549.473713] #PF: error_code(0x0010) - not-present page
[ 549.478851] PGD 17c7e06067 P4D 17c7e06067 PUD 17c7e01067 PMD 0
[ 549.484773] Oops: 0010 [#1] SMP NOPTI
[ 549.488438] CPU: 68 PID: 19851 Comm: fsstress Not tainted 5.6.0-rc1+ #42
[ 549.495134] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0D.01.0395.022720191340 02/27/2019
[ 549.505562] RIP: 0010:0x0
[ 549.508186] Code: Bad RIP value.
[ 549.511418] RSP: 0018:ffffab132dc9fa98 EFLAGS: 00010246
[ 549.516642] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
[ 549.523768] RDX: 0000000000000000 RSI: ffffdcf75e7060c0 RDI: ffff8c3805d22300
[ 549.530900] RBP: ffffab132dc9fb08 R08: 0000000000000000 R09: 00002308a18f9f3f
[ 549.538030] R10: 0000000000000000 R11: ffffdcf75f4b19c0 R12: ffff8c37cfe6d2b8
[ 549.545155] R13: ffffab132dc9fb60 R14: ffffdcf75e7060c8 R15: ffffdcf75e7060c0
[ 549.552288] FS: 00007f849d20cb80(0000) GS:ffff8c3821100000(0000) knlGS:0000000000000000
[ 549.560373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 549.566117] CR2: ffffffffffffffd6 CR3: 00000017d3088005 CR4: 00000000007606e0
[ 549.573250] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 549.580383] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 549.587515] PKRU: 55555554
[ 549.590228] Call Trace:
[ 549.592683] read_pages+0x120/0x190
[ 549.596173] __do_page_cache_readahead+0x1c1/0x1e0
[ 549.600965] ondemand_readahead+0x182/0x2f0
[ 549.605152] generic_file_buffered_read+0x5a6/0xaf0
[ 549.610032] ? security_inode_permission+0x30/0x50
[ 549.614824] ? _cond_resched+0x15/0x30
[ 549.618620] xfs_file_buffered_aio_read+0x47/0xe0 [xfs]
[ 549.623861] xfs_file_read_iter+0x6e/0xd0 [xfs]
[ 549.628394] generic_file_splice_read+0x100/0x220
[ 549.633099] splice_direct_to_actor+0xd5/0x220
[ 549.637543] ? pipe_to_sendpage+0xa0/0xa0
[ 549.641557] do_splice_direct+0x9a/0xd0
[ 549.645396] vfs_copy_file_range+0x153/0x320
[ 549.649667] __x64_sys_copy_file_range+0xdd/0x200
[ 549.654375] do_syscall_64+0x55/0x1d0
[ 549.658039] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 549.663091] RIP: 0033:0x7f849c7086bd
[ 549.666671] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 9b 67 2c 00 f7 d8 64 89 01 48
[ 549.685414] RSP: 002b:00007fff81b78678 EFLAGS: 00000246 ORIG_RAX: 0000000000000146
[ 549.692980] RAX: ffffffffffffffda RBX: 00000000000000c9 RCX: 00007f849c7086bd
[ 549.700112] RDX: 0000000000000004 RSI: 00007fff81b786b0 RDI: 0000000000000003
[ 549.707242] RBP: 00000000005d92ef R08: 0000000000006cb4 R09: 0000000000000000
[ 549.714375] R10: 00007fff81b786b8 R11: 0000000000000246 R12: 0000000000000003
[ 549.721508] R13: 0000000000006cb4 R14: 0000000000037f58 R15: 0000000000365871
[ 549.728641] Modules linked in: xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common skx_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass crct10dif_pclmul ipmi_ssif crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore mei_me ipmi_si joydev intel_rapl_perf ioatdma pcspkr ipmi_devintf sg i2c_i801 lpc_ich mei dca ipmi_msghandler dax_pmem dax_pmem_core acpi_power_meter acpi_pad xfs libcrc32c nd_pmem nd_btt sd_mod sr_mod cdrom ast i2c_algo_bit drm_vram_helper drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32c_intel i40e drm nvme ahci nvme_core libahci t10_pi libata wmi nfit libnvdimm
[ 549.805384] CR2: 0000000000000000
[ 549.808744] ---[ end trace 62568a4ecc43ee90 ]---
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/psr: Force PSR probe only after full initialization (rev3)
From: Patchwork @ 2020-02-14 23:03 UTC (permalink / raw)
To: Ross Zwisler; +Cc: intel-gfx
In-Reply-To: <20200214015038.122913-1-jose.souza@intel.com>
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev3)
URL : https://patchwork.freedesktop.org/series/73436/
State : failure
== Summary ==
Applying: drm/i915/psr: Force PSR probe only after full initialization
error: corrupt patch at line 11
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 drm/i915/psr: Force PSR probe only after full initialization
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [meta-python][PATCH] python3-cffi: consolidate inc and bb files into a single bb file
From: Khem Raj @ 2020-02-14 23:02 UTC (permalink / raw)
To: Derek Straka, openembedded-devel
In-Reply-To: <20200214223751.16148-1-derek@asterius.io>
On 2/14/20 2:37 PM, Derek Straka wrote:
> Signed-off-by: Derek Straka <derek@asterius.io>
> ---
> .../recipes-devtools/python/python-cffi.inc | 17 -----------------
> .../python/python3-cffi_1.13.2.bb | 19 ++++++++++++++++++-
> 2 files changed, 18 insertions(+), 18 deletions(-)
> delete mode 100644 meta-python/recipes-devtools/python/python-cffi.inc
>
> diff --git a/meta-python/recipes-devtools/python/python-cffi.inc b/meta-python/recipes-devtools/python/python-cffi.inc
> deleted file mode 100644
> index a2b0c3bb0c..0000000000
> --- a/meta-python/recipes-devtools/python/python-cffi.inc
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -SUMMARY = "Foreign Function Interface for Python calling C code"
> -HOMEPAGE = "http://cffi.readthedocs.org/"
> -LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
> -DEPENDS += "libffi ${PYTHON_PN}-pycparser"
> -
> -SRC_URI[md5sum] = "652203cf99faa254efff7fab23c2f3a2"
> -SRC_URI[sha256sum] = "599a1e8ff057ac530c9ad1778293c665cb81a791421f46922d80a86473c13346"
> -
> -RDEPENDS_${PN}_class-target = " \
> - ${PYTHON_PN}-ctypes \
> - ${PYTHON_PN}-io \
> - ${PYTHON_PN}-pycparser \
> - ${PYTHON_PN}-shell \
> -"
> -
> -BBCLASSEXTEND = "native nativesdk"
> diff --git a/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb b/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
> index e888084347..6156081126 100644
> --- a/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
> +++ b/meta-python/recipes-devtools/python/python3-cffi_1.13.2.bb
> @@ -1,2 +1,19 @@
> +SUMMARY = "Foreign Function Interface for Python calling C code"
> +HOMEPAGE = "http://cffi.readthedocs.org/"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
> +DEPENDS += "libffi ${PYTHON_PN}-pycparser"
> +
> +SRC_URI[md5sum] = "652203cf99faa254efff7fab23c2f3a2"
> +SRC_URI[sha256sum] = "599a1e8ff057ac530c9ad1778293c665cb81a791421f46922d80a86473c13346"
> +
> inherit pypi setuptools3
> -require python-cffi.inc
> +
> +RDEPENDS_${PN}_class-target = " \
> + ${PYTHON_PN}-ctypes \
> + ${PYTHON_PN}-io \
> + ${PYTHON_PN}-pycparser \
> + ${PYTHON_PN}-shell \
> +"
> +
> +BBCLASSEXTEND = "native nativesdk"
>
this patch does not apply cleanly on master-next, can you rebase and
send v2 please ?
^ permalink raw reply
* [PATCH v2 5/5] drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST
From: Lyude Paul @ 2020-02-14 22:58 UTC (permalink / raw)
To: nouveau
Cc: Ben Skeggs, David Airlie, Daniel Vetter, Sean Paul, Mikita Lipski,
Manasi Navare, Takashi Iwai, dri-devel, linux-kernel
In-Reply-To: <20200214225910.695210-1-lyude@redhat.com>
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.
So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 ++++-
drivers/gpu/drm/nouveau/nouveau_connector.c | 41 +++++++++++----------
drivers/gpu/drm/nouveau/nouveau_connector.h | 5 +++
drivers/gpu/drm/nouveau/nouveau_dp.c | 31 ++++++++++++++++
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++
5 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 020058811831..684e2c081ea2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1051,7 +1051,14 @@ static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return MODE_OK;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct nouveau_encoder *outp = mstc->mstm->outp;
+
+ /* TODO: calculate the PBN from the dotclock and validate against the
+ * MSTB's max possible PBN
+ */
+
+ return nv50_dp_mode_valid(connector, outp, mode, NULL);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 6dae00da5d7e..a82a51661ca1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_drv.h"
#include "dispnv04/hw.h"
+#include "dispnv50/disp.h"
#include "nouveau_acpi.h"
#include "nouveau_display.h"
@@ -1033,6 +1034,24 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
return 112000 * duallink_scale;
}
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned *clock)
+{
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
+ DRM_MODE_FLAG_3D_FRAME_PACKING)
+ *clock *= 2;
+
+ if (*clock < min_clock)
+ return MODE_CLOCK_LOW;
+ if (*clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static enum drm_mode_status
nouveau_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1041,7 +1060,6 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
- unsigned clock = mode->clock;
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -1064,29 +1082,14 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
case DCB_OUTPUT_TV:
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
- if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->caps.dp_interlace)
- return MODE_NO_INTERLACE;
-
- max_clock = nv_encoder->dp.link_nr;
- max_clock *= nv_encoder->dp.link_bw;
- clock = clock * (connector->display_info.bpc * 3) / 10;
- break;
+ return nv50_dp_mode_valid(connector, nv_encoder, mode, NULL);
default:
BUG();
return MODE_BAD;
}
- if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING)
- clock *= 2;
-
- if (clock < min_clock)
- return MODE_CLOCK_LOW;
-
- if (clock > max_clock)
- return MODE_CLOCK_HIGH;
-
- return MODE_OK;
+ return nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+ NULL);
}
static struct drm_encoder *
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h
index de84fb4708c7..9e062c7adec8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -195,6 +195,11 @@ int nouveau_conn_atomic_get_property(struct drm_connector *,
const struct drm_connector_state *,
struct drm_property *, u64 *);
struct drm_display_mode *nouveau_conn_native_mode(struct drm_connector *);
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned *clock);
#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
extern int nouveau_backlight_init(struct drm_connector *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 2674f1587457..8a0f7994e1ae 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -98,3 +98,34 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
return NOUVEAU_DP_SST;
return ret;
}
+
+/* TODO:
+ * - Use the minimum possible BPC here, once we add support for the max bpc
+ * property.
+ * - Validate the mode against downstream port caps (see
+ * drm_dp_downstream_max_clock())
+ * - Validate against the DP caps advertised by the GPU (we don't check these
+ * yet)
+ */
+enum drm_mode_status
+nv50_dp_mode_valid(struct drm_connector *connector,
+ struct nouveau_encoder *outp,
+ const struct drm_display_mode *mode,
+ unsigned *out_clock)
+{
+ const unsigned min_clock = 25000;
+ unsigned max_clock, clock;
+ enum drm_mode_status ret;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
+ return MODE_NO_INTERLACE;
+
+ max_clock = outp->dp.link_nr * outp->dp.link_bw;
+ clock = mode->clock * (connector->display_info.bpc * 3) / 10;
+
+ ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+ &clock);
+ if (out_clock)
+ *out_clock = clock;
+ return ret;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index 3217f587eceb..de51733b0476 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -104,6 +104,10 @@ enum nouveau_dp_status {
};
int nouveau_dp_detect(struct nouveau_encoder *);
+enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
+ struct nouveau_encoder *,
+ const struct drm_display_mode *,
+ unsigned *clock);
struct nouveau_connector *
nouveau_encoder_connector_get(struct nouveau_encoder *encoder);
--
2.24.1
^ permalink raw reply related
* [PATCH v2 5/5] drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST
From: Lyude Paul @ 2020-02-14 22:58 UTC (permalink / raw)
To: nouveau
Cc: David Airlie, linux-kernel, dri-devel, Manasi Navare, Sean Paul,
Ben Skeggs, Mikita Lipski
In-Reply-To: <20200214225910.695210-1-lyude@redhat.com>
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.
So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 ++++-
drivers/gpu/drm/nouveau/nouveau_connector.c | 41 +++++++++++----------
drivers/gpu/drm/nouveau/nouveau_connector.h | 5 +++
drivers/gpu/drm/nouveau/nouveau_dp.c | 31 ++++++++++++++++
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++
5 files changed, 70 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 020058811831..684e2c081ea2 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1051,7 +1051,14 @@ static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return MODE_OK;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct nouveau_encoder *outp = mstc->mstm->outp;
+
+ /* TODO: calculate the PBN from the dotclock and validate against the
+ * MSTB's max possible PBN
+ */
+
+ return nv50_dp_mode_valid(connector, outp, mode, NULL);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 6dae00da5d7e..a82a51661ca1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_drv.h"
#include "dispnv04/hw.h"
+#include "dispnv50/disp.h"
#include "nouveau_acpi.h"
#include "nouveau_display.h"
@@ -1033,6 +1034,24 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
return 112000 * duallink_scale;
}
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned *clock)
+{
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
+ DRM_MODE_FLAG_3D_FRAME_PACKING)
+ *clock *= 2;
+
+ if (*clock < min_clock)
+ return MODE_CLOCK_LOW;
+ if (*clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static enum drm_mode_status
nouveau_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1041,7 +1060,6 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
- unsigned clock = mode->clock;
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -1064,29 +1082,14 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
case DCB_OUTPUT_TV:
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
- if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->caps.dp_interlace)
- return MODE_NO_INTERLACE;
-
- max_clock = nv_encoder->dp.link_nr;
- max_clock *= nv_encoder->dp.link_bw;
- clock = clock * (connector->display_info.bpc * 3) / 10;
- break;
+ return nv50_dp_mode_valid(connector, nv_encoder, mode, NULL);
default:
BUG();
return MODE_BAD;
}
- if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING)
- clock *= 2;
-
- if (clock < min_clock)
- return MODE_CLOCK_LOW;
-
- if (clock > max_clock)
- return MODE_CLOCK_HIGH;
-
- return MODE_OK;
+ return nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+ NULL);
}
static struct drm_encoder *
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h
index de84fb4708c7..9e062c7adec8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -195,6 +195,11 @@ int nouveau_conn_atomic_get_property(struct drm_connector *,
const struct drm_connector_state *,
struct drm_property *, u64 *);
struct drm_display_mode *nouveau_conn_native_mode(struct drm_connector *);
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned *clock);
#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
extern int nouveau_backlight_init(struct drm_connector *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 2674f1587457..8a0f7994e1ae 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -98,3 +98,34 @@ nouveau_dp_detect(struct nouveau_encoder *nv_encoder)
return NOUVEAU_DP_SST;
return ret;
}
+
+/* TODO:
+ * - Use the minimum possible BPC here, once we add support for the max bpc
+ * property.
+ * - Validate the mode against downstream port caps (see
+ * drm_dp_downstream_max_clock())
+ * - Validate against the DP caps advertised by the GPU (we don't check these
+ * yet)
+ */
+enum drm_mode_status
+nv50_dp_mode_valid(struct drm_connector *connector,
+ struct nouveau_encoder *outp,
+ const struct drm_display_mode *mode,
+ unsigned *out_clock)
+{
+ const unsigned min_clock = 25000;
+ unsigned max_clock, clock;
+ enum drm_mode_status ret;
+
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
+ return MODE_NO_INTERLACE;
+
+ max_clock = outp->dp.link_nr * outp->dp.link_bw;
+ clock = mode->clock * (connector->display_info.bpc * 3) / 10;
+
+ ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+ &clock);
+ if (out_clock)
+ *out_clock = clock;
+ return ret;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index 3217f587eceb..de51733b0476 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -104,6 +104,10 @@ enum nouveau_dp_status {
};
int nouveau_dp_detect(struct nouveau_encoder *);
+enum drm_mode_status nv50_dp_mode_valid(struct drm_connector *,
+ struct nouveau_encoder *,
+ const struct drm_display_mode *,
+ unsigned *clock);
struct nouveau_connector *
nouveau_encoder_connector_get(struct nouveau_encoder *encoder);
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes
From: Lyude Paul @ 2020-02-14 22:58 UTC (permalink / raw)
To: nouveau; +Cc: David Airlie, linux-kernel, dri-devel, Ben Skeggs
In-Reply-To: <20200214225910.695210-1-lyude@redhat.com>
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 00011ce109a6..4a9a32b89f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -168,14 +168,15 @@ headc37d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
struct nv50_dmac *core = &nv50_disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = &asyh->mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 938d910a1b1e..859131a8bc3c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -173,14 +173,15 @@ headc57d_mode(struct nv50_head *head, struct nv50_head_atom *asyh)
struct nv50_dmac *core = &nv50_disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = &asyh->mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 43bcbb6d73c4..6dae00da5d7e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1065,7 +1065,7 @@ nouveau_connector_mode_valid(struct drm_connector *connector,
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->dp.caps.interlace)
+ !nv_encoder->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = nv_encoder->dp.link_nr;
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
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.