Hi Sir/Madam,

Glad to hear that you are on the market for valves, we specialize in this field for 13 years with the strength of BUTTERFLY VALVES with good quality and pretty competitive price.

Also we have our own professional designers to meet any of your requirements.

If you are interested in,Please let me know.

 

Best Regards!

 

 

Huang Dekai

____________________________

Tianjin Worlds Valve co., ltd.

www.wdsvalve.com

www.worldsvalve.com

Tel:0086-13682070288

Linkedin:https://www.linkedin.com/in/butterflyvalves1/

https://www.linkedin.com/company/tianjin-worlds-valve-co-ltd/

Add:No.25,Fuhui Road,Jinnan District,Tianjin, China

Hi all,

CIP kernel team has released Linux kernel v4.19.113-cip23.

The linux-4.19.y-cip tree has been updated base version from v4.19.109 to v4.19.113.
You can get this release via the git tree at:

v4.19.113-cip23:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit hash:
52f7171e0b7fcf44b37d9dc270de2576bcefe169
added commits:
CIP: Bump version suffix to -cip23 after merge from stable

Best regards,
Nobuhiro

Hi Pavel,

A couple of comments below -

Pavel Machek <pavel@ucw.cz> writes:

From: Eugenio Pérez <eperezma@redhat.com>

Doing so, we save one call to get data we already have in the struct.

Also, since there is no guarantee that getname use sockaddr_ll
parameter beyond its size, we add a little bit of security here.
It should do not do beyond MAX_ADDR_LEN, but syzbot found that
ax25_getname writes more (72 bytes, the size of full_sockaddr_ax25,
versus 20 + 32 bytes of sockaddr_ll + MAX_ADDR_LEN in syzbot repro).

Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Reported-by: syzbot+f2a62d07a5198c819c7b@syzkaller.appspotmail.com
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upstream: 42d84c8490f9f0931786f1623191fcab397c3d64

Please follow the style guidelines documented in
Documentation/process/stable-kernel-rules.rst. In this instance, please
mention the upstream commit id following -

The upstream commit ID must be specified with a separate line above the
commit
text, like this:

commit <sha1> upstream.

For an example, take a look at Commit ad598a48fe61 ("vhost: Check docket
sk_family instead of call getname"). It's a backport of the same
upstream patch to 4.19 stable kernel.

Signed-off-by: Pavel Machek <pavel@denx.de>
---
drivers/vhost/net.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

---

Since it is a security problem, I backported the patch to 4.4. I
compile tested it on cip test farm, but it was only built for single
target, probably due to too big config.

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 1459dc9fd701..5efac33c29dc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -815,11 +815,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)

static struct socket *get_raw_socket(int fd)
{
- struct {
- struct sockaddr_ll sa;
- char buf[MAX_ADDR_LEN];
- } uaddr;
- int uaddr_len = sizeof uaddr, r;
+ int r;
struct socket *sock = sockfd_lookup(fd, &r);

if (!sock)
@@ -831,12 +827,7 @@ static struct socket *get_raw_socket(int fd)
goto err;
}

