Re: violating function pointer signature

* Segher Boessenkool: > On Wed, Nov 18, 2020 at 12:17:30PM -0500, Steven Rostedt wrote: >> I could change the stub from (void) to () if that would be better. > > Don't? In a function definition they mean exactly the same thing (and > the kernel uses (void) everywhere else, which many people find

Re: violating function pointer signature

* Peter Zijlstra: >> The default Linux calling conventions are all of the cdecl family, >> where the caller pops the argument off the stack. You didn't quote >> enough to context to tell whether other calling conventions matter in >> your case. > > This is strictly in-kernel, and I think we're al

Re: violating function pointer signature

* Peter Zijlstra: > I think that as long as the function is completely empty (it never > touches any of the arguments) this should work in practise. > > That is: > > void tp_nop_func(void) { } > > can be used as an argument to any function pointer that has a void > return. In fact, I already do

Re: [PATCH] dns: Apply a default TTL to records obtained from getaddrinfo()

* David Howells: > Fix this to apply a default TTL of 10mins in the event that we haven't got > one. This can be configured in /etc/keyutils/key.dns_resolver.conf by > adding the line: > > default_ttl: > > to the file. If the name resolution is not needed continuously, but only for the co

GPL compliance issue with liquidio/lio_23xx_vsw.bin firmware

liquidio/lio_23xx_vsw.bin contains a compiled MIPS Linux kernel: $ tail --bytes=+1313 liquidio/lio_23xx_vsw.bin > elf $ readelf -aW elf […] [ 6] __ksymtab PROGBITS80e495f8 64a5f8 00d130 00 A 0 0 8 [ 7] __ksymtab_gpl PROGBITS80e56728 657728 00

sendmmsg flags userspace ABI change in kernel 4.6

Since this commit: commit 28a94d8fb35b3a75b802f368ae6f4a9f6b0d435a Author: Tom Herbert Date: Mon Mar 7 14:11:02 2016 -0800 net: Allow MSG_EOR in each msghdr of sendmmsg This patch allows setting MSG_EOR in each individual msghdr passed in sendmmsg. This allows a sendmmsg to send m

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 06:29 PM, Linus Torvalds wrote: Gcc people are crazy. End of discussion from me. This is not acceptable. Florian

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 05:25 AM, Kees Cook wrote: In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One c

Re: [net-next PATCH 2/3] net: reduce cycles spend on ICMP replies that gets rate limited

On 06/04/2017 04:38 PM, Jesper Dangaard Brouer wrote: > On Sun, 4 Jun 2017 09:11:53 +0200 > Florian Weimer wrote: > >> On 01/09/2017 04:04 PM, Jesper Dangaard Brouer wrote: >> >>> This patch split the global and per (inet)peer ICMP-reply limiter >>> co

Re: [net-next PATCH 2/3] net: reduce cycles spend on ICMP replies that gets rate limited

On 01/09/2017 04:04 PM, Jesper Dangaard Brouer wrote: > This patch split the global and per (inet)peer ICMP-reply limiter > code, and moves the global limit check to earlier in the packet > processing path. Thus, avoid spending cycles on ICMP replies that > gets limited/suppressed anyhow. > > The

Re: Kernel uapi and glibc header conflicts (was Re: header conflict introduced by change to netfilter_ipv4/ip_tables.h )

On 02/07/2016 12:31 PM, Mikko Rapeli wrote: > On Thu, Jan 07, 2016 at 10:30:40AM -0800, Stephen Hemminger wrote: >> On Thu, 7 Jan 2016 07:29:50 + >> Mikko Rapeli wrote: >> >>> On Wed, Jan 06, 2016 at 09:20:07AM -0800, Stephen Hemminger wrote: This commit breaks compilation of iproute2 wit

Re: Asterisk deadlocks since Kernel 4.1

On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > I can try Kernel 4.4-rc1 next week. Or something else? I found this bug report which indicates that 4.1.10 works: But in your original report, you said that 4.1.13 is broken.

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:36 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. > > sorry here it is. What I'm wondering is why is there ipv6

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 10:23 PM, Stefan Priebe wrote: >> please try to get a backtrace with debugging information. It is likely >> that this is the make_request/__check_pf functionality in glibc, but it >> would be nice to get some certainty. >> >> Which glibc version do you use? Has it got a fix for CVE

Re: Asterisk deadlocks since Kernel 4.1

On 11/18/2015 09:23 PM, Stefan Priebe wrote: > > Am 17.11.2015 um 20:43 schrieb Thomas Gleixner: >> On Tue, 17 Nov 2015, Stefan Priebe wrote: >>> I've now also two gdb backtraces from two crashes: >>> http://pastebin.com/raw.php?i=yih5jNt8 >>> >>> http://pastebin.com/raw.php?i=kGEcvH4T >> >> They

Re: [PATCH] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]

On 11/03/2015 02:48 PM, Hannes Frederic Sowa wrote: > Hello, > > On Fri, Oct 23, 2015, at 21:07, Florian Weimer wrote: >> (By the way, we'd also love to have a better kernel interface to fulfill >> the needs for getaddrinfo address sorting. The netlink requests we >

[PATCH v2] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]

On 10/24/2015 06:22 AM, Mike Frysinger wrote: > On 23 Oct 2015 22:07, Florian Weimer wrote: >> --- /dev/null >> +++ b/sysdeps/unix/sysv/linux/netlink_assert_response.c >> @@ -0,0 +1,100 @@ >> +/* Copyright (C) 2015 Free Software Foundation, Inc. >> + This

[PATCH] glibc: Terminate process on invalid netlink response from kernel [BZ #12926]

ength (without the netlink header) is received, or an error code which cannot happen due to the way the netlink socket is used. 2015-10-23 Florian Weimer [BZ #12926] Terminate process on invalid netlink response. * sysdeps/unix/sysv/linux/netlinkaccess.h (__netlink_assert_response): Declare. * sy

Re: e1000 driver and samba

gned bit flips is not detected by the TCP checksum. 8-( Actually, nobody should use TCP without application-level checksums for that reason. But of course, there is HTTP. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100

Re: Beyond 64K TCP connections limit per IP-address

port. But as soon as multiple clients are involved, there is virtually no protocol-imposed limit. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-

Re: [PATCH 2.6.18-rc6 1/2] dllink driver: porting v1.19 to linux 2.6.18-rc6

bugs, but current systems with different timings expose them. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 - To unsubscribe from t

Re: Question about tcp hash function tcp_hashfn()

* Evgeniy Polyakov: > :) thats true, but to be 100% honest I used different code to test for > hash artifacts... Ah, okay. > But it still does not fix artifacts with for example const IP and random > ports or const IP and linear port selection. I see them now. Hmm. Is there a theoretical expl

Re: Question about tcp hash function tcp_hashfn()

* Evgeniy Polyakov: > That is wrong. And I have a code and picture to show that, > and you dont - prove me wrong :) Here we go: static inline num2ip(__u8 a1, __u8 a2, __u8 a3, __u8 a4) { __u32 a = 0; a |= a1; a << 8; a |= a2; a << 8; a |= a3;