On January 10, 2019 11:22:26 AM PST, Heiner Kallweit
wrote:
>So far genphy_soft_reset was used automatically if the PHY driver
>didn't implement the soft_reset callback. This changed with the
>mentioned commit and broke KSZ9031. To fix this configure the
>KSZ9031 PHY driver to use genphy_soft_
On January 9, 2019 11:34:56 AM PST, Heiner Kallweit
wrote:
>When adding checks to detect wrong usage of the phylib API we added
>a check to phy_start_aneg() which is too strict. If the phylib
>state machine is in state PHY_HALTED we should allow reconfiguring
>and restarting aneg, and just don
On January 12, 2019 4:22:55 PM PST, Timotej Lazar
wrote:
>Since the referenced commit, Ethernet fails to come up at boot on the
>board meson-gxl-s905x-libretech-cc. Fix this by re-enabling the
>genphy_soft_reset callback for the Amlogic Meson GXL PHY driver.
>
>Fixes: 6e2d85ec0559 ("net: phy:
Since the referenced commit, Ethernet fails to come up at boot on the
board meson-gxl-s905x-libretech-cc. Fix this by re-enabling the
genphy_soft_reset callback for the Amlogic Meson GXL PHY driver.
Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
Signed-off-by: Timotej Lazar
---
x86 compilation has required asm goto support since 4.17.
Since clang does not support asm goto, at 4.17,
Commit b1ae32dbab50 ("x86/cpufeature: Guard asm_volatile_goto usage
for BPF compilation") worked around the issue by permitting an
alternative implementation without asm goto for clang.
At 5.0
I really don't know. That's why I'd be hesitant to restrict this. Maybe
limit it to something really out of the ordinary, like a year?
I am not sure that for example one hour would be out of the question for
some edge cases. Maybe someone wants to do a heartbeat for his/her
system with a very low
Hi Andre,
just wondered whether it makes sense to limit this value for sending
cyclic messages or for detecting a timeout on reception.
4.294.967.295 seconds would be ~136 years - this makes no sense to me
and I would assume someone applied some (unintended?) stuff into the
timeval.
Don't
Hi.
The 15 minute limit seems arbitrary to me. I'd be surprised if an
(R|T)X_SETUP failed because of a timeout greater than this. Are there
any problems with allowing larger timeouts? If not, I do not see a
reason to restrict this.
Regards
Andre
On 1/12/19 10:57 PM, Oliver Hartkopp wrote:
> Ky
Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup() when
the conversion into ktime multiplies the given value with NSEC_PER_USEC (1000).
Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2
Add a check for the given tv_usec, so that the value stays below one secon
On 1/12/19 10:03 PM, Kyungtae Kim wrote:
On Sat, Jan 12, 2019 at 3:02 PM Oliver Hartkopp wrote:
So there could potentially be some other users of timeval_to_ktime()
that might have the same issue.
The following would be the one related.
Yes - it is also in bcm_rx_setup(). Same issue ca
On Sat, 2019-01-12 at 12:45 -0800, Jakub Kicinski wrote:
> "IPv6: " prefix is already added by pr_fmt, no need to include
> it again in the pr_warn() format.
[]
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
[]
> @@ -4256,7 +4256,7 @@ static void ip6_print_replace_route_err(struct
> list_head
On Sat, Jan 12, 2019 at 3:02 PM Oliver Hartkopp wrote:
>
> So there could potentially be some other users of timeval_to_ktime()
> that might have the same issue.
>
The following would be the one related.
=
UBSAN: Undefined behaviour in ./include/linux/ktim
Kernel ignores the RTM_F_LOOKUP_TABLE flag for all families
but IPv4. Don't set it, otherwise it may fall foul of
strict checking policies.
Signed-off-by: Jakub Kicinski
---
ip/iproute.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index 044
net_tstamp.h is an UAPI header, so it was moved under include/uapi.
Signed-off-by: Jakub Kicinski
---
CC: Jonathan Corbet
CC: Richard Cochran
CC: Miroslav Lichvar
Hi!
I'm not 100% sure about this one. Is the path supposed to be as
installed in /usr/include/ for example, or within kernel sou
On 12.01.2019 21:28, Heiner Kallweit wrote:
> On 12.01.2019 21:08, Marc Haber wrote:
>> Hi,
>>
>> I am writing to all people who have commits in r8169.c between the v4.18
>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>> you'd prefer that to be on a mailing list, please ind
"IPv6: " prefix is already added by pr_fmt, no need to include
it again in the pr_warn() format.
Signed-off-by: Jakub Kicinski
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 49117a72fcad..06708f0070cf 100644
---
On 12.01.2019 21:08, Marc Haber wrote:
> Hi,
>
> I am writing to all people who have commits in r8169.c between the v4.18
> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
> you'd prefer that to be on a mailing list, please indicate on which list
> you want to have that, and I
Hi,
thanks for the report!
On 1/12/19 8:25 PM, Kyungtae Kim wrote:
We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in net/can/bcm.c"
kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.296b5.c
An integer overflow arose in bcm_time
We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in net/can/bcm.c"
kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.296b5.c
An integer overflow arose in bcm_timeval_to_ktime() when
tv.tv_usec * NSEC_PER_USEC is larger than its bound
On Sat, Jan 12, 2019 at 10:52 AM David Miller wrote:
>
> From: Michael Chan
> Date: Sat, 12 Jan 2019 00:13:03 -0500
>
> > Two small bug fixes for ring checking and context memory allocation
> > that affect the new 57500 chips.
>
> Series applied, thanks Michael.
>
> Should I queue these up for -s
From: Michael Chan
Date: Sat, 12 Jan 2019 00:13:03 -0500
> Two small bug fixes for ring checking and context memory allocation
> that affect the new 57500 chips.
Series applied, thanks Michael.
Should I queue these up for -stable?
Hi Lukas,
On Sat, Jan 12, 2019 at 07:01:34PM +0100, Lukas Tribus wrote:
> > Roobesh, do you use the destination address only for logging or
> > anywhere else in the request path ? And could you check if you have
> > nf_conntrack_tcp_loose set as Florian suggests ? I really think he
> > figured it
syzbot has found a reproducer for the following crash on:
HEAD commit:4b3c31c8d4dd Merge branch 'i2c/for-current' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12fecc7f40
kernel config: https://syzkaller.appspot.com/x/.config?x=b05cfd
Hello!
On Sat, 12 Jan 2019 at 18:26, Willy Tarreau wrote:
> > One case where this can happen is when nf_conntrack_tcp_loose
> > (mid-stream pickup) is enabled.
>
> Very interesting case indeed, I hadn't thought about it! I think we
> don't have enough info from the original reporter's setup but
On Fri, Jan 11, 2019 at 4:29 PM Willem de Bruijn
wrote:
>
> On Fri, Jan 11, 2019 at 9:44 AM Nicolas Dichtel
> wrote:
> >
> > Since commit cb9f1b783850, scapy (which uses an AF_PACKET socket in
> > SOCK_RAW mode) is unable to send a basic icmp packet over a sit tunnel:
> >
> > Here is a example of
Hi Florian!
Sorry for the lag, I was busy with other issues.
On Sat, Jan 12, 2019 at 05:04:00PM +0100, Florian Westphal wrote:
> Lukas Tribus wrote:
> > The application (haproxy) needs to know the original destination IP
> > address, however it does not know whether -j REDIRECT was used or not.
Lukas Tribus wrote:
> The application (haproxy) needs to know the original destination IP
> address, however it does not know whether -j REDIRECT was used or not.
> Because of this the application always queries SO_ORIGINAL_DST, and
> this includes configurations without -j REDIRECT.
>
> Are you
On 2019-01-12 7:23 a.m., Jamal Hadi Salim wrote:
Do we have a test case for a setup like this in tdc?
i.e incoming tagged and then vlan popped by action?
Otherwise a test with IFE which resets the ethertype
would be sufficient i.e just something that will messup
with skb->protocol.
And here is
On Sat, Jan 12, 2019 at 06:28:27PM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> The skb header should be set to ethernet header before using
> is_skb_forwardable(including dev->hard_header_len length).
Hi Yunjian
I don't see any recent changes in this code. Do you know why this is
needed
Hello,
>> getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes
>> returning the source IP instead the destination IP. Using getsockname()
>> instead looks like solving the issue.
>>
>> For just an example:
>> Out of 6569124 requests , 4 requests were wrong 0.60891 % (this
Make the access to the struct inet_hashinfo's ehash member consistent.
In net/ipv4/inet_hashtables.c, the ehash member is accessed by calling
inet_ehash_bucket(...) except for the access in __inet_lookup_established.
In order to make the access consistent, use inet_ehash_bucket(...)
in __inet_looku
On 2019-01-11 10:55 a.m., Arnaldo Carvalho de Melo wrote:
Hi Peter,
bpf_perf_event_open() already returns a value, but if
perf_event_output's output_begin (mostly perf_output_begin) fails,
the only way to know about that is looking before/after the rb->lost,
right?
For ring buff
groff stiff complains about unbreakable lines:
96: warning [p 2, 3.0i]: can't break line
Indent it some more.
Fixes: 7f5047524c99 ("man: ss.8: break and indent long line")
Signed-off-by: Luca Boccassi
---
man/man8/ss.8 | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --
Pass the same parameters Lintian uses in Debian.
$ make check
<...>
Checking manpages for syntax errors...
:48: warning: macro `Q' not defined
Error in tc-taprio.8
Makefile:27: recipe for target 'check' failed
Signed-off-by: Luca Boccassi
---
As far as I can see all the shell-ery should be porta
.Q does not exist so groff complains and the "queues" word is actually
not displayed.
Fixes: 579acb4bc52f ("taprio: Add manpage for tc-taprio(8)")
Signed-off-by: Luca Boccassi
---
man/man8/tc-taprio.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/man8/tc-taprio.8 b/man
On 2019-01-11 9:55 p.m., Cong Wang wrote:
Martin reported a set of filters don't work after changing
from reclassify to continue. Looking into the code, it
looks like skb protocol is not always fetched for each
iteration of the filters. But, as demonstrated by Martin,
TC actions could modify skb-
On 2019-01-10 8:45 a.m., Simon Horman wrote:
On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
You can use flower instead of basic but such one offs basic would
be more effective.
Bartek, if you say you have 20 vlans: worst case scenario
here is you are going to do 20 lookups (
From: Yunjian Wang
The skb header should be set to ethernet header before using
is_skb_forwardable(including dev->hard_header_len length).
Signed-off-by: Yunjian Wang
---
net/bridge/br_forward.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_forward.c b/n
On Fri, Jan 11, 2019 at 12:14:11PM -0800, Benedict Wong wrote:
> A behavior change introduced in 9b42c1f179a6 (“xfrm: Extend the
> output_mark to support input direction and masking”) results in a
> change in:
>
> 1. Default outbound behavior with regards to route lookup marks, and
> 2. Inbound be
39 matches
Mail list logo