- r = sock->ops->getname(sock, (struct sockaddr *)&uaddr.sa,
- &uaddr_len, 0);
- if (r)
- goto err;
-
- if (uaddr.sa.sll_family != AF_PACKET) {
+ if (sock->sk->sk_family != AF_PACKET) {
r = -EPFNOSUPPORT;
goto err;
}
--
2.20.1

This patch fails to apply with the following error -

% git am vhost.mbox
Applying: vhost: Check docket sk_family instead of call getname
error: corrupt patch at line 16
Patch failed at 0001 vhost: Check docket sk_family instead of call
getname
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

There is some encoding issue in your mail client. The same workflow
works for other kernel patches.

Thanks,
Punit

Hi!

I tried to prepare next 4.4-rt release. I have code ready, but while
running tests I realized that only two targets are used to run them.

We 4.19-rt has known bugs breaking boot on de0-nano (and probably
other) boards, and according to code inspection, same bug is present
in 4.4-rt. Fix is not complex, but I'm not comfortable applying it
without _any_ testing.

If I'm right, 4.4-rt should be broken on socfpga boards (arm32) in
non-realtime configuration; it should panic on boot in cca 50% of
cases. Patch below should fix it.

And I pushed code _without_ the patch to kernel.org,

To gitolite.kernel.org:pub/scm/linux/kernel/git/cip/linux-cip.git
924af895a033..fbc533f445d2 linux-4.4.y-cip-rt -> linux-4.4.y-cip-rt

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

I tried to prepare next 4.4-rt release. I have code ready, but while
running tests I realized that only two targets are used to run them.

We 4.19-rt has known bugs breaking boot on de0-nano (and probably
other) boards, and according to code inspection, same bug is present
in 4.4-rt. Fix is not complex, but I'm not comfortable applying it
without _any_ testing.

If I'm right, 4.4-rt should be broken on socfpga boards (arm32) in
non-realtime configuration; it should panic on boot in cca 50% of
cases. Patch below should fix it.

Best regards,
Pavel

commit 20124aef8572b764ffd90d836253153102c763c5
Author: Pavel Machek <pavel@ucw.cz>
Date: Sat Mar 21 22:58:43 2020 +0100

With -rt tree but prempt-rt not enabled, de0-nano was getting failures
during boot, such as this:

https://lava.ciplatform.org/scheduler/job/13037

[ 6.813352] Freeing unused kernel memory: 1024K
[ 6.817927] Unable to handle kernel paging request at virtual address e7fddef0
[ 6.825121] pgd = (ptrval)
[ 6.827816] [e7fddef0] *pgd=27e1141e(bad)
[ 6.831818] Internal error: Oops: 8000000d [#1] SMP ARM
[ 6.837019] Modules linked in:
[ 6.840067] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.106-cip21-gc82fe0af5 #1
[ 6.847601] Hardware name: Altera SOCFPGA
[ 6.851596] PC is at 0xe7fddef0
[ 6.854733] LR is at irq_work_run_list+0x84/0xc0

Bisect revealed fc9f4631a290 is the problematic commit, and some code
auditing revealed that it is working with wrong list. Fix it.

Signed-off-by: Pavel Machek <pavel@denx.de>
Fixes: fc9f4631a290 ("irqwork: push most work into softirq context")

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 2899ba0d23d1..19896e6f1b2a 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -78,7 +78,8 @@ bool irq_work_queue_on(struct irq_work *work, int cpu)
if (!irq_work_claim(work))
return false;

- if (IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !(work->flags & IRQ_WORK_HARD_IRQ))
+ if ((IS_ENABLED(CONFIG_PREEMPT_RT_FULL) && !(work->flags & IRQ_WORK_HARD_IRQ))
+ || (work->flags & IRQ_WORK_LAZY))
list = &per_cpu(lazy_list, cpu);
else
list = &per_cpu(raised_list, cpu);

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

From: Eugenio Pérez <eperezma@redhat.com>

Doing so, we save one call to get data we already have in the struct.

Also, since there is no guarantee that getname use sockaddr_ll
parameter beyond its size, we add a little bit of security here.
It should do not do beyond MAX_ADDR_LEN, but syzbot found that
ax25_getname writes more (72 bytes, the size of full_sockaddr_ax25,
versus 20 + 32 bytes of sockaddr_ll + MAX_ADDR_LEN in syzbot repro).

Fixes: 3a4d5c94e9593 ("vhost_net: a kernel-level virtio server")
Reported-by: syzbot+f2a62d07a5198c819c7b@syzkaller.appspotmail.com
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upstream: 42d84c8490f9f0931786f1623191fcab397c3d64
Signed-off-by: Pavel Machek <pavel@denx.de>
---
drivers/vhost/net.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

---

Since it is a security problem, I backported the patch to 4.4. I
compile tested it on cip test farm, but it was only built for single
target, probably due to too big config.

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 1459dc9fd701..5efac33c29dc 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -815,11 +815,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)

static struct socket *get_raw_socket(int fd)
{
- struct {
- struct sockaddr_ll sa;
- char buf[MAX_ADDR_LEN];
- } uaddr;
- int uaddr_len = sizeof uaddr, r;
+ int r;
struct socket *sock = sockfd_lookup(fd, &r);

if (!sock)
@@ -831,12 +827,7 @@ static struct socket *get_raw_socket(int fd)
goto err;
}

- r = sock->ops->getname(sock, (struct sockaddr *)&uaddr.sa,
- &uaddr_len, 0);
- if (r)
- goto err;
-
- if (uaddr.sa.sll_family != AF_PACKET) {
+ if (sock->sk->sk_family != AF_PACKET) {
r = -EPFNOSUPPORT;
goto err;
}
--
2.20.1


--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=3&day=26&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

US-West US-East UK DE TW JP
02:00 05:00 09:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/03/cip.2020-03-19-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - Iwamatsu-san
2. Assign the owner of "CIP kernel config" - masashi910
3. Strengthen sustainable process to backport patches from Mainline/LTS - Kernel Team
3-1. Workflow for identifying important fixes, backporting, and reviewing them
3-2. Prepare the tools to be used for this workflow
3-3. Get practice in backporting patches
4. Upload a guideline for reference hardware platform addition - masashi910

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* CIP Security
* AOB
1. Summer Time
US summer time started on March 8. CEST starts on March 29. This IRC meeting stays to start at UTC (GMT) 09:00.

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

Hi!

vv4.19.106-cip21-rt8 should be available at kernel.org.

We are only testing kernels in non-realtime configurations, but this
proved useful in this case, and uncovered problem on de0-nano (32-bit
arm). Bisecting was quite interesting, but in the end we got close
enough to guess the guilty commit, and fix was comparatively
easy. Thanks for all the help (and that includes upstream). I still
need that or equivalent patch merged into -rt tree. Technical details
are here:

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/commit/?h=linux-4.19.y-cip-rt&id=1edcec1ee609d349e520e85e7cdfd938f6bafdda

Trees are available at

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt

https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt-rebase

And their content should be identical.

Best regards,
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

On 23.03.20 17:54, Andreas Weißel wrote:

Hi CIP kernel team,
I have a question regarding the super long-term kernel support: can
other commercial or non-commercial projects make use of such kernel
versions like "linux-4.19.y-cip", i.e., use the CIP git repositories
to address security issues (CVEs) in the Linux kernel even after the
upstream long-term versions are no longer supported, or is this
considered a service for members only?

As Pavel already pointed out: The CIP kernel naturally remains a GPL project, usage is free under the terms of this license.

The benefits of being a CIP member - besides ensuring the funding of this work - is the chance to influence which configurations and, thus, subsystems the CIP kernel will support, and on which hardware.

Best regards,
Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Hi!

In the meantime:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/478548891
https://lava.ciplatform.org/scheduler/job/13037

So yes, it seems this is not reproducible. Is it easy to make the test
run .. say 5 times?

Just repeat the test case name 5 times in the gitlab-ci file.
E.g. https://gitlab.com/cip-project/cip-kernel/linux-cip/-/commit/791b84001ce05a9a26117a0c2de0e7250b343960

Thanks for useful trick. I'll try to remember it in case it is needed
again.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hi!

I have a question regarding the super long-term kernel support: can
other commercial or non-commercial projects make use of such kernel
versions like "linux-4.19.y-cip", i.e., use the CIP git repositories
to address security issues (CVEs) in the Linux kernel even after the
upstream long-term versions are no longer supported, or is this
considered a service for members only?

Kernel is GPLed. If you get any version of kernel from anywhere, you
are basically welcome to use it any way you want. That's what GPL
says.

Check with your lawyers.

(Plus, CIP project is trying to be friendly member of community....)

Best regards,
Pavel
(Not a lawyer, not speaking for anyone but my horse.)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi CIP kernel team,

I have a question regarding the super long-term kernel support: can
other commercial or non-commercial projects make use of such kernel
versions like "linux-4.19.y-cip", i.e., use the CIP git repositories
to address security issues (CVEs) in the Linux kernel even after the
upstream long-term versions are no longer supported, or is this
considered a service for members only?

Regards
Andreas Weissel

Hi Sir/Madam,

Glad to hear that you are on the market for valves, we specialize in this field for 13 years with the strength of  FLANGED BRONZE BUTTERFLY VALVES with good quality and pretty competitive price.

 

 

Also we have our own professional designers to meet any of your requirements.

If you are interested in,Please let me know.

 

Best Regards!

 

 

Huang Dekai

____________________________

Tianjin Worlds Valve co., ltd.

www.wdsvalve.com

www.worldsvalve.com

Tel:0086-13682070288

Linkedin:https://www.linkedin.com/in/butterflyvalves1/

https://www.linkedin.com/company/tianjin-worlds-valve-co-ltd/

Add:No.25,Fuhui Road,Jinnan District,Tianjin, China

On Mon, 2020-02-17 at 23:14 +0000, nobuhiro1.iwamatsu@toshiba.co.jp wrote:

Hi Pavel,

-----Original Message-----
From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf
Of Pavel Machek
Sent: Sunday, February 16, 2020 4:54 AM
To: cip-dev@lists.cip-project.org; Chris.Paterson2@renesas.com
Subject: [cip-dev] [backport 4.4] mac80211: Fix TKIP replay protection
immediately after key setup

Hi!

So... this is first backport patch. I'll need to reformat a changelog.

The patch should pass our tests on gitlab, but I somehow don't think those
tests involved wifi at all... At least it compiles.

Can someone test it easily? Should I just submit it to stable explaining
I did not test it?

If testing is difficult, how about sending a patch to stable ML as RFC?
We may get reviews from the patch authors.

Do you have other patches that should go to 4.4/4.19?

I don't think there are other patches.

The security tracker shows a lot of fixes missing from 4.4.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

On Sat, 2020-02-15 at 20:54 +0100, Pavel Machek wrote:

Hi!

So... this is first backport patch. I'll need to reformat a changelog.

The patch should pass our tests on gitlab, but I somehow don't think
those tests involved wifi at all... At least it compiles.

Can someone test it easily? Should I just submit it to stable
explaining I did not test it?

That's what I would do.

Do you have other patches that should go to 4.4/4.19?

Best regards,
Pavel

commit 911e21ed055f6700fa80d0f7a818ba223999bb2a
Author: Pavel Machek <pavel@ucw.cz>
Date: Thu Feb 13 22:56:46 2020 +0100

Author: Jouni Malinen <j@w1.fi>
Date: Tue Jan 7 17:35:45 2020 +0200

commit fa73f24d1b119b85b32cd8f217a73d108888097e

This reference is wrong; the upstream commit is
6f601265215a421f425ba3a4850a35861d024643. Also the usual format for
this reference has "upstream." after the commit hash.

[...]

--- a/net/mac80211/tkip.c
+++ b/net/mac80211/tkip.c
@@ -265,10 +265,21 @@ int ieee80211_tkip_decrypt_data(struct crypto_cipher *tfm,
if ((keyid >> 6) != key->conf.keyidx)
return TKIP_DECRYPT_INVALID_KEYIDX;

- if (key->u.tkip.rx[queue].state != TKIP_STATE_NOT_INIT &&
- (iv32 < key->u.tkip.rx[queue].iv32 ||
- (iv32 == key->u.tkip.rx[queue].iv32 &&
- iv16 <= key->u.tkip.rx[queue].iv16)))
+ /* Reject replays if the received TSC is smaller than or equal to the
+ * last received value in a valid message, but with an exception for
+ * the case where a new key has been set and no valid frame using that
+ * key has yet received and the local RSC was initialized to 0. This
+ * exception allows the very first frame sent by the transmitter to be
+ * accepted even if that transmitter were to use TSC 0 (IEEE 802.11
+ * described TSC to be initialized to 1 whenever a new key is taken into
+ * use).
+ */
+ if (iv32 < key->u.tkip.rx[queue].iv32 ||
+ (iv32 == key->u.tkip.rx[queue].iv32 &&
+ (iv16 < key->u.tkip.rx[queue].iv16 ||
+ (iv16 == key->u.tkip.rx[queue].iv16 &&
+ (key->u.tkip.rx[queue].iv32 || key->u.tkip.rx[queue].iv16 ||
+ key->u.tkip.rx[queue].state != TKIP_STATE_NOT_INIT)))))
return TKIP_DECRYPT_REPLAY;

if (only_iv) {

This backport makes sense to me. Please can you send it to the stable
list, with the fixed commit message?

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

Hi Pavel,

From: Pavel Machek <pavel@denx.de>
Sent: 19 March 2020 21:24

Hi!

From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Chris
Paterson
Sent: 19 March 2020 11:23

Hello Pavel,

From: Pavel Machek <pavel@denx.de>
Sent: 19 March 2020 11:05

[...]

like tests are unreliable (and even my basic assumptions may be worth
re-testing).

Can you help? I'll be away from console for a few hours now.

I'll get bisecting.

Last 'good' patch is: 2089f853a8c3 ("drm/i915: disable tracing on
-RT")
The first 'bad' path is: c82fe0af5e58 ("drm/i915: skip
DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE")

Don't ask me why c82fe0af5e58 causes a boot issue on the de0-nano
board but at least it's a starting point for you.

[...]

When bisection finds a commit touching code that you're not even
building, the answer should not be "don't ask me why" but "this is not
a reproducible bug".

That's my job, I guess. I asked for bisect and got bisect
(thanks!). And yes, I have to agree:

In the meantime:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/478548891
https://lava.ciplatform.org/scheduler/job/13037

So yes, it seems this is not reproducible. Is it easy to make the test
run .. say 5 times?

Just repeat the test case name 5 times in the gitlab-ci file.
E.g. https://gitlab.com/cip-project/cip-kernel/linux-cip/-/commit/791b84001ce05a9a26117a0c2de0e7250b343960

Regards, Chris

I'm starting to suspect

pick fc9f4631a290 irqwork: push most work into softirq context

Best regards,
                                                              Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On Fri, 2020-03-13 at 22:03 +0100, Pavel Machek wrote:

Hi!

Here's backport of `subj` to 4.19. ip6_dst_lookup_flow() prototype
changed between 4.19 and mainline, files were moved around, and I
could not find some instances to update. Fun!

I also had a go at this before catching up on cip-dev and finding you
had also done so. So I've compared this with my version.

I did minimal compile testing, I'll need to run it behind gitlab ci;
but... if you are using IPv6 and can test this, it would be nice.

I haven't done real testing yet either.

Best regards,
Pavel



diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 46b855a42884..e3c948617c73 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -415,9 +415,9 @@ static int addr6_resolve(struct sockaddr_in6 *src_in,
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;

- ret = ipv6_stub->ipv6_dst_lookup(addr->net, NULL, &dst, &fl6);
- if (ret < 0)
- return ret;
+ dst = ipv6_stub->ipv6_dst_lookup_flow(addr->net, NULL, &fl6, NULL);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);

This leaves the ret variable unused, so I deleted it.

[...]

diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index ff33f498c137..035cd7dc3836 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -961,6 +961,13 @@ int ip6_dst_lookup(struct net *net, struct sock *sk, struct dst_entry **dst,
struct flowi6 *fl6);
struct dst_entry *ip6_dst_lookup_flow(const struct sock *sk, struct flowi6 *fl6,
const struct in6_addr *final_dst);
+
+static inline struct dst_entry *ip6_dst_lookup_flow_net(struct net *ign, const struct sock *sk, struct flowi6 *fl6,
+ const struct in6_addr *final_dst)
+{
+ return ip6_dst_lookup_flow(sk, fl6, final_dst);
+}
+

I think we should pick commit c4e85f73afb6 "net: ipv6: add net argument
to ip6_dst_lookup_flow" first instead of adding this adapter. It is
explicitly described as preparation for this fix.

[...]

--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -190,6 +190,14 @@ static int tipc_udp_xmit(struct net *net, struct sk_buff *skb,
.saddr = src->ipv6,
.flowi6_proto = IPPROTO_UDP
};
+ ndst = ipv6_stub->ipv6_dst_lookup_flow(net,
+ ub->ubsock->sk,
+ &fl6, NULL);
+ if (IS_ERR(ndst)) {
+ err = PTR_ERR(ndst);
+ goto tx_error;
+ }
+
err = ipv6_stub->ipv6_dst_lookup(net, ub->ubsock->sk, &ndst,
&fl6);
if (err)

You've not deleted the call to the old ipv6_dst_lookup operation here.

The mlx5_en driver *does* use the ipv6_dst_lookup operation in 4.19 so
it should be converted to ipv6_dst_lookup_flow. The relevant code is
in drivers/net/ethernet/mellanox/mlx5/core/en_tc.c.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom

Hi!

From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Chris
Paterson
Sent: 19 March 2020 11:23

Hello Pavel,

From: Pavel Machek <pavel@denx.de>
Sent: 19 March 2020 11:05

[...]

like tests are unreliable (and even my basic assumptions may be worth
re-testing).

Can you help? I'll be away from console for a few hours now.

I'll get bisecting.

Last 'good' patch is: 2089f853a8c3 ("drm/i915: disable tracing on
-RT")
The first 'bad' path is: c82fe0af5e58 ("drm/i915: skip
DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE")

Don't ask me why c82fe0af5e58 causes a boot issue on the de0-nano
board but at least it's a starting point for you.

[...]

When bisection finds a commit touching code that you're not even
building, the answer should not be "don't ask me why" but "this is not
a reproducible bug".

That's my job, I guess. I asked for bisect and got bisect
(thanks!). And yes, I have to agree:

In the meantime:

https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/478548891
https://lava.ciplatform.org/scheduler/job/13037

So yes, it seems this is not reproducible. Is it easy to make the test
run .. say 5 times?

I'm starting to suspect

pick fc9f4631a290 irqwork: push most work into softirq context

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On Tue, 2020-03-17 at 13:30 +0530, vijai kumar wrote:

On Tue, Mar 17, 2020 at 4:19 AM <nobuhiro1.iwamatsu@toshiba.co.jp> wrote:

[...]

I am now implementing LAVA's kselftest. This kselftest uses kseflftest included in the latest kernel.
There are no plans to backport tests to 4.4 or 4.19. I believe that ksefltest included in the CIP kernel
is inadequate in function and difficult to use as it is.
I suggest using a new kernel test that incorporates the latest tests.

Thank you Nobuhiro-San. Our original idea was to use the kselftest
from 4.19/4.4 cip tree. We faced some issues with
out-of-tree compilation while debianizing it. Also we faced some
compilation issues.

If that is the case, that we are going to use kselftest from the
latest kernel, how can we track the kselftest binaries for a
particular
cip kernel release? I am not sure if all the test cases would pass for
4.19/4/4. Do you have any plans to maintain a branch and release
kselftest binaries and/or testcases that have been tested with a
particular cip kernel release?

Some self-tests will fail on older kernel versions due to missing
features or bugs that might not be practically fixable. Test cases can
report "skip" rather than "fail" for missing features, but this is not
done consistently.

The way I've used kselftest with stable branches has been to look for
regressions rather than any failures. The Linaro folks are doing that
(reporting regressions only) when sending test results to the stable
list, but I don't know how or how much they have automated that.

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom