* [MPTCP] [PATCH v3 6/6] mptcp: send acks when moving skbs to mptcp receive queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
This isn't strictly required, however, without this we will
punish flows that don't do bluk transmits as they will lag
behind in their window updates sent to peer.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
include/net/tcp.h | 1 +
net/ipv4/tcp.c | 2 +-
net/mptcp/protocol.c | 3 +++
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index a5ea27df3c2b..454ecab0df8b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -650,6 +650,7 @@ static inline int tcp_bound_to_half_wnd(struct tcp_sock *tp, int pktsize)
/* tcp.c */
void tcp_get_info(struct sock *, struct tcp_info *);
+void tcp_cleanup_rbuf(struct sock *sk, int copied);
/* Read 'sendfile()'-style from a TCP socket */
int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1b685485a5b5..62362885a518 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1517,7 +1517,7 @@ static int tcp_peek_sndq(struct sock *sk, struct msghdr *msg, int len)
* calculation of whether or not we must ACK for the sake of
* a window update.
*/
-static void tcp_cleanup_rbuf(struct sock *sk, int copied)
+void tcp_cleanup_rbuf(struct sock *sk, int copied)
{
struct tcp_sock *tp = tcp_sk(sk);
bool time_to_ack = false;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 02aba8b31f1f..93963bf3f9fe 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -773,6 +773,9 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
more_data_avail = mptcp_subflow_data_available(ssk);
} while (more_data_avail);
+ if (moved > 0)
+ tcp_cleanup_rbuf(ssk, moved);
+
release_sock(ssk);
} while (!done);
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 5/6] mptcp: protocol: re-check dsn before reading from subflow
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
mptcp_subflow_data_available() is commonly called via
ssk->sk_data_ready(), in this case the mptcp socket lock
cannot be acquired.
Therefore, while we can safely discard subflow data that
was already received up to msk->ack_seq, we cannot be sure
that 'subflow->data_avail' will still be valid at the time
userspace wants to read the data -- a previous read on a
different subflow might have carried this data already.
In that (unlikely) event, msk->ack_seq will have been updated
and will be ahead of the subflow dsn.
We can check for this condition and skip/resync to the expected
sequence number.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 75ae03931963..02aba8b31f1f 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -205,8 +205,24 @@ static struct sock *mptcp_subflow_recv_lookup(const struct mptcp_sock *msk)
sock_owned_by_me(sk);
mptcp_for_each_subflow(msk, subflow) {
- if (subflow->data_avail)
- return mptcp_subflow_tcp_sock(subflow);
+ if (subflow->data_avail) {
+ struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
+ u64 dsn = mptcp_subflow_get_mapped_dsn(subflow);
+
+ /* revalidate data sequence number.
+ *
+ * mptcp_subflow_data_available() is usually called
+ * without msk lock. Its unlikely (but possible)
+ * that msk->ack_seq has been advanced since the last
+ * call found in-sequence data.
+ */
+ if (likely(dsn == msk->ack_seq))
+ return ssk;
+
+ subflow->data_avail = 0;
+ if (mptcp_subflow_data_available(ssk))
+ return ssk;
+ }
}
return NULL;
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 4/6] mptcp: remove mptcp_read_actor
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Only used to discard stale data from the subflow, so move
it where needed.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 27 ---------------------------
net/mptcp/protocol.h | 7 -------
net/mptcp/subflow.c | 18 +++++++++++++-----
3 files changed, 13 insertions(+), 39 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index ac81283d5ec3..75ae03931963 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -616,33 +616,6 @@ static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
return ret;
}
-int mptcp_read_actor(read_descriptor_t *desc, struct sk_buff *skb,
- unsigned int offset, size_t len)
-{
- struct mptcp_read_arg *arg = desc->arg.data;
- size_t copy_len;
-
- copy_len = min(desc->count, len);
-
- if (likely(arg->msg)) {
- int err;
-
- err = skb_copy_datagram_msg(skb, offset, arg->msg, copy_len);
- if (err) {
- pr_debug("error path");
- desc->error = err;
- return err;
- }
- } else {
- pr_debug("Flushing skb payload");
- }
-
- desc->count -= copy_len;
-
- pr_debug("consumed %zu bytes, %zu left", copy_len, desc->count);
- return copy_len;
-}
-
static void mptcp_wait_data(struct sock *sk, long *timeo)
{
DEFINE_WAIT_FUNC(wait, woken_wake_function);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index d676b7b6bbd3..c6f955f0fd0b 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -304,13 +304,6 @@ void mptcp_proto_init(void);
int mptcp_proto_v6_init(void);
#endif
-struct mptcp_read_arg {
- struct msghdr *msg;
-};
-
-int mptcp_read_actor(read_descriptor_t *desc, struct sk_buff *skb,
- unsigned int offset, size_t len);
-
void mptcp_get_options(const struct sk_buff *skb,
struct tcp_options_received *opt_rx);
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index fbff5dc39575..da984f2af7ac 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -577,6 +577,18 @@ static enum mapping_status get_mapping_status(struct sock *ssk)
return MAPPING_OK;
}
+static int subflow_read_actor(read_descriptor_t *desc,
+ struct sk_buff *skb,
+ unsigned int offset, size_t len)
+{
+ size_t copy_len = min(desc->count, len);
+
+ desc->count -= copy_len;
+
+ pr_debug("flushed %zu bytes, %zu left", copy_len, desc->count);
+ return copy_len;
+}
+
static bool subflow_check_data_avail(struct sock *ssk)
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
@@ -651,16 +663,12 @@ static bool subflow_check_data_avail(struct sock *ssk)
pr_debug("discarding %zu bytes, current map len=%d", delta,
map_remaining);
if (delta) {
- struct mptcp_read_arg arg = {
- .msg = NULL,
- };
read_descriptor_t desc = {
.count = delta,
- .arg.data = &arg,
};
int ret;
- ret = tcp_read_sock(ssk, &desc, mptcp_read_actor);
+ ret = tcp_read_sock(ssk, &desc, subflow_read_actor);
if (ret < 0) {
ssk->sk_err = -ret;
goto fatal;
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 3/6] mptcp: add rmem queue accounting
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]
If userspace never drains the receive buffers we must stop draining
the subflow socket(s) at some point.
This adds the needed rmem accouting for this.
If the threshold is reached, we stop draining the subflows.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 85d7f73ca804..ac81283d5ec3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -172,6 +172,10 @@ void mptcp_data_ready(struct sock *sk)
if (test_and_set_bit(MPTCP_WORK_DATA_READY, &msk->flags))
return;
+ /* don't schedule if mptcp sk is (still) over limit */
+ if (atomic_read(&sk->sk_rmem_alloc) > READ_ONCE(sk->sk_rcvbuf))
+ return;
+
sock_hold(sk);
if (!schedule_work(&msk->rtx_work))
sock_put(sk);
@@ -699,7 +703,7 @@ static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
struct sock *sk = (struct sock *)msk;
__skb_unlink(skb, &ssk->sk_receive_queue);
- skb_orphan(skb);
+ skb_set_owner_r(skb, sk);
__skb_queue_tail(&sk->sk_receive_queue, skb);
msk->ack_seq += copy_len;
@@ -717,6 +721,7 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
struct sock *ssk;
bool more_data_avail;
struct tcp_sock *tp;
+ int rcvbuf;
ssk = mptcp_subflow_recv_lookup(msk);
if (!ssk)
@@ -726,6 +731,10 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
lock_sock(ssk);
+ rcvbuf = max(ssk->sk_rcvbuf, sk->sk_rcvbuf);
+ if (rcvbuf > sk->sk_rcvbuf)
+ sk->sk_rcvbuf = rcvbuf;
+
tp = tcp_sk(ssk);
do {
u32 map_remaining, offset;
@@ -741,6 +750,11 @@ static bool __mptcp_move_skbs(struct mptcp_sock *msk)
if (!skb)
break;
+ if (!sk_rmem_schedule(sk, skb, skb->truesize)) {
+ done = true;
+ break;
+ }
+
offset = seq - TCP_SKB_CB(skb)->seq;
fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
if (fin) {
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 2/6] mptcp: update mptcp ack sequence from work queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 9967 bytes --]
This adds a new worker flag to indicate when the work queue should
drain a subflow socket.
skbs on the subflow socket are then placed on the mptcp socket receive
queue (which was not used so far).
This allows us to announce the correct mptcp ack sequence in the tcp
acks that we send back to the peer, even when the application does not
call recv() on the mptcp socket for some time.
We still wake userspace tasks waiting for POLLIN immediately:
If the mptcp level receive queue is empty (because the work queue is
still pending) it can be filled from in-sequence subflow sockets at
recv time.
Without this, when userspace is not reading data, all the mptcp-level
acks contain the ack_seq from the last time userspace read data rather
than the most recent in-sequence value. This causes pointless
retransmissions for data that is already queued.
The skb_orphan when moving skbs from subflow to mptcp level is needed,
because the destructor (sock_rfree) relies on skb->sk (ssk!) lock
being taken.
Followup patch will add needed rmem accouting for the moved skbs.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 231 ++++++++++++++++++++++++++++++-------------
net/mptcp/protocol.h | 1 +
2 files changed, 164 insertions(+), 68 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 84204129e1d3..85d7f73ca804 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -34,6 +34,12 @@ struct mptcp6_sock {
static struct percpu_counter mptcp_sockets_allocated;
+struct mptcp_skb_cb {
+ u32 offset;
+};
+
+#define MPTCP_SKB_CB(__skb) ((struct mptcp_skb_cb *)&((__skb)->cb[0]))
+
/* If msk has an initial subflow socket, and the MP_CAPABLE handshake has not
* completed yet or has failed, return the subflow socket.
* Otherwise return NULL.
@@ -162,6 +168,13 @@ void mptcp_data_ready(struct sock *sk)
set_bit(MPTCP_DATA_READY, &msk->flags);
sk->sk_data_ready(sk);
+
+ if (test_and_set_bit(MPTCP_WORK_DATA_READY, &msk->flags))
+ return;
+
+ sock_hold(sk);
+ if (!schedule_work(&msk->rtx_work))
+ sock_put(sk);
}
static void mptcp_stop_timer(struct sock *sk)
@@ -641,19 +654,134 @@ static void mptcp_wait_data(struct sock *sk, long *timeo)
remove_wait_queue(sk_sleep(sk), &wait);
}
+static int __mptcp_recvmsg_mskq(struct mptcp_sock *msk,
+ struct msghdr *msg,
+ size_t len)
+{
+ struct sock *sk = (struct sock *)msk;
+ struct sk_buff *skb;
+ int copied = 0;
+
+ while ((skb = skb_peek(&sk->sk_receive_queue)) != NULL) {
+ u32 offset = MPTCP_SKB_CB(skb)->offset;
+ u32 data_len = skb->len - offset;
+ u32 count = min_t(size_t, len - copied, data_len);
+ int err;
+
+ err = skb_copy_datagram_msg(skb, offset, msg, count);
+ if (unlikely(err < 0)) {
+ if (!copied)
+ return err;
+ break;
+ }
+
+ copied += count;
+
+ if (count < data_len) {
+ MPTCP_SKB_CB(skb)->offset += count;
+ break;
+ }
+
+ __skb_unlink(skb, &sk->sk_receive_queue);
+ __kfree_skb(skb);
+
+ if (copied >= len)
+ break;
+ }
+
+ return copied;
+}
+
+static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
+ struct sk_buff *skb,
+ unsigned int offset, size_t copy_len)
+{
+ struct sock *sk = (struct sock *)msk;
+
+ __skb_unlink(skb, &ssk->sk_receive_queue);
+ skb_orphan(skb);
+ __skb_queue_tail(&sk->sk_receive_queue, skb);
+
+ msk->ack_seq += copy_len;
+ MPTCP_SKB_CB(skb)->offset = offset;
+}
+
+static bool __mptcp_move_skbs(struct mptcp_sock *msk)
+{
+ struct sock *sk = &msk->sk.icsk_inet.sk;
+ unsigned int moved = 0;
+ bool done = false;
+
+ do {
+ struct mptcp_subflow_context *subflow;
+ struct sock *ssk;
+ bool more_data_avail;
+ struct tcp_sock *tp;
+
+ ssk = mptcp_subflow_recv_lookup(msk);
+ if (!ssk)
+ break;
+
+ subflow = mptcp_subflow_ctx(ssk);
+
+ lock_sock(ssk);
+
+ tp = tcp_sk(ssk);
+ do {
+ u32 map_remaining, offset;
+ u32 seq = tp->copied_seq;
+ struct sk_buff *skb;
+ bool fin;
+
+ /* try to move as much data as available */
+ map_remaining = subflow->map_data_len -
+ mptcp_subflow_get_map_offset(subflow);
+
+ skb = skb_peek(&ssk->sk_receive_queue);
+ if (!skb)
+ break;
+
+ offset = seq - TCP_SKB_CB(skb)->seq;
+ fin = TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN;
+ if (fin) {
+ done = true;
+ seq++;
+ }
+
+ if (offset < skb->len) {
+ size_t len = skb->len - offset;
+
+ if (tp->urg_data)
+ done = true;
+
+ __mptcp_move_skb(msk, ssk, skb, offset, len);
+ seq += len;
+ moved += len;
+
+ if (WARN_ON_ONCE(map_remaining < len))
+ break;
+ } else {
+ WARN_ON_ONCE(!fin);
+ sk_eat_skb(sk, skb);
+ done = true;
+ }
+
+ WRITE_ONCE(tp->copied_seq, seq);
+ more_data_avail = mptcp_subflow_data_available(ssk);
+ } while (more_data_avail);
+
+ release_sock(ssk);
+ } while (!done);
+
+ return moved > 0;
+}
+
+
static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
int nonblock, int flags, int *addr_len)
{
struct mptcp_sock *msk = mptcp_sk(sk);
- struct mptcp_subflow_context *subflow;
- bool more_data_avail = false;
- struct mptcp_read_arg arg;
- read_descriptor_t desc;
- bool wait_data = false;
struct socket *ssock;
- struct tcp_sock *tp;
- bool done = false;
- struct sock *ssk;
int copied = 0;
int target;
long timeo;
@@ -671,66 +799,27 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
return copied;
}
- arg.msg = msg;
- desc.arg.data = &arg;
- desc.error = 0;
-
timeo = sock_rcvtimeo(sk, nonblock);
len = min_t(size_t, len, INT_MAX);
target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
__mptcp_flush_join_list(msk);
- while (!done) {
- u32 map_remaining;
+ while (len > (size_t)copied) {
int bytes_read;
- ssk = mptcp_subflow_recv_lookup(msk);
- pr_debug("msk=%p ssk=%p", msk, ssk);
- if (!ssk)
- goto wait_for_data;
+ bytes_read = __mptcp_recvmsg_mskq(msk, msg, len - copied);
+ if (unlikely(bytes_read < 0)) {
+ if (!copied)
+ copied = bytes_read;
+ goto out_err;
+ }
- subflow = mptcp_subflow_ctx(ssk);
- tp = tcp_sk(ssk);
+ copied += bytes_read;
- lock_sock(ssk);
- do {
- /* try to read as much data as available */
- map_remaining = subflow->map_data_len -
- mptcp_subflow_get_map_offset(subflow);
- desc.count = min_t(size_t, len - copied, map_remaining);
- pr_debug("reading %zu bytes, copied %d", desc.count,
- copied);
- bytes_read = tcp_read_sock(ssk, &desc,
- mptcp_read_actor);
- if (bytes_read < 0) {
- if (!copied)
- copied = bytes_read;
- done = true;
- goto next;
- }
-
- pr_debug("msk ack_seq=%llx -> %llx", msk->ack_seq,
- msk->ack_seq + bytes_read);
- msk->ack_seq += bytes_read;
- copied += bytes_read;
- if (copied >= len) {
- done = true;
- goto next;
- }
- if (tp->urg_data && tp->urg_seq == tp->copied_seq) {
- pr_err("Urgent data present, cannot proceed");
- done = true;
- goto next;
- }
-next:
- more_data_avail = mptcp_subflow_data_available(ssk);
- } while (more_data_avail && !done);
- release_sock(ssk);
- continue;
-
-wait_for_data:
- more_data_avail = false;
+ if (skb_queue_empty(&sk->sk_receive_queue) &&
+ __mptcp_move_skbs(msk))
+ continue;
/* only the master socket status is relevant here. The exit
* conditions mirror closely tcp_recvmsg()
@@ -771,26 +860,25 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
}
pr_debug("block timeout %ld", timeo);
- wait_data = true;
mptcp_wait_data(sk, &timeo);
if (unlikely(__mptcp_tcp_fallback(msk)))
goto fallback;
}
- if (more_data_avail) {
- if (!test_bit(MPTCP_DATA_READY, &msk->flags))
- set_bit(MPTCP_DATA_READY, &msk->flags);
- } else if (!wait_data) {
+ if (skb_queue_empty(&sk->sk_receive_queue)) {
+ /* entire backlog drained, clear DATA_READY. */
clear_bit(MPTCP_DATA_READY, &msk->flags);
- /* .. race-breaker: ssk might get new data after last
- * data_available() returns false.
+ /* .. race-breaker: ssk might have gotten new data
+ * after last __mptcp_move_skbs() returned false.
*/
- ssk = mptcp_subflow_recv_lookup(msk);
- if (unlikely(ssk))
+ if (unlikely(__mptcp_move_skbs(msk)))
set_bit(MPTCP_DATA_READY, &msk->flags);
+ } else if (unlikely(!test_bit(MPTCP_DATA_READY, &msk->flags))) {
+ /* data to read but mptcp_wait_data() cleared DATA_READY */
+ set_bit(MPTCP_DATA_READY, &msk->flags);
}
-
+out_err:
release_sock(sk);
return copied;
}
@@ -921,6 +1009,9 @@ static void mptcp_worker(struct work_struct *work)
lock_sock(sk);
mptcp_clean_una(sk);
+ if (test_and_clear_bit(MPTCP_WORK_DATA_READY, &msk->flags))
+ __mptcp_move_skbs(msk);
+
if (test_and_clear_bit(MPTCP_WORK_EOF, &msk->flags))
mptcp_check_for_eof(msk);
@@ -1085,6 +1176,8 @@ static void mptcp_close(struct sock *sk, long timeout)
mptcp_cancel_work(sk);
+ __skb_queue_purge(&sk->sk_receive_queue);
+
sk_common_release(sk);
}
@@ -1755,6 +1848,8 @@ void mptcp_proto_init(void)
panic("Failed to register MPTCP proto.\n");
inet_register_protosw(&mptcp_protosw);
+
+ BUILD_BUG_ON(sizeof(struct mptcp_skb_cb) > sizeof_field(struct sk_buff, cb));
}
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 95b0ade75771..d676b7b6bbd3 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -82,6 +82,7 @@
#define MPTCP_SEND_SPACE BIT(1)
#define MPTCP_WORK_RTX BIT(2)
#define MPTCP_WORK_EOF BIT(3)
+#define MPTCP_WORK_DATA_READY BIT(4)
static inline __be32 mptcp_option(u8 subopt, u8 len, u8 nib, u8 field)
{
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 1/6] mptcp: add and use mptcp_data_ready helper
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
allows us to schedule the work queue to drain the ssk receive queue in
a followup patch.
This is needed to avoid sending all-to-pessimistic mptcp-level
acknowledgements. At this time, the ack_seq is what was last read by
userspace instead of the highest in-sequence number queued for reading.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 8 ++++++++
net/mptcp/protocol.h | 1 +
net/mptcp/subflow.c | 14 ++++----------
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 47b3c4afdc87..84204129e1d3 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -156,6 +156,14 @@ void mptcp_subflow_eof(struct sock *sk)
sock_hold(sk);
}
+void mptcp_data_ready(struct sock *sk)
+{
+ struct mptcp_sock *msk = mptcp_sk(sk);
+
+ set_bit(MPTCP_DATA_READY, &msk->flags);
+ sk->sk_data_ready(sk);
+}
+
static void mptcp_stop_timer(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 3fbb33deb764..95b0ade75771 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -317,6 +317,7 @@ void mptcp_finish_connect(struct sock *sk);
void mptcp_subflow_eof(struct sock *sk);
bool mptcp_finish_join(struct sock *sk);
void mptcp_data_acked(struct sock *sk);
+void mptcp_data_ready(struct sock *sk);
int mptcp_token_new_request(struct request_sock *req);
void mptcp_token_destroy_request(u32 token);
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 547d5ffef070..fbff5dc39575 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -723,11 +723,8 @@ static void subflow_data_ready(struct sock *sk)
return;
}
- if (mptcp_subflow_data_available(sk)) {
- set_bit(MPTCP_DATA_READY, &mptcp_sk(parent)->flags);
-
- parent->sk_data_ready(parent);
- }
+ if (mptcp_subflow_data_available(sk))
+ mptcp_data_ready(parent);
}
static void subflow_write_space(struct sock *sk)
@@ -916,11 +913,8 @@ static void subflow_state_change(struct sock *sk)
* a fin packet carrying a DSS can be unnoticed if we don't trigger
* the data available machinery here.
*/
- if (parent && subflow->mp_capable && mptcp_subflow_data_available(sk)) {
- set_bit(MPTCP_DATA_READY, &mptcp_sk(parent)->flags);
-
- parent->sk_data_ready(parent);
- }
+ if (parent && subflow->mp_capable && mptcp_subflow_data_available(sk))
+ mptcp_data_ready(parent);
if (parent && !(parent->sk_shutdown & RCV_SHUTDOWN) &&
!subflow->rx_eof && subflow_is_done(sk)) {
--
2.24.1
^ permalink raw reply related
* [MPTCP] [PATCH v3 0/6] mptcp: update mptcp ack sequence from work queue
From: Florian Westphal @ 2020-02-20 14:34 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
V3. No changes since v2, I only updated commit messages in
patches 1, 2, 3 and 6.
I think we should try to avoid needless squashing and keep
these as-is for now. We can always condense some of this later
on in case we need to reduce number of individual patches for some
reason.
^ permalink raw reply
* [PATCH] env: ti: boot: Fix Android boot on AM57x EVM
From: Eugeniu Rosca @ 2020-02-20 14:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200219182752.27392-1-joe.skb7@gmail.com>
Hi Sam,
On Wed, Feb 19, 2020 at 08:27:52PM +0200, Sam Protsenko wrote:
> When applying DTBO on top of DTB (with "fdt apply" command) on AM57x EVM
> board, there is not enough memory reserved in RAM for DTB blob. Hence,
> DTBO can't be merged in DTB. It leads to inability to boot Android with
> next error message:
>
> failed on fdt_overlay_apply(): FDT_ERR_NOSPACE
>
> To overcome that issue let's provide 1 MiB of space to keep DTB and all
> merged DTBO blobs. To do so, "length" parameter should be specified for
> "fdt addr" command:
>
> => fdt addr $fdtaddr 0x100000
I am not an everyday user of this platform, hence curious what are the
usual sizes of DTB and DTBO files employed in Android booting?
For comparison, below are the sizes of R-Car3 DTB (Linux v5.6-rc2):
$ du -sh arch/arm64/boot/dts/renesas/r8a779*dtb | sort -n
32K arch/arm64/boot/dts/renesas/r8a77961-salvator-xs.dtb
32K arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dtb
44K arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb
52K arch/arm64/boot/dts/renesas/r8a77965-ulcb.dtb
60K arch/arm64/boot/dts/renesas/r8a77960-ulcb.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dtb
60K arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-salvator-x.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-salvator-xs.dtb
64K arch/arm64/boot/dts/renesas/r8a77960-ulcb-kf.dtb
68K arch/arm64/boot/dts/renesas/r8a77950-ulcb.dtb
68K arch/arm64/boot/dts/renesas/r8a77951-ulcb.dtb
72K arch/arm64/boot/dts/renesas/r8a77950-salvator-x.dtb
72K arch/arm64/boot/dts/renesas/r8a77950-ulcb-kf.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-salvator-x.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb
72K arch/arm64/boot/dts/renesas/r8a77951-ulcb-kf.dtb
FWIW based on the above values, Renesas scripts reserve 512K for DTB.
>
> Also add size variables to 'adtimg' command invocations, to avoid
> cluttering the console with DTBO blob sizes.
Looks good to me.
>
> Signed-off-by: Sam Protsenko <joe.skb7@gmail.com>
Reviewed-by: Eugeniu Rosca <rosca.eugeniu@gmail.com>
--
Best Regards
Eugeniu Rosca
^ permalink raw reply
* [igt-dev] [PATCH] Reduce Docker images size
From: Ramotowski, Maciej @ 2020-02-20 14:32 UTC (permalink / raw)
To: igt-dev@lists.freedesktop.org
Cc: Ramotowski, Maciej, Oleg Vasilev, Latvala, Petri
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Oleg Vasilev <oleg.vasilev@intel.com>
Cc: Petri Latvala <petri.latvala@intel.com>
Signed-off-by: Maciej Ramotowski <maciej.ramotowski@intel.com>
---
Dockerfile.build-debian | 39 ++++++++----------
Dockerfile.build-debian-arm64 | 68 +++++++++++++++-----------------
Dockerfile.build-debian-armhf | 67 +++++++++++++++----------------
Dockerfile.build-debian-minimal | 44 ++++++++++-----------
Dockerfile.build-debian-mips | 70 +++++++++++++++------------------
5 files changed, 132 insertions(+), 156 deletions(-)
diff --git a/Dockerfile.build-debian b/Dockerfile.build-debian
index b143a532..6cf7a1f0 100644
--- a/Dockerfile.build-debian
+++ b/Dockerfile.build-debian
@@ -7,25 +7,20 @@ FROM $CI_REGISTRY_IMAGE/build-debian-minimal:commit-$CI_COMMIT_SHA
# just few extra dependencies for building IGT with all the optional components
# enabled
-RUN apt-get update
-RUN apt-get install -y \
- libunwind-dev \
- libgsl-dev \
- libasound2-dev \
- libxmlrpc-core-c3-dev \
- libjson-c-dev \
- libcurl4-openssl-dev \
- python-docutils \
- valgrind \
- peg \
- libdrm-intel1
-
-# autotools build deps
-RUN apt-get install -y \
- autoconf \
- automake \
- xutils-dev \
- libtool \
- make
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ autoconf \
+ automake \
+ libasound2-dev \
+ libcurl4-openssl-dev \
+ libdrm-intel1 \
+ libgsl-dev \
+ libjson-c-dev \
+ libtool \
+ libunwind-dev \
+ libxmlrpc-core-c3-dev \
+ make \
+ peg \
+ python-docutils \
+ valgrind \
+ xutils-dev \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-arm64 b/Dockerfile.build-debian-arm64
index 573c7096..924432bd 100644
--- a/Dockerfile.build-debian-arm64
+++ b/Dockerfile.build-debian-arm64
@@ -1,40 +1,34 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture arm64
-RUN apt-get update
-RUN apt-get install -y \
- gcc-aarch64-linux-gnu \
- libatomic1:arm64 \
- libpciaccess-dev:arm64 \
- libkmod-dev:arm64 \
- libprocps-dev:arm64 \
- libunwind-dev:arm64 \
- libdw-dev:arm64 \
- zlib1g-dev:arm64 \
- liblzma-dev:arm64 \
- libcairo-dev:arm64 \
- libpixman-1-dev:arm64 \
- libudev-dev:arm64 \
- libgsl-dev:arm64 \
- libasound2-dev:arm64 \
- libjson-c-dev:arm64 \
- libcurl4-openssl-dev:arm64 \
- libxrandr-dev:arm64 \
- libxv-dev:arm64 \
- meson \
- libdrm-dev:arm64 \
- qemu-user \
- qemu-user-static
-
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-aarch64-linux-gnu \
+ libasound2-dev:arm64 \
+ libatomic1:arm64 \
+ libcairo-dev:arm64 \
+ libcurl4-openssl-dev:arm64 \
+ libdrm-dev:arm64 \
+ libdw-dev:arm64 \
+ libgsl-dev:arm64 \
+ libjson-c-dev:arm64 \
+ libkmod-dev:arm64 \
+ liblzma-dev:arm64 \
+ libpciaccess-dev:arm64 \
+ libpixman-1-dev:arm64 \
+ libprocps-dev:arm64 \
+ libudev-dev:arm64 \
+ libunwind-dev:arm64 \
+ libxrandr-dev:arm64 \
+ libxv-dev:arm64 \
+ meson \
+ peg \
+ pkg-config \
+ python-docutils \
+ qemu-user \
+ qemu-user-static \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:arm64 \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-armhf b/Dockerfile.build-debian-armhf
index 737ca364..3752dc91 100644
--- a/Dockerfile.build-debian-armhf
+++ b/Dockerfile.build-debian-armhf
@@ -1,39 +1,34 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture armhf
-RUN apt-get update
-RUN apt-get install -y \
- gcc-arm-linux-gnueabihf \
- libatomic1:armhf \
- libpciaccess-dev:armhf \
- libkmod-dev:armhf \
- libprocps-dev:armhf \
- libunwind-dev:armhf \
- libdw-dev:armhf \
- zlib1g-dev:armhf \
- liblzma-dev:armhf \
- libcairo-dev:armhf \
- libpixman-1-dev:armhf \
- libudev-dev:armhf \
- libgsl-dev:armhf \
- libasound2-dev:armhf \
- libjson-c-dev:armhf \
- libcurl4-openssl-dev:armhf \
- libxrandr-dev:armhf \
- libxv-dev:armhf \
- meson \
- libdrm-dev:armhf \
- qemu-user \
- qemu-user-static
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-arm-linux-gnueabihf \
+ libasound2-dev:armhf \
+ libatomic1:armhf \
+ libcairo-dev:armhf \
+ libcurl4-openssl-dev:armhf \
+ libdrm-dev:armhf \
+ libdw-dev:armhf \
+ libgsl-dev:armhf \
+ libjson-c-dev:armhf \
+ libkmod-dev:armhf \
+ liblzma-dev:armhf \
+ libpciaccess-dev:armhf \
+ libpixman-1-dev:armhf \
+ libprocps-dev:armhf \
+ libudev-dev:armhf \
+ libunwind-dev:armhf \
+ libxrandr-dev:armhf \
+ libxv-dev:armhf \
+ meson \
+ peg \
+ pkg-config \
+ python-docutils \
+ qemu-user \
+ qemu-user-static \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:armhf \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-minimal b/Dockerfile.build-debian-minimal
index 64edf4b4..d0756be5 100644
--- a/Dockerfile.build-debian-minimal
+++ b/Dockerfile.build-debian-minimal
@@ -1,25 +1,23 @@
FROM debian:buster
-RUN apt-get update
-RUN apt-get install -y \
- gcc \
- flex \
- bison \
- pkg-config \
- libatomic1 \
- libpciaccess-dev \
- libkmod-dev \
- libprocps-dev \
- libdw-dev \
- zlib1g-dev \
- liblzma-dev \
- libcairo-dev \
- libpixman-1-dev \
- libudev-dev \
- libxrandr-dev \
- libxv-dev \
- x11proto-dri2-dev \
- meson \
- libdrm-dev
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc \
+ libatomic1 \
+ libcairo-dev \
+ libdrm-dev \
+ libdw-dev \
+ libkmod-dev \
+ liblzma-dev \
+ libpciaccess-dev \
+ libpixman-1-dev \
+ libprocps-dev \
+ libudev-dev \
+ libxrandr-dev \
+ libxv-dev \
+ meson \
+ pkg-config \
+ x11proto-dri2-dev \
+ zlib1g-dev \
+ && rm -rf /var/lib/apt/lists/*
diff --git a/Dockerfile.build-debian-mips b/Dockerfile.build-debian-mips
index 7e4bacdf..e52d403b 100644
--- a/Dockerfile.build-debian-mips
+++ b/Dockerfile.build-debian-mips
@@ -2,42 +2,36 @@
# https://bugs.debian.org/932725
FROM debian:stretch-backports
-RUN apt-get update
-RUN apt-get install -y \
- flex \
- bison \
- pkg-config \
- x11proto-dri2-dev \
- python-docutils \
- valgrind \
- peg
-
RUN dpkg --add-architecture mips
-RUN apt-get update
-RUN apt-get install -y \
- gcc-mips-linux-gnu \
- libatomic1:mips \
- libpciaccess-dev:mips \
- libkmod-dev:mips \
- libprocps-dev:mips \
- libunwind-dev:mips \
- libdw-dev:mips \
- zlib1g-dev:mips \
- liblzma-dev:mips \
- libcairo-dev:mips \
- libpixman-1-dev:mips \
- libudev-dev:mips \
- libgsl-dev:mips \
- libasound2-dev:mips \
- libjson-c-dev:mips \
- libcurl4-openssl-dev:mips \
- libxrandr-dev:mips \
- libxv-dev:mips
-
-RUN apt-get install -t stretch-backports -y \
- meson \
- libdrm-dev:mips \
- qemu-user \
- qemu-user-static
-
-RUN apt-get clean
+RUN apt-get update && apt-get install -y \
+ bison \
+ flex \
+ gcc-mips-linux-gnu \
+ libasound2-dev:mips \
+ libatomic1:mips \
+ libcairo-dev:mips \
+ libcurl4-openssl-dev:mips \
+ libdw-dev:mips \
+ libgsl-dev:mips \
+ libjson-c-dev:mips \
+ libkmod-dev:mips \
+ liblzma-dev:mips \
+ libpciaccess-dev:mips \
+ libpixman-1-dev:mips \
+ libprocps-dev:mips \
+ libudev-dev:mips \
+ libunwind-dev:mips \
+ libxrandr-dev:mips \
+ libxv-dev:mips \
+ peg \
+ pkg-config \
+ python-docutils \
+ valgrind \
+ x11proto-dri2-dev \
+ zlib1g-dev:mips \
+ && apt-get install -t stretch-backports -y \
+ libdrm-dev:mips \
+ meson \
+ qemu-user \
+ qemu-user-static \
+ && rm -rf /var/lib/apt/lists/*
--
2.17.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-3-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
From: chris hyser @ 2020-02-20 14:30 UTC (permalink / raw)
To: Parth Shah, vincent.guittot, patrick.bellasi, valentin.schneider,
dhaval.giani, dietmar.eggemann
Cc: linux-kernel, peterz, mingo, qais.yousef, pavel, qperret,
David.Laight, pjt, tj
In-Reply-To: <7429e0ae-41ff-e9c4-dd65-3ef1919f5f50@linux.ibm.com>
On 2/20/20 3:50 AM, Parth Shah wrote:
>
>
> On 2/20/20 2:04 PM, Parth Shah wrote:
>>
>>
>> On 2/19/20 11:53 PM, chris hyser wrote:
>>>
>>>
>>> On 2/19/20 9:15 AM, chris hyser wrote:
>>>>
>>>>
>>>> On 2/19/20 5:09 AM, Parth Shah wrote:
>>>>> Hi Chris,
>>>>>
>>>>> On 2/19/20 4:30 AM, chris hyser wrote:
>>>>>> On 2/17/20 3:57 AM, Parth Shah wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/16/20 5:32 PM, Parth Shah wrote:
>>>>>>>> This is the 3rd revision of the patch set to introduce
>>>>>>>> latency_{nice/tolerance} as a per task attribute.
>>>>>>>>
>>>>>>>> The previous version can be found at:
>>>>>>>> v1: https://lkml.org/lkml/2019/11/25/151
>>>>>>>> v2: https://lkml.org/lkml/2019/12/8/10
>>>>>>>>
>>>>>>>> Changes in this revision are:
>>>>>>>> v2 -> v3:
>>>>>>>> - This series changes the longer attribute name to "latency_nice" as per
>>>>>>>> the comment from Dietmar Eggemann
>>>>>>>> https://lkml.org/lkml/2019/12/5/394
>>>>>>>> v1 -> v2:
>>>>>>>> - Addressed comments from Qais Yousef
>>>>>>>> - As per suggestion from Dietmar, moved content from newly created
>>>>>>>> include/linux/sched/latency_tolerance.h to kernel/sched/sched.h
>>>>>>>> - Extend sched_setattr() to support latency_tolerance in tools
>>>>>>>> headers UAPI
>>>>>>>>
>>>>>>>>
>>>>>>>> Introduction:
>>>>>>>> ==============
>>>>>>>> This patch series introduces a new per-task attribute latency_nice to
>>>>>>>> provide the scheduler hints about the latency requirements of the
>>>>>>>> task [1].
>>>>>>>>
>>>>>>>> Latency_nice is a ranged attribute of a task with the value ranging
>>>>>>>> from [-20, 19] both inclusive which makes it align with the task nice
>>>>>>>> value.
>>>>>>>>
>>>>>>>> The value should provide scheduler hints about the relative latency
>>>>>>>> requirements of tasks, meaning the task with "latency_nice = -20"
>>>>>>>> should have lower latency requirements than compared to those tasks with
>>>>>>>> higher values. Similarly a task with "latency_nice = 19" can have higher
>>>>>>>> latency and hence such tasks may not care much about latency.
>>>>>>>>
>>>>>>>> The default value is set to 0. The usecases discussed below can use this
>>>>>>>> range of [-20, 19] for latency_nice for the specific purpose. This
>>>>>>>> patch does not implement any use cases for such attribute so that any
>>>>>>>> change in naming or range does not affect much to the other (future)
>>>>>>>> patches using this. The actual use of latency_nice during task wakeup
>>>>>>>> and load-balancing is yet to be coded for each of those usecases.
>>>>>>>>
>>>>>>>> As per my view, this defined attribute can be used in following ways
>>>>>>>> for a
>>>>>>>> some of the usecases:
>>>>>>>> 1 Reduce search scan time for select_idle_cpu():
>>>>>>>> - Reduce search scans for finding idle CPU for a waking task with lower
>>>>>>>> latency_nice values.
>>>>>>>>
>>>>>>>> 2 TurboSched:
>>>>>>>> - Classify the tasks with higher latency_nice values as a small
>>>>>>>> background task given that its historic utilization is very low, for
>>>>>>>> which the scheduler can search for more number of cores to do task
>>>>>>>> packing. A task with a latency_nice >= some_threshold (e.g, == 19)
>>>>>>>> and util <= 12.5% can be background tasks.
>>>>>>>>
>>>>>>>> 3 Optimize AVX512 based workload:
>>>>>>>> - Bias scheduler to not put a task having (latency_nice == -20) on a
>>>>>>>> core occupying AVX512 based workload.
>>>>>>>>
>>>>>>>>
>>>>>>>> Series Organization:
>>>>>>>> ====================
>>>>>>>> - Patch 1: Add new attribute latency_nice to task_struct.
>>>>>>>> - Patch 2: Clone parent task's attribute to the child task on fork
>>>>>>>> - Patch 3: Add support for sched_{set,get}attr syscall to modify
>>>>>>>> latency_nice of the task
>>>>>>>>
>>>>>>>>
>>>>>>>> The patch series can be applied on tip/sched/core at the
>>>>>>>> commit 804d402fb6f6 ("sched/rt: Make RT capacity-aware")
>>>>>>>>
>>>>>>>>
>>>>>>>> References:
>>>>>>>> ============
>>>>>>>> [1]. Usecases for the per-task latency-nice attribute,
>>>>>>>> https://lkml.org/lkml/2019/9/30/215
>>>>>>>> [2]. Task Latency-nice, "Subhra Mazumdar",
>>>>>>>> https://lkml.org/lkml/2019/8/30/829
>>>>>>>> [3]. Introduce per-task latency_tolerance for scheduler hints,
>>>>>>>> https://lkml.org/lkml/2019/12/8/10
>>>>>>>>
>>>>>>>>
>>>>>>>> Parth Shah (3):
>>>>>>>> sched: Introduce latency-nice as a per-task attribute
>>>>>>>> sched/core: Propagate parent task's latency requirements to the
>>>>>>>> child
>>>>>>>> task
>>>>>>>> sched: Allow sched_{get,set}attr to change latency_nice of the task
>>>>>>>>
>>>>>>>> include/linux/sched.h | 1 +
>>>>>>>> include/uapi/linux/sched.h | 4 +++-
>>>>>>>> include/uapi/linux/sched/types.h | 19 +++++++++++++++++++
>>>>>>>> kernel/sched/core.c | 21 +++++++++++++++++++++
>>>>>>>> kernel/sched/sched.h | 18 ++++++++++++++++++
>>>>>>>> tools/include/uapi/linux/sched.h | 4 +++-
>>>>>>>> 6 files changed, 65 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> Its been a long time and few revisions since the beginning of the
>>>>>>> discussion around the latency-nice. Hence thought of asking if there
>>>>>>> is/are
>>>>>>> any further work that needs to be done for adding latency-nice
>>>>>>> attribute or
>>>>>>> am I missing any piece in here?
>>>>>>
>>>>>> All, I was asked to take a look at the original latency_nice patchset.
>>>>>> First, to clarify objectives, Oracle is not interested in trading
>>>>>> throughput for latency. What we found is that the DB has specific tasks
>>>>>> which do very little but need to do this as absolutely quickly as
>>>>>> possible,
>>>>>> ie extreme latency sensitivity. Second, the key to latency reduction in
>>>>>> the
>>>>>> task wakeup path seems to be limiting variations of "idle cpu" search. The
>>>>>> latter particularly interests me as an example of "platform size based
>>>>>> latency" which I believe to be important given all the varying size VMs
>>>>>> and
>>>>>> containers.
>>>>>>
>>>>>> Parth, I've been using your v3 patchset as the basis of an investigation
>>>>>> into the measurable effects of short-circuiting this search. I'm not quite
>>>>>> ready to put anything out, but the patchset is working well. The only
>>>>>
>>>>> That's a good news as you are able to get a usecase of this patch-set.
>>>>>
>>>>>> feedback I have is that currently non-root can set the value negative
>>>>>> which
>>>>>> is inconsistent with 'nice' and I would think a security hole.
>>>>>>
>>>>>
>>>>> I would assume you mean 'latency_nice' here.
>>>>>
>>>>> From my testing, I was not able to set values for any root owned task's
>>>>> latency_nice value by the non-root user. Also, my patch-set just piggybacks
>>>>> on the already existing sched_setattr syscall and hence it should not allow
>>>>> non-root user to do any modifications. Can you confirm this by changing
>>>>> nice (renice) value of a root task from non-root user.
>>>>>
>>>>> I have done the sanity check in the code and thinking where it could
>>>>> possibly have gone wrong. So, can you please specify what values were you
>>>>> able to set outside the [-20, 19] range?
>>>>
>>>> The checks prevent being outside that range. But negative numbers -20 to
>>>> -1 did not need root. Let me dig some more. I verified this explicitly
>>>> before sending the email so something is up.
>>>
>>> I went digging. This is absolutely repeatable. I checked that I do not
>>> unknowingly have CAP_SYS_NICE as a user. So first, are we tying
>>> latency_nice to CAP_SYS_NICE? Seems like a reasonable thing, but not sure I
>>> saw this stated anywhere. Second, the only capability checked in
>>> __sched_setscheduler() in the patch I have is CAP_SYS_NICE and those checks
>>> will not return a -EPERM for a negative latency_tolerance (in the code, aka
>>> latency_nice). Do I have the correct version of the code? Am I missing
>>> something?
>>
>> You are right. I have not added permission checks for setting the
>> latency_nice value. For the task_nice, non-root user has no permission to
>> set the value lower than the current value which is not the case with the
>> latency_nice.
>>
>> In order to align with the permission checks like task_nice, I will add the
>> check similar to task_nice and send out the v4 of the series soon.
>>
>>
>> Thanks for pointing out.
>> - Parth
>>
>
> The below diff works out well enough in-order to align permission checks
> with NICE.
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2bfcff5623f9..ef4a397c9170 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4878,6 +4878,10 @@ static int __sched_setscheduler(struct task_struct *p,
> return -EINVAL;
> if (attr->sched_latency_nice < MIN_LATENCY_NICE)
> return -EINVAL;
> + /* Use the same security checks as NICE */
> + if (attr->sched_latency_nice < p->latency_nice &&
> + !can_nice(p, attr->sched_latency_nice))
> + return -EPERM;
> }
>
> if (pi)
>
> With the above in effect,
> A non-root user can only increase the value upto +19, and once increased
> cannot be decreased. e.g., a user once sets the value latency_nice = 19,
> the same user cannot set the value latency_nice = 18. This is the same
> effect as with NICE.
>
> Is such permission checks required?
>
> Unlike NICE, we are going to use latency_nice for scheduler hints only, and
> so won't it make more sense to allow a user to increase/decrease the values
> of their owned tasks?
Whether called a hint or not, it is a trade-off to reduce latency of select tasks at the expense of the throughput of
the other tasks in the the system. If any of the other tasks belong to other users, you would presumably require permission.
-chrish
^ permalink raw reply
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-3-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Force PSR probe only after full initialization (rev5)
From: Patchwork @ 2020-02-20 14:30 UTC (permalink / raw)
To: Ross Zwisler; +Cc: intel-gfx
In-Reply-To: <20200218203916.58636-1-jose.souza@intel.com>
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
New tests
---------
New tests have been introduced between CI_DRM_7963_full and Patchwork_16607_full:
### New IGT tests (58) ###
* igt@i915_pm_backlight@bad-brightness:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 0.03] s
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.24] s
* igt@i915_pm_backlight@fade:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 2.59] s
* igt@i915_pm_backlight@fade_with_dpms:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.92] s
* igt@i915_pm_backlight@fade_with_suspend:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.54] s
* igt@i915_pm_lpsp@edp-native:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@edp-panel-fitter:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_lpsp@non-edp:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.12] s
* igt@i915_pm_lpsp@screens-disabled:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rc6_residency@rc6-accuracy:
- Statuses : 8 pass(s)
- Exec time: [3.0, 3.00] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 7 pass(s)
- Exec time: [0.25, 5.02] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [1.30, 11.45] s
* igt@i915_pm_rpm@cursor:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.78] s
* igt@i915_pm_rpm@cursor-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.22] s
* igt@i915_pm_rpm@debugfs-forcewake-user:
- Statuses : 7 pass(s)
- Exec time: [10.44, 14.38] s
* igt@i915_pm_rpm@debugfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 80.93] s
* igt@i915_pm_rpm@dpms-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.82] s
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 13.27] s
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.14] s
* igt@i915_pm_rpm@dpms-non-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.16] s
* igt@i915_pm_rpm@drm-resources-equal:
- Statuses : 7 pass(s)
- Exec time: [0.79, 9.69] s
* igt@i915_pm_rpm@fences:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.91] s
* igt@i915_pm_rpm@fences-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 12.80] s
* igt@i915_pm_rpm@gem-evict-pwrite:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.97] s
* igt@i915_pm_rpm@gem-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 15.56] s
* igt@i915_pm_rpm@gem-execbuf-stress:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.66] s
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s
* igt@i915_pm_rpm@gem-idle:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.26] s
* igt@i915_pm_rpm@gem-pread:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 6.15] s
* igt@i915_pm_rpm@i2c:
- Statuses : 7 pass(s)
- Exec time: [0.94, 11.24] s
* igt@i915_pm_rpm@legacy-planes:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.38] s
* igt@i915_pm_rpm@legacy-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 146.54] s
* igt@i915_pm_rpm@modeset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.76] s
* igt@i915_pm_rpm@modeset-lpsp-stress:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 53.13] s
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 16.77] s
* igt@i915_pm_rpm@modeset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.00] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 9.55] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 6.65] s
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 72.05] s
* igt@i915_pm_rpm@pc8-residency:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@pm-caching:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 19.56] s
* igt@i915_pm_rpm@pm-tiling:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.86] s
* igt@i915_pm_rpm@reg-read-ioctl:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 8.09] s
* igt@i915_pm_rpm@sysfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.94] s
* igt@i915_pm_rpm@system-suspend:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.06] s
* igt@i915_pm_rpm@system-suspend-devices:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.53] s
* igt@i915_pm_rpm@system-suspend-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 86.05] s
* igt@i915_pm_rpm@system-suspend-modeset:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.73] s
* igt@i915_pm_rpm@universal-planes:
- Statuses : 7 pass(s)
- Exec time: [2.86, 226.26] s
* igt@i915_pm_rpm@universal-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 195.60] s
* igt@i915_pm_rps@basic-api:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.03] s
* igt@i915_pm_rps@min-max-config-idle:
- Statuses : 8 pass(s)
- Exec time: [0.11, 0.63] s
* igt@i915_pm_rps@min-max-config-loaded:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [0.32, 3.02] s
* igt@i915_pm_rps@reset:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [3.52, 3.66] s
* igt@i915_pm_rps@waitboost:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [2.52, 2.63] s
* igt@i915_pm_sseu@full-enable:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in Patchwork_16607_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +8 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb7/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_exec_schedule@pi-userfault-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_schedule@pi-userfault-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@gem_exec_schedule@pi-userfault-bsd.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +4 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@preempt-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@preempt-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#644])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_ppgtt@flink-and-close-vma-leak.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gen7_exec_parse@basic-offset:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@gen7_exec_parse@basic-offset.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw5/igt@gen7_exec_parse@basic-offset.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl7/igt@i915_suspend@sysfs-reader.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#72])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-glk3/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#488])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb7/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@plain-flip-ts-check:
- shard-skl: [PASS][23] -> [FAIL][24] ([i915#34])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@kms_flip@plain-flip-ts-check.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl5/igt@kms_flip@plain-flip-ts-check.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-tglb: [PASS][25] -> [SKIP][26] ([i915#668]) +3 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][27] -> [FAIL][28] ([i915#49])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl9/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#108145])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109441]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@perf@oa-exponents:
- shard-glk: [PASS][33] -> [FAIL][34] ([i915#84])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk6/igt@perf@oa-exponents.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-glk5/igt@perf@oa-exponents.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][35] -> [SKIP][36] ([fdo#109276]) +16 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@prime_busy@hang-bsd2.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb8/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-iclb: [FAIL][37] ([i915#1241]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][39] ([fdo#110854]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_balancer@smoke.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb4/igt@gem_exec_balancer@smoke.html
* {igt@gem_exec_schedule@implicit-read-write-bsd}:
- shard-iclb: [SKIP][41] ([i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@gem_exec_schedule@implicit-read-write-bsd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb3/igt@gem_exec_schedule@implicit-read-write-bsd.html
* {igt@gem_exec_schedule@implicit-write-read-bsd1}:
- shard-iclb: [SKIP][43] ([fdo#109276] / [i915#677]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@implicit-write-read-bsd1.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@implicit-write-read-bsd1.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][45] ([fdo#112146]) -> [PASS][46] +5 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb8/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [SKIP][47] ([fdo#109276]) -> [PASS][48] +17 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@promotion-bsd1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb1/igt@gem_exec_schedule@promotion-bsd1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-apl: [FAIL][49] ([i915#644]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl6/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][51] ([fdo#109271]) -> [PASS][52] +1 similar issue
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-snb1/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][53] ([i915#96]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw2/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][55] ([i915#180]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][57] ([i915#61]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw1/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][59] ([i915#668]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-tglb7/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][61] ([i915#180]) -> [PASS][62] +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-apl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][63] ([fdo#108145]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][65] ([fdo#109642] / [fdo#111068]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@kms_psr2_su@page_flip.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [SKIP][67] ([fdo#109441]) -> [PASS][68] +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][69] ([i915#69]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-skl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-kbl: [INCOMPLETE][71] ([fdo#103665]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][73] ([fdo#112271] / [i915#51]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-kbl1/igt@perf@short-reads.html
* igt@perf_pmu@busy-vcs1:
- shard-iclb: [SKIP][75] ([fdo#112080]) -> [PASS][76] +12 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@perf_pmu@busy-vcs1.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@perf_pmu@busy-vcs1.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][77] ([fdo#112080]) -> [FAIL][78] ([IGT#28]) +1 similar issue
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][79] ([i915#818]) -> [FAIL][80] ([i915#694])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/shard-hsw7/igt@gem_tiled_blits@interruptible.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
[i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
[i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#84]: https://gitlab.freedesktop.org/drm/intel/issues/84
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16607
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16607: dbe2fc981e60de0fe193361613c6c8bebb1b78e2 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16607/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 02/10] ASoC: tegra: add support for CIF programming
From: Jon Hunter @ 2020-02-20 14:30 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-3-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> Audio Client Interface (CIF) is a proprietary interface employed to route
> audio samples through Audio Hub (AHUB) components by inter connecting the
> various modules.
>
> This patch exports an inline function tegra_set_cif() which can be used,
> for now, to program CIF on Tegra210 and later Tegra generations. Later it
> can be extended to include helpers for legacy chips as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/tegra_cif.h | 63 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 sound/soc/tegra/tegra_cif.h
>
> diff --git a/sound/soc/tegra/tegra_cif.h b/sound/soc/tegra/tegra_cif.h
> new file mode 100644
> index 0000000..ecc0850
> --- /dev/null
> +++ b/sound/soc/tegra/tegra_cif.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * tegra_cif.h - TEGRA Audio CIF Programming
> + *
> + * Copyright (c) 2020 NVIDIA CORPORATION. All rights reserved.
> + *
> + */
> +
> +#ifndef __TEGRA_CIF_H__
> +#define __TEGRA_CIF_H__
> +
> +#define TEGRA_ACIF_CTRL_FIFO_TH_SHIFT 24
> +#define TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT 20
> +#define TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT 16
> +#define TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT 12
> +#define TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT 8
> +#define TEGRA_ACIF_CTRL_EXPAND_SHIFT 6
> +#define TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT 4
> +#define TEGRA_ACIF_CTRL_REPLICATE_SHIFT 3
> +#define TEGRA_ACIF_CTRL_TRUNCATE_SHIFT 1
> +#define TEGRA_ACIF_CTRL_MONO_CONV_SHIFT 0
> +
> +/* AUDIO/CLIENT_BITS values */
> +#define TEGRA_ACIF_BITS_8 1
> +#define TEGRA_ACIF_BITS_16 3
> +#define TEGRA_ACIF_BITS_24 5
> +#define TEGRA_ACIF_BITS_32 7
> +
> +#define TEGRA_ACIF_UPDATE_MASK 0x3ffffffb
> +
> +struct tegra_cif_conf {
> + unsigned int threshold;
> + unsigned int audio_ch;
> + unsigned int client_ch;
> + unsigned int audio_bits;
> + unsigned int client_bits;
> + unsigned int expand;
> + unsigned int stereo_conv;
> + unsigned int replicate;
> + unsigned int truncate;
> + unsigned int mono_conv;
> +};
> +
> +static inline void tegra_set_cif(struct regmap *regmap, unsigned int reg,
> + struct tegra_cif_conf *conf)
> +{
> + unsigned int value;
> +
> + value = (conf->threshold << TEGRA_ACIF_CTRL_FIFO_TH_SHIFT) |
> + ((conf->audio_ch - 1) << TEGRA_ACIF_CTRL_AUDIO_CH_SHIFT) |
> + ((conf->client_ch - 1) << TEGRA_ACIF_CTRL_CLIENT_CH_SHIFT) |
> + (conf->audio_bits << TEGRA_ACIF_CTRL_AUDIO_BITS_SHIFT) |
> + (conf->client_bits << TEGRA_ACIF_CTRL_CLIENT_BITS_SHIFT) |
> + (conf->expand << TEGRA_ACIF_CTRL_EXPAND_SHIFT) |
> + (conf->stereo_conv << TEGRA_ACIF_CTRL_STEREO_CONV_SHIFT) |
> + (conf->replicate << TEGRA_ACIF_CTRL_REPLICATE_SHIFT) |
> + (conf->truncate << TEGRA_ACIF_CTRL_TRUNCATE_SHIFT) |
> + (conf->mono_conv << TEGRA_ACIF_CTRL_MONO_CONV_SHIFT);
> +
> + regmap_update_bits(regmap, reg, TEGRA_ACIF_UPDATE_MASK, value);
> +}
> +
> +#endif
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers!
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] btrfs: clear file extent mapping for punch past i_size
From: Josef Bacik @ 2020-02-20 14:29 UTC (permalink / raw)
To: linux-btrfs, kernel-team
In my stress testing we were still seeing some hole's with my patches to
fix missing hole extents. Turns out we do not fill in holes during hole
punch if the punch is past i_size. I incorrectly assumed this was fine,
because anybody extending would use btrfs_cont_expand, however there is
a corner that still can give us trouble. Start with an empty file and
fallocate KEEP_SIZE 1m-2m
We now have a 0 length file, and a hole file extent from 0-1m, and a
prealloc extent from 1m-2m. Now
punch 1m-1.5m
Because this is past i_size we have
[HOLE EXTENT][ NOTHING ][PREALLOC]
[0 1m][1m 1.5m][1.5m 2m]
with an i_size of 0. Now if we pwrite 0-1.5m we'll increas our i_size
to 1.5m, but our disk_i_size is still 0 until the ordered extent
completes.
However if we now immediately truncate 2m on the file we'll just call
btrfs_cont_expand(inode, 1.5m, 2m), since our old i_size is 1.5m. If we
commit the transaction here and crash we'll expose the gap.
To fix this we need to clear the file extent mapping for the range that
we punched but didn't insert a corresponding file extent for. This will
mean the truncate will only get an disk_i_size set to 1m if we crash
before the finish ordered io happens.
I've written an xfstest to reproduce the problem and validate this fix.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
- Dave, this needs to be folded into "btrfs: use the file extent tree
infrastructure" and the changelog needs to be adjusted since I incorrectly
point out that we don't need to clear for hole punch. We definitely need to
clear for the case that we're punching past i_size as we aren't inserting hole
file extents.
fs/btrfs/file.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 5cdcdbdd908b..6f6f1805e6fd 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -2597,6 +2597,24 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
btrfs_abort_transaction(trans, ret);
break;
}
+ } else if (!clone_info && cur_offset < drop_end) {
+ /*
+ * We are past the i_size here, but since we didn't
+ * insert holes we need to clear the mapped area so we
+ * know to not set disk_i_size in this area until a new
+ * file extent is inserted here.
+ */
+ ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
+ cur_offset, drop_end - cur_offset);
+ if (ret) {
+ /*
+ * We couldn't clear our area, so we could
+ * presumably adjust up and corrupt the fs, so
+ * we need to abort.
+ */
+ btrfs_abort_transaction(trans, ret);
+ break;
+ }
}
if (clone_info && drop_end > clone_info->file_offset) {
@@ -2687,6 +2705,15 @@ int btrfs_punch_hole_range(struct inode *inode, struct btrfs_path *path,
btrfs_abort_transaction(trans, ret);
goto out_trans;
}
+ } else if (!clone_info && cur_offset < drop_end) {
+ /* See the comment in the loop above for the reasoning here. */
+ ret = btrfs_inode_clear_file_extent_range(BTRFS_I(inode),
+ cur_offset, drop_end - cur_offset);
+ if (ret) {
+ btrfs_abort_transaction(trans, ret);
+ goto out_trans;
+ }
+
}
if (clone_info) {
ret = btrfs_insert_clone_extent(trans, inode, path, clone_info,
--
2.24.1
^ permalink raw reply related
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Eric Blake @ 2020-02-20 14:28 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <0b884ddcd0ac3a3c0b8cdd9d09c74566ac107c9a.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> Subcluster allocation in qcow2 is implemented by extending the
> existing L2 table entries and adding additional information to
> indicate the allocation status of each subcluster.
>
> This patch documents the changes to the qcow2 format and how they
> affect the calculation of the L2 cache size.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> docs/interop/qcow2.txt | 68 ++++++++++++++++++++++++++++++++++++++++--
> docs/qcow2-cache.txt | 19 +++++++++++-
> 2 files changed, 83 insertions(+), 4 deletions(-)
This adds a new feature bit; where is the corresponding patch to qcow2.c
to advertise the feature bit name in the optional feature name table?
/me reads ahead
good, patch 25 covers it. Quick comment added there as a result.
> +== Extended L2 Entries ==
> +
> +An image uses Extended L2 Entries if bit 3 is set on the incompatible_features
> +field of the header.
> +
> +In these images standard data clusters are divided into 32 subclusters of the
> +same size. They are contiguous and start from the beginning of the cluster.
> +Subclusters can be allocated independently and the L2 entry contains information
> +indicating the status of each one of them. Compressed data clusters don't have
> +subclusters so they are treated like in images without this feature.
Grammar; I'd suggest:
...don't have subclusters, so they are treated the same as in images
without this feature.
Are they truly the same, or do you still need to document that the extra
64 bits of the extended L2 entry are all zero?
> +
> +The size of an extended L2 entry is 128 bits so the number of entries per table
> +is calculated using this formula:
> +
> + l2_entries = (cluster_size / (2 * sizeof(uint64_t)))
> +
> +The first 64 bits have the same format as the standard L2 table entry described
> +in the previous section, with the exception of bit 0 of the standard cluster
> +descriptor.
> +
> +The last 64 bits contain a subcluster allocation bitmap with this format:
> +
> +Subcluster Allocation Bitmap (for standard clusters):
> +
> + Bit 0 - 31: Allocation status (one bit per subcluster)
> +
> + 1: the subcluster is allocated. In this case the
> + host cluster offset field must contain a valid
> + offset.
> + 0: the subcluster is not allocated. In this case
> + read requests shall go to the backing file or
> + return zeros if there is no backing file data.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 31 - x)
> +
Missing trailing '.'
> + 32 - 63 Subcluster reads as zeros (one bit per subcluster)
> +
> + 1: the subcluster reads as zeros. In this case the
> + allocation status bit must be unset. The host
> + cluster offset field may or may not be set.
Why must the allocation bit be unset? When we preallocate, we want a
cluster to reserve space, but still read as zero, so the combination of
both bits set makes sense to me.
> + 0: no effect.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 63 - x)
and again.
> +
> +Subcluster Allocation Bitmap (for compressed clusters):
> +
> + Bit 0 - 63: Reserved (set to 0)
> + Compressed clusters don't have subclusters,
> + so this field is not used.
>
> == Snapshots ==
>
> diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt
> index d57f409861..04eb4ce2f1 100644
> --- a/docs/qcow2-cache.txt
> +++ b/docs/qcow2-cache.txt
> @@ -1,6 +1,6 @@
> qcow2 L2/refcount cache configuration
> =====================================
> -Copyright (C) 2015, 2018 Igalia, S.L.
> +Copyright (C) 2015, 2018-2019 Igalia, S.L.
Our review is late; you could add 2020 if desired, now.
> Author: Alberto Garcia <berto@igalia.com>
>
> This work is licensed under the terms of the GNU GPL, version 2 or
> @@ -222,3 +222,20 @@ support this functionality, and is 0 (disabled) on other platforms.
> This functionality currently relies on the MADV_DONTNEED argument for
> madvise() to actually free the memory. This is a Linux-specific feature,
> so cache-clean-interval is not supported on other systems.
> +
> +
> +Extended L2 Entries
> +-------------------
> +All numbers shown in this document are valid for qcow2 images with normal
> +64-bit L2 entries.
> +
> +Images with extended L2 entries need twice as much L2 metadata, so the L2
> +cache size must be twice as large for the same disk space.
> +
> + disk_size = l2_cache_size * cluster_size / 16
> +
> +i.e.
> +
> + l2_cache_size = disk_size * 16 / cluster_size
> +
> +Refcount blocks are not affected by this.
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* [PATCH 2/2] ARM: dts: exynos: Make fixed regulators always-on on Arndale5250
From: Marek Szyprowski @ 2020-02-20 14:28 UTC (permalink / raw)
To: linux-samsung-soc
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20200220142806.19340-1-m.szyprowski@samsung.com>
The fixed regulators defined for Arndale5250 boards have no control lines,
so mark them as 'always-on' to better describe the hardware and also kill
the strange messages like 'MAIN_DC: disabling' after boot.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index bff24c61212b..6904091d4837 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -93,6 +93,7 @@
compatible = "regulator-fixed";
reg = <0>;
regulator-name = "MAIN_DC";
+ regulator-always-on;
};
mmc_reg: regulator@1 {
@@ -101,12 +102,14 @@
regulator-name = "VDD_MMC";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
+ regulator-always-on;
};
reg_hdmi_en: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "hdmi-en";
+ regulator-always-on;
};
vcc_1v2_reg: regulator@3 {
@@ -115,6 +118,7 @@
regulator-name = "VCC_1V2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
+ regulator-always-on;
};
vcc_1v8_reg: regulator@4 {
@@ -123,6 +127,7 @@
regulator-name = "VCC_1V8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ regulator-always-on;
};
vcc_3v3_reg: regulator@5 {
@@ -131,6 +136,7 @@
regulator-name = "VCC_3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-always-on;
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: exynos: Fix MMC regulator on Arndale5250 board
From: Marek Szyprowski @ 2020-02-20 14:28 UTC (permalink / raw)
To: linux-samsung-soc
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <CGME20200220142814eucas1p2a230d064c9cebcc029ce12b228fd31ac@eucas1p2.samsung.com>
According to the schematic, both eMMC and SDMMC use dedicated fixed
regulators connected directly to the DC5V and MAIN_DC rails. Remove the
GPX1-1 line assigned to the MMC regulator, because such control
connection doesn't exist. Also change its name to VDD_MMC to avoid
conflict with LDO18 output of S5M8767 PMIC.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index f8ebc620f42d..bff24c61212b 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -98,11 +98,9 @@
mmc_reg: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
- regulator-name = "VDD_33ON_2.8V";
+ regulator-name = "VDD_MMC";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
- gpio = <&gpx1 1 GPIO_ACTIVE_HIGH>;
- enable-active-high;
};
reg_hdmi_en: regulator@2 {
--
2.17.1
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 14:27 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo50pCb4OafEs9tLm7YEPqHc+BtDAvagRnwjXtZeQDNwUwg@mail.gmail.com>
On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct drm_display_mode):
> > 200 -> 136 bytes (-32%)
> >
> > 64bit bloat-o-meter -c drm.ko:
> > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > Function old new delta
> > ...
> > Total: Before=189430, After=188779, chg -0.34%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=11667, After=11667, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 1000 680 -320
> > edid_est_modes 3400 2312 -1088
> > edid_cea_modes_193 5400 3672 -1728
> > drm_dmt_modes 17600 11968 -5632
> > edid_cea_modes_1 25400 17272 -8128
> > Total: Before=71239, After=54343, chg -23.72%
> >
> >
> > 64bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > ...
> > Total: Before=272336, After=254789, chg -6.44%
> >
> >
> > 32bit sizeof(struct drm_display_mode):
> > 184 -> 120 bytes (-34%)
> >
> > 32bit bloat-o-meter -c drm.ko
> > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > Function old new delta
> > ...
> > Total: Before=172359, After=171734, chg -0.36%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=4227, After=4227, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 920 600 -320
> > edid_est_modes 3128 2040 -1088
> > edid_cea_modes_193 4968 3240 -1728
> > drm_dmt_modes 16192 10560 -5632
> > edid_cea_modes_1 23368 15240 -8128
> > Total: Before=59230, After=42334, chg -28.53%
> >
> > 32bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > ...
> > Total: Before=235816, After=218295, chg -7.43%
> >
> >
> > Some ideas for further reduction:
> > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > struct but would often require a heap alloc for the name (though
> > typical mode name is <10 bytes so still overall win perhaps)
> > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > place where we have to preserve the user provided name, elsewhere
> > could pehaps just generate on demand? Not sure how tricky this
> > would get.
>
> The series does some great work, with future work reaching the cache
> line for 64bit.
> Doing much more than that might be an overkill IMHO.
>
> In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> avoiding the heap alloc/calc on demand fun.
> While also ensuring the name is sufficiently large for the next decade or so.
Unfortunately it's part of the uabi. So can't change it without some
risk of userspace breakage.
The least demanding option is probably to nuke export_head. We need
one bit to replace it, which we can get by either:
- stealing from eg. mode->type, or perhaps mode->private_flags
- nuke private_flags outright and replace it with a bool for this
purpose
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 14:27 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo50pCb4OafEs9tLm7YEPqHc+BtDAvagRnwjXtZeQDNwUwg@mail.gmail.com>
On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct drm_display_mode):
> > 200 -> 136 bytes (-32%)
> >
> > 64bit bloat-o-meter -c drm.ko:
> > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > Function old new delta
> > ...
> > Total: Before=189430, After=188779, chg -0.34%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=11667, After=11667, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 1000 680 -320
> > edid_est_modes 3400 2312 -1088
> > edid_cea_modes_193 5400 3672 -1728
> > drm_dmt_modes 17600 11968 -5632
> > edid_cea_modes_1 25400 17272 -8128
> > Total: Before=71239, After=54343, chg -23.72%
> >
> >
> > 64bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > ...
> > Total: Before=272336, After=254789, chg -6.44%
> >
> >
> > 32bit sizeof(struct drm_display_mode):
> > 184 -> 120 bytes (-34%)
> >
> > 32bit bloat-o-meter -c drm.ko
> > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > Function old new delta
> > ...
> > Total: Before=172359, After=171734, chg -0.36%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=4227, After=4227, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 920 600 -320
> > edid_est_modes 3128 2040 -1088
> > edid_cea_modes_193 4968 3240 -1728
> > drm_dmt_modes 16192 10560 -5632
> > edid_cea_modes_1 23368 15240 -8128
> > Total: Before=59230, After=42334, chg -28.53%
> >
> > 32bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > ...
> > Total: Before=235816, After=218295, chg -7.43%
> >
> >
> > Some ideas for further reduction:
> > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > struct but would often require a heap alloc for the name (though
> > typical mode name is <10 bytes so still overall win perhaps)
> > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > place where we have to preserve the user provided name, elsewhere
> > could pehaps just generate on demand? Not sure how tricky this
> > would get.
>
> The series does some great work, with future work reaching the cache
> line for 64bit.
> Doing much more than that might be an overkill IMHO.
>
> In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> avoiding the heap alloc/calc on demand fun.
> While also ensuring the name is sufficiently large for the next decade or so.
Unfortunately it's part of the uabi. So can't change it without some
risk of userspace breakage.
The least demanding option is probably to nuke export_head. We need
one bit to replace it, which we can get by either:
- stealing from eg. mode->type, or perhaps mode->private_flags
- nuke private_flags outright and replace it with a bool for this
purpose
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Xen-devel] [linux-5.4 test] 147286: regressions - FAIL
From: osstest service owner @ 2020-02-20 14:27 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147286 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 20 leak-check/check fail pass in 147210
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 146121
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 146121
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 27dfbcc2f53d5b14ef78156d15ff92619807d46c
baseline version:
linux 122179cb7d648a6f36b20dd6bf34f953cb384c30
Last test of basis 146121 2020-01-15 17:42:04 Z 35 days
Failing since 146178 2020-01-17 02:59:07 Z 34 days 63 attempts
Testing same since 147129 2020-02-16 10:37:40 Z 4 days 3 attempts
------------------------------------------------------------
1051 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 55132 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: Greg KH @ 2020-02-20 14:27 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220081420.GA3328448@kroah.com>
On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> >
> > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > leaks data across cores sharing the HW-RNG for vulnerable processors.
> >
> > This leak is fixed by a microcode update and is enabled by default.
> >
> > This new microcode serializes processor access during execution of RDRAND
> > or RDSEED. It ensures that the shared buffer is overwritten before it
> > is released for reuse.
> >
> > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > and latency of RT processing running on the socket while executing RDRAND or
> > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
>
> Then we need to stop using RDRAND internally for our "give me a random
> number api" which has spread to more and more parts of the kernel.
>
> Here's a patch that does so:
> https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> which I'm going to advise get merged now and backported to the stable
> branches.
Note, the author of that patch has reached out to me to say they found
this same issue. He did so independantly so odds are others already
know about this. He found it because he was wondering why rdrand was so
slow on newer systems, and then traced things backwards like all the
other researchers in this area.
So, what's the timeline here? Looks like this is already "in the wild"
from what I can tell.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 13/21] btrfs: move vairalbes for clustered allocation into find_free_extent_ctl
From: Christoph Hellwig @ 2020-02-20 14:27 UTC (permalink / raw)
To: Naohiro Aota
Cc: linux-btrfs, David Sterba, Chris Mason, Josef Bacik,
Nikolay Borisov, Damien Le Moal, Johannes Thumshirn,
Hannes Reinecke, Anand Jain, linux-fsdevel
In-Reply-To: <20200212072048.629856-14-naohiro.aota@wdc.com>
s/vairalbes/variables/ in the Subject.
^ permalink raw reply
* [Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.
From: Laurent Vivier @ 2020-02-20 14:13 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <157762661516.5433.16221584605990009162.malonedeb@gac.canonical.com>
I need the strace result of _configure_loopback_interface in a qemu-
aarch64 chroot.
But as strace cannot be started in the chroot you must strace the
"chroot" command and its children.
So something like "sudo strace -yyy chroot <your chroot directory> <your
test path>"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
Title:
qemu user static binary seems to lack support for network namespace.
Status in QEMU:
New
Bug description:
Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I
see the following error message.
Unable to configure loopback interface: Operation not supported
If I disable emerge's network-sandbox which utilizes network
namespace, the error disappears.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1857811/+subscriptions
^ permalink raw reply
* Re: [PATCH v3 09/25] fs: add is_userns_visible() helper
From: Serge E. Hallyn @ 2020-02-20 14:26 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Christian Brauner, Serge E. Hallyn, Stéphane Graber,
Eric W. Biederman, Aleksa Sarai, Jann Horn, smbarber,
Seth Forshee, Alexander Viro, Alexey Dobriyan, James Morris,
Kees Cook, Jonathan Corbet, Phil Estes, LKML, Linux FS Devel,
Linux Containers, LSM List, Linux API
In-Reply-To: <CALCETrW-XPkBMs30vk+Aiv+jA5i7TjHOYCgz0Ud6d0geaYte=g@mail.gmail.com>
On Wed, Feb 19, 2020 at 09:18:51AM -0800, Andy Lutomirski wrote:
> On Wed, Feb 19, 2020 at 4:06 AM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> > On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote:
> > > On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
> > > > Introduce a helper which makes it possible to detect fileystems whose
> > > > superblock is visible in multiple user namespace. This currently only
> > > > means proc and sys. Such filesystems usually have special semantics so their
> > > > behavior will not be changed with the introduction of fsid mappings.
> > >
> > > Hi,
> > >
> > > I'm afraid I've got a bit of a hangup about the terminology here. I
> > > *think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
> > > always translated per the id mappings, not fsid mappings. But when I see
> >
> > Correct!
> >
> > > the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
> > > be seen by other namespaces at all.
> > >
> > > Am I right in my first interpretation? If so, can we talk about the
> > > naming?
> >
> > Yep, your first interpretation is right. What about: wants_idmaps()
>
> Maybe fsidmap_exempt()?
Yeah, and maybe SB_USERNS_FSID_EXEMPT ?
> I still haven't convinced myself that any of the above is actually
> correct behavior, especially when people do things like creating
> setuid binaries.
The only place that would be a problem is if the child userns has an
fsidmapping from X to 0 in the parent userns, right? Yeah I'm sure
many people would ignore all advice to the contrary and do this anyway,
but I would try hard to suggest that people use an intermediary userns
for storing filesystems for the "docker share" case. So the host fsid
range would start at say 200000. So a setuid binary would just be
setuid-200000.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.