From: Geert Uytterhoeven
> Sent: 20 April 2021 08:40
>
> Hi Willy,
>
> On Sat, Apr 17, 2021 at 4:49 AM Matthew Wilcox wrote:
> > Replacement patch to fix compiler warning.
> >
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm,
From: Matthew Wilcox
> Sent: 17 April 2021 03:45
>
> Replacement patch to fix compiler warning.
...
> static inline dma_addr_t page_pool_get_dma_addr(struct page *page)
> {
> - return page->dma_addr;
> + dma_addr_t ret = page->dma_addr[0];
> + if (sizeof(dma_addr_t) > sizeof(unsigne
From: Matthew Wilcox (Oracle)
> Sent: 17 April 2021 00:07
>
> The net page_pool wants to use a magic value to identify page pool pages.
> The best place to put it is in the first word where it can be clearly a
> non-pointer value. That means shifting dma_addr up to alias with ->index,
> which me
From: Grygorii Strashko
> Sent: 16 April 2021 10:27
...
> Sry, for delayed reply.
>
> The TI platforms am3/4/5 (cpsw) and Keystone 2 (netcp) can do only 32bit DMA
> even in case of LPAE
> (dma-ranges are used).
> Originally, as I remember, CONFIG_ARCH_DMA_ADDR_T_64BIT has not been selected
> for
From: Matteo Croce
> Sent: 16 April 2021 23:44
...
> > A more interesting change would be something that generated:
> > unsigned int nr_frags = skb_shinfo(skb)->nr_frags;
> > for (i = 0; i < nr_frags; i++) {
> > since that will run faster for most loops.
> > But that is ~impossible
From: Matthew Wilcox
> Sent: 16 April 2021 16:28
>
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > See below patch. Where I swap32 the dma address to satisfy
> > page->compound having bit zero cleared. (It is the simplest fix I could
> > come up with).
>
> I think t
From: Matthew Wilcox
> Sent: 15 April 2021 23:22
>
> On Thu, Apr 15, 2021 at 09:11:56PM +0000, David Laight wrote:
> > Isn't it possible to move the field down one long?
> > This might require an explicit zero - but this is not a common
> > code path - the extra w
From: Matthew Wilcox
> Sent: 15 April 2021 19:22
>
> On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > +static inline
> > +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> > +{
> > + /* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> > +
From: Andrii Nakryiko
> Sent: 14 April 2021 21:02
>
> While -Og is designed to work well with debugger, it's still inferior to -O0
> in terms of debuggability experience. It will cause some variables to still be
> inlined, it will also prevent single-stepping some statements and otherwise
> interf
From: Matthew Wilcox
> Sent: 14 April 2021 22:36
>
> On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > (If others want to reproduce). First I could not reproduce on ARM32.
> > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > cause the issue by enab
> Doing this fixes it:
>
> +++ b/include/linux/types.h
> @@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
> * so they don't care about the size of the actual bus addresses.
> */
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> -typedef u64 dma_addr_t;
> +typedef u64 __attribute__((aligned(sizeof(void * d
From: Tom Talpey
> Sent: 14 April 2021 15:16
>
> On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
> > On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
> >
> >> So the issue is only in testing all the providers and platforms,
> >> to be sure this new behavior isn't tickling anything that wen
From: Matthew Wilcox
> Sent: 12 April 2021 19:24
>
> On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> > Could you explain your intent here?
> > I worry about @index.
> >
> > As I mentioned in other thread[1] netstack use page_is_pfmemalloc()
> > (code copy-pasted below si
From: Matteo Croce
> Sent: 12 April 2021 01:38
>
> Introduce skb_for_each_frag, an helper macro to iterate over the SKB frags.
The real question is why, the change is:
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ skb_for_each_frag(skb, i) {
The existing code isn't complicat
From: Tom Talpey
> Sent: 09 April 2021 18:49
> On 4/9/2021 12:27 PM, Haakon Bugge wrote:
> >
> >
> >> On 9 Apr 2021, at 17:32, Tom Talpey wrote:
> >>
> >> On 4/9/2021 10:45 AM, Chuck Lever III wrote:
> On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
>
> On 4/6/2021 7:49 AM, Jason Gu
From: Sven Van Asbroeck
> Sent: 08 April 2021 19:35
...
> - buffer_length = netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING;
> + buffer_length = netdev->mtu + ETH_HLEN + ETH_FCS_LEN +
> RX_HEAD_PADDING;
I'd try to write the lengths in the order they happen, so:
buffer_length = RX
From: Vladimir Oltean
> Sent: 29 March 2021 17:24
>
> On Mon, Mar 29, 2021 at 05:14:43PM +0300, Claudiu Manoil wrote:
> > Static analysis tool reports:
> > "Suspicious implicit sign extension - 'flags' with type u8 (8 bit,
> > unsigned) is promoted in 'flags' << 24 to type int (32 bits, signed),
>
From: Alex Elder
> Sent: 24 March 2021 17:07
>
> On 3/24/21 11:27 AM, David Laight wrote:
> > From: Alex Elder
> >> Sent: 23 March 2021 01:05
> >> It is possible for a 32 bit x86 build to use a 64 bit DMA address.
> >>
> >> There are two
From: Alex Elder
> Sent: 23 March 2021 01:05
> It is possible for a 32 bit x86 build to use a 64 bit DMA address.
>
> There are two remaining spots where the IPA driver does a modulo
> operation to check alignment of a DMA address, and under certain
> conditions this can lead to a build error on i
From: David Laight
> Sent: 24 March 2021 09:12
>
> From: Martin Sebor
> > Sent: 22 March 2021 22:08
> ...
> > In GCC 11, all access warnings expect objects to be either declared
> > or allocated. Pointers with constant values are taken to point to
> > nothing
From: Martin Sebor
> Sent: 22 March 2021 22:08
...
> In GCC 11, all access warnings expect objects to be either declared
> or allocated. Pointers with constant values are taken to point to
> nothing valid (as Arnd mentioned above, this is to detect invalid
> accesses to members of structs at addre
From: Herbert Xu
> Sent: 21 March 2021 12:49
>
> On Sun, Mar 21, 2021 at 08:39:29PM +0800, menglong8.d...@gmail.com wrote:
> >
> > diff --git a/include/linux/socket.h b/include/linux/socket.h
> > index d5ebfe30d96b..317b2933f499 100644
> > --- a/include/linux/socket.h
> > +++ b/include/linux/socke
From: Guenter Roeck
> Sent: 17 March 2021 01:38
...
> MSG_CMSG_COMPAT (0x8000) is set in flags, meaning its value is negative.
> This is then evaluated in
>
>if (flags &
> ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
> goto out;
>
> If any of those
From: Jiapeng Chong
> Sent: 09 March 2021 10:11
>
> Fix the following coccicheck warnings:
>
> ./tools/perf/util/machine.c:2041:9-10: WARNING: return of 0/1 in
> function 'symbol__match_regex' with return type bool.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> tools/per
...
> Sort of related, I have been meaning to eliminate the
> pointless __aligned(1) tags on rmnet structures defined
> in . It wouldn't hurt to use __packed,
> though I think they're all 4 or 8 bytes naturally anyway.
> Perhaps marking them __aligned(4) would help identify
> potential unaligned a
...
> >> - if (!csum_trailer->valid) {
> >> + if (!u8_get_bits(csum_trailer->flags, MAP_CSUM_DL_VALID_FMASK)) {
> >
> > Is that just an overcomplicated way of saying:
> > if (!(csum_trailer->flags & MAP_CSUM_DL_VALID_FMASK)) {
>
> Yes it is. I defined and used all the field masks in a
> con
From: Alex Elder
> Sent: 06 March 2021 03:16
>
> Replace the use of C bit-fields in the rmnet_map_ul_csum_header
> structure with a single two-byte (big endian) structure member,
> and use field masks to encode or get values within it.
>
> Previously rmnet_map_ipv4_ul_csum_header() would update v
From: Alex Elder
> Sent: 06 March 2021 03:16
>
> Replace the use of C bit-fields in the rmnet_map_dl_csum_trailer
> structure with a single one-byte field, using constant field masks
> to encode or get at embedded values.
>
> Signed-off-by: Alex Elder
> Reviewed-by: Bjorn Andersson
> ---
> ...
Some thoughts...
Does a non-android linux system behave correctly through the same NAT gateways?
Particularly with a similar kernel version.
If you have a USB OTG cable and USB ethernet dongle you may be able to get
android to use a wired ethernet connection - excluding any WiFi issues.
(OTG usua
> > > vfs_truncate disasm:
> > >
> > > 80001031f430 :
> > > 80001031f430: 5f 24 03 d5 hint#34
> > > 80001031f434: 1f 20 03 d5 nop
> > > 80001031f438: 1f 20 03 d5 nop
> > > 80001031f43c: 3f 23 03 d5 hint#25
> > >
> > > thats
From: Marc Kleine-Budde
> Sent: 09 February 2021 11:28
>
> On 09.02.2021 10:34:42, David Laight wrote:
...
> > AFAICT there is one structure that would have end-padding.
> > But I didn't actually spot anything validating it's length.
> > Which may well mean th
From: Marc Kleine-Budde
> Sent: 08 February 2021 13:16
>
> On 04.02.2021 17:26:13, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > struct ucan_message_in contains member with 4-byte alignment
> > but is itself marked as unaligned, which triggers a warning:
> >
> > drivers/net/can/usb/ucan.c:
From: Arnd Bergmann
> Sent: 04 February 2021 16:29
>
> Multiple structures in the carl9170 driver have alignment
> impossible alignment constraints that gcc warns about when
> building with 'make W=1':
>
> drivers/net/wireless/ath/carl9170/fwcmd.h:243:2: warning: alignment 1 of
> 'union ' is les
From: Paolo Abeni
> Sent: 02 February 2021 10:19
...
> Note that you can already process several packets with a single syscall
> using sendmmsg/recvmmsg. Both have issues with error reporting and
> timeout and IIRC still don't amortize the overhead introduced e.g. by
> CONFIG_HARDENED_USERCOPY.
Bo
From: Xie He
> Sent: 01 February 2021 16:15
>
> On Mon, Feb 1, 2021 at 6:10 AM Julian Wiedmann wrote:
> >
> > This sounds a bit like you want skb_cow_head() ... ?
>
> Calling "skb_cow_head" before we call "skb_clone" would indeed solve
> the problem of writes to our clones affecting clones in ot
> I'd encourage anyone thinking about "using OOB" to read
> https://tools.ietf.org/html/rfc6093 first. Basically, TCP does not
> actually provide an OOB mechanism, and frankly Unix sockets shouldn't
> try either.
OOB data maps much better onto ISO transport 'expedited data'
than anything in a byt
From: Xie He
> Sent: 27 January 2021 09:08
>
> An HDLC hardware driver may call netif_stop_queue to temporarily stop
> the TX queue when the hardware is busy sending a frame, and after the
> hardware has finished sending the frame, call netif_wake_queue to
> resume the TX queue.
>
> However, the
From: Kevin Hao
> Sent: 21 January 2021 07:09
>
> The octeontx2 hardware needs the buffer to be 128 byte aligned.
> But in the current implementation of napi_alloc_frag(), it can't
> guarantee the return address is 128 byte aligned even the request size
> is a multiple of 128 bytes, so we have to
From: Eric Dumazet
> Sent: 14 January 2021 05:17
>
> On Wed, Jan 13, 2021 at 11:23 PM David Laight wrote:
> >
> > From: Eric Dumazet
> > > Sent: 13 January 2021 16:18
> > >
> > > From: Eric Dumazet
> > >
> > > Both virtio net an
From: Eric Dumazet
> Sent: 13 January 2021 16:18
>
> From: Eric Dumazet
>
> Both virtio net and napi_get_frags() allocate skbs
> with a very small skb->head
>
> While using page fragments instead of a kmalloc backed skb->head might give
> a small performance improvement in some cases, there is
From: Marc Kleine-Budde
> Sent: 07 January 2021 21:17
>
> On 1/7/21 8:06 PM, Jakub Kicinski wrote:
> > On Thu, 7 Jan 2021 11:00:35 -0800 Jakub Kicinski wrote:
> >> On Thu, 7 Jan 2021 10:48:56 +0100 Marc Kleine-Budde wrote:
> >>> +struct __packed tcan4x5x_map_buf {
> >>> + struct tcan4x5x_buf_cmd
From: Christoph Hellwig
> Sent: 21 September 2020 15:34
>
> Stop duplicating the iovec verify code, and instead add add a
> __import_iovec helper that does the whole verify and import, but takes
> a bool compat to decided on the native or compat layout. This also
> ends up massively simplifying
From: Christoph Hellwig
> Sent: 21 September 2020 15:22
>
> So looking at the various callers I'm not sure this API is the
> best. If we want to do something fancy I'd hide the struct iovec
> instances entirely with something like:
>
> struct iov_storage {
> struct iovec stack[UIO_FASTIOV]
From: Tom Rix
> Sent: 25 December 2020 14:57
...
> > Kernel code doesn't use a signed char or short with %hx or %hu very often
> > but in case you didn't already know, any signed char/short emitted with
> > anything like %hx or %hu needs to be left alone as sign extension occurs so:
>
> Yes, this
From: Alexei Starovoitov
> Sent: 16 December 2020 02:36
...
> > The problem is never about granularity, it is about how efficient we can
> > GC. User-space has to scan the whole table one by one, while the kernel
> > can just do this behind the scene with a much lower overhead.
> >
> > Let's say we
From: Thomas Gleixner
> Sent: 11 December 2020 21:11
>
> On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> > From: Thomas Gleixner
> >> You can't catch that. If this really becomes an issue you need a
> >> sequence counter around it.
> >
> > Or
From: Thomas Gleixner
> Sent: 11 December 2020 12:58
..
> > After my failed hasty sketch from last night I had a different one which
> > was kind of heuristics based (re-reading the upper dword and retrying if
> > it changed on 32-bit).
>
> The problem is that there will be two seperate modificati
From: Xie He
> Sent: 10 December 2020 10:17
>
> On Thu, Dec 10, 2020 at 1:14 AM David Laight wrote:
> >
> > > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > &g
From: Xie He
> Sent: 09 December 2020 22:54
>
> On Wed, Dec 9, 2020 at 1:21 PM David Laight wrote:
> >
> > I always wondered about running Class 2 transport directly over LLC2
> > (rather than Class 4 over LLC1).
> > But the only LLC2 user was netbios - and mic
From: Xie He
> Sent: 09 December 2020 03:34
>
> According to the X.25 documentation, there was a plan to implement
> X.25-over-802.2-LLC. It never finished but left various code stubs in the
> X.25 code. At this time it is unlikely that it would ever finish so it
> may be better to remove those co
From: Eric
> Sent: 03 December 2020 23:15
>
> On Fri, Dec 4, 2020 at 12:01 AM David Laight wrote:
> >
> > From: Stephen Hemminger
> > > Sent: 03 December 2020 00:15
> > >
> > > On Wed, 2 Dec 2020 14:09:38 -0800
> > > Arjun Roy wro
From: Arjun Roy
> Sent: 03 December 2020 23:25
...
> > > You also have to allow for old (working) applications being recompiled
> > > with the new headers.
> > > So you cannot rely on the fields being zero even if you are passed
> > > the size of the structure.
> > >
> >
> > I think this should alr
From: Stephen Hemminger
> Sent: 03 December 2020 00:15
>
> On Wed, 2 Dec 2020 14:09:38 -0800
> Arjun Roy wrote:
>
> > diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
> > index cfcb10b75483..62db78b9c1a0 100644
> > --- a/include/uapi/linux/tcp.h
> > +++ b/include/uapi/linux/tcp.
From: Stephen Hemminger
> Sent: 30 November 2020 00:22
>
> The code here was doing strncpy() in a way that causes gcc 10
> warning about possible string overflow. Just use strlcpy() which
> will null terminate and bound the string as expected.
>
> This has existed since start of git era so no Fix
From: Arnd Bergmann
> Sent: 24 November 2020 19:06
>
> On Tue, Nov 24, 2020 at 5:13 PM David Laight wrote:
> >
> > From: Arnd Bergmann
> > > Sent: 24 November 2020 15:18
> > >
> > > SIOCGIFMAP and SIOCSIFMAP currently require compat_alloc_user_
From: Arnd Bergmann
> Sent: 24 November 2020 15:18
>
> The ethtool compat ioctl handling is hidden away in net/socket.c,
> which introduces a couple of minor oddities:
>
...
> +
> +static int ethtool_rxnfc_copy_from_compat(struct ethtool_rxnfc *rxnfc,
> + con
From: Arnd Bergmann
> Sent: 24 November 2020 15:18
>
> SIOCGIFMAP and SIOCSIFMAP currently require compat_alloc_user_space()
> and copy_in_user() for compat mode.
>
> Move the compat handling into the location where the structures are
> actually used, to avoid using those interfaces and get a cle
From: Russell King
> Sent: 24 November 2020 15:17
...
> That said, _if_ the PHY has a way to read the resolved state rather
> than reading the advertisement registers, that is what should be
> used (as I said previously) rather than trying to decode the
> advertisement registers ourselves. That is
From: Martin Schiller
> Sent: 24 November 2020 09:36
>
> 1. DTE interface changes immediately to LAPB_STATE_1 and start sending
>SABM(E).
>
> 2. DCE interface sends N2-times DM and changes to LAPB_STATE_1
>afterwards if there is no response in the meantime.
Seems reasonable.
It is 35 yea
From: Segher Boessenkool
> Sent: 19 November 2020 16:35
...
> I just meant "valid C language code as defined by the standards". Many
> people want all UB to just go away, while that is *impossible* to do for
> many compilers: for example where different architectures or different
> ABIs have contr
From: Mathieu Desnoyers
> Sent: 18 November 2020 16:01
...
> > If it is already done elsewhere in the kernel, then I will call this
> > precedence, and keep the original version.
>
> It works for me. Bonus points if you can document in a comment that this
> trick depends on the cdecl calling conve
From: Kuniyuki Iwashima
> Sent: 17 November 2020 09:40
>
> The SO_REUSEPORT option allows sockets to listen on the same port and to
> accept connections evenly. However, there is a defect in the current
> implementation. When a SYN packet is received, the connection is tied to a
> listening socket
From: Martin Schiller
> Sent: 16 November 2020 13:55
> Extended struct x25_neigh and x25_subscrip_struct to configure following
> params through SIOCX25SSUBSCRIP:
> o mode (DTE/DCE)
> o number of channels
> o facilities (packet size, window size)
> o timer T20
>
> Based on this configurati
From: Eric Dumazet
> Sent: 12 November 2020 10:42
>
> On 11/12/20 7:52 AM, Kegl Rohit wrote:
> > On Wed, Nov 11, 2020 at 11:18 PM Fabio Estevam wrote:
> >>
> >> On Wed, Nov 11, 2020 at 11:27 AM Kegl Rohit wrote:
> >>>
> >>> Hello!
> >>>
> >>> We are using a imx6q platform.
> >>> The fec interfac
> On 11/11/20 3:27 PM, Kegl Rohit wrote:
> > Hello!
> >
> > We are using a imx6q platform.
> > The fec interface is used to receive a continuous stream of custom /
> > raw ethernet packets. The packet size is fixed ~132 bytes and they get
> > sent every 250µs.
> >
> > While testing I observed spont
From: Andrew Lunn
> Sent: 07 November 2020 22:33
>
> On Sat, Nov 07, 2020 at 09:39:42AM -0800, Joe Perches wrote:
> > On Sat, 2020-11-07 at 20:54 +0800, Alex Shi wrote:
> > > 在 2020/11/7 上午12:39, Florian Fainelli 写道:
> > > > > It is good to remember that there are multiple readers of source
> > >
From: Joe Perches
> Sent: 06 November 2020 21:50
>
> On Fri, 2020-11-06 at 13:32 -0800, Andrii Nakryiko wrote:
> > On Thu, Nov 5, 2020 at 11:12 PM wrote:
> > > Fix following warning from coccinelle:
> > > ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not
> > > needed here
> []
From: Nicolas Pitre
> Sent: 06 November 2020 15:06
>
> On Fri, 6 Nov 2020, David Laight wrote:
>
> > From: Jakub Kicinski
> > > Sent: 05 November 2020 22:47
> > >
> > > On Wed, 4 Nov 2020 16:48:57 +0100 Andrew Lunn wrote:
> > > > -
From: Joe Perches
> Sent: 06 November 2020 06:36
>
> On Fri, 2020-11-06 at 13:37 +0800, Alex Shi wrote:
> > There are some macros unused, they causes much gcc warnings. Let's
> > remove them to tame gcc.
>
> I believe these to be essentially poor warnings.
Indeed.
One 'solution' is to move the
From: Xie He
> Sent: 05 November 2020 22:47
>
> On Thu, Nov 5, 2020 at 12:40 PM Arnd Bergmann wrote:
> >
> > > I think this driver never worked. Looking at the original code in
> > > Linux 2.1.31, it already has the problems I fixed in commit
> > > 8fdcabeac398.
> > >
> > > I guess when people (o
From: Jakub Kicinski
> Sent: 05 November 2020 22:38
> On Wed, 4 Nov 2020 16:48:52 +0100 Andrew Lunn wrote:
> > drivers/net/ethernet/smsc/smc91x.c:706:51: warning: variable ‘pkt_len’ set
> > but not used [-Wunused-
> but-set-variable]
> > 706 | unsigned int saved_packet, packet_no, tx_status, p
From: Jakub Kicinski
> Sent: 05 November 2020 22:47
>
> On Wed, 4 Nov 2020 16:48:57 +0100 Andrew Lunn wrote:
> > - buf = (char*)((u32)skb->data & ~0x3);
> > - len = (skb->len + 3 + ((u32)skb->data & 3)) & ~0x3;
> > - cmdA = (((u32)skb->data & 0x3) << 16) |
> > + offset = (unsigned long)sk
From: Xie He
> Sent: 05 November 2020 19:35
>
> On Thu, Nov 5, 2020 at 1:10 AM David Laight wrote:
> >
> > > This driver transports LAPB (X.25 link layer) frames over TTY links.
> >
> > I don't remember any requests to run LAPB over anything other
>
From: Heiner Kallweit
> Sent: 05 November 2020 13:58
>
> RTL8125B has same or similar short packet hw padding bug as RTL8168evl.
> The main workaround has been extended accordingly, however we have to
> disable also hw checksumming for short packets on affected new chip
> versions. Change the code
From: Xie He
> Sent: 05 November 2020 07:35
>
> This driver transports LAPB (X.25 link layer) frames over TTY links.
I don't remember any requests to run LAPB over anything other
than synchronous links when I was writing LAPB implementation(s)
back in the mid 1980's.
If you need to run 'comms ov
From: Jakub Kicinski
> Sent: 03 November 2020 00:01
>
> On Sat, 31 Oct 2020 18:40:28 +0100 Andrew Lunn wrote:
> > In function ‘strncpy’,
> > inlined from ‘sky2_name’ at drivers/net/ethernet/marvell/sky2.c:4903:3,
> > inlined from ‘sky2_probe’ at drivers/net/ethernet/marvell/sky2.c:5049:2:
From: Jakub Kicinski
> Sent: 02 November 2020 23:48
>
> On Sat, 31 Oct 2020 01:49:57 +0100 Andrew Lunn wrote:
> > drivers/net/ethernet/smsc/smc911x.c: In function
> > ‘smc911x_hardware_send_pkt’:
> > drivers/net/ethernet/smsc/smc911x.c:471:11: warning: cast from pointer to
> > integer of differe
From: 'Greg KH'
> Sent: 02 November 2020 13:52
>
> On Mon, Nov 02, 2020 at 09:06:38AM +, David Laight wrote:
> > From: 'Greg KH'
> > > Sent: 23 October 2020 15:47
> > >
> > > On Fri, Oct 23, 2020 at 02:39:24PM +, David La
From: 'Greg KH'
> Sent: 23 October 2020 15:47
>
> On Fri, Oct 23, 2020 at 02:39:24PM +, David Laight wrote:
> > From: David Hildenbrand
> > > Sent: 23 October 2020 15:33
> > ...
> > > I just checked against upstream code generated by clang 10 a
From: Andrew Lunn
> Sent: 29 October 2020 14:31
> On Thu, Oct 29, 2020 at 02:19:27PM +, David Laight wrote:
> > From: Andrew Lunn
> > > Sent: 28 October 2020 00:23
> > >
> > > net/rose/af_rose.c: In function ‘rose_info_show’:
> > > net/rose/af_ro
From: Andrew Lunn
> Sent: 28 October 2020 00:23
>
> net/rose/af_rose.c: In function ‘rose_info_show’:
> net/rose/af_rose.c:1413:20: warning: trigraph ??- ignored, use -trigraphs to
> enable [-Wtrigraphs]
> 1413 |callsign = "??-?";
>
> ??- is a trigraph, and should be replaced by a ˜ by
From: Ard Biesheuvel
> Sent: 27 October 2020 20:57
>
> Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for
> ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a
> function scope __attribute__((optimize("-fno-gcse"))), to disable a
> GCC specific optimization that was ca
From: Arnd Bergmann
> Sent: 26 October 2020 21:03
>
> From: Arnd Bergmann
>
> Building with -Wextra shows lots of warnings in the bpf
> code such as
>
> kernel/bpf/verifier.c: In function ‘jit_subprogs’:
> include/linux/filter.h:345:4: warning: cast between incompatible function
> types from ‘
From: Stefano Garzarella
> Sent: 26 October 2020 09:39
>
> On Mon, Oct 26, 2020 at 09:13:23AM +0000, David Laight wrote:
> >From: Stefano Garzarella
> >> Sent: 26 October 2020 08:43
> >...
> >> >Isn't the canonical error for unknown ioctl codes -E
From: Stefano Garzarella
> Sent: 26 October 2020 08:43
...
> >Isn't the canonical error for unknown ioctl codes -ENOTTY?
> >
>
> Oh, thanks for pointing that out!
>
> I had not paid attention to the error returned, but looking at it I
> noticed that perhaps the most appropriate would be -ENOIOCTL
From: Segher Boessenkool
> Sent: 24 October 2020 18:29
>
> On Fri, Oct 23, 2020 at 09:28:59PM +0000, David Laight wrote:
> > From: Segher Boessenkool
> > > Sent: 23 October 2020 19:27
> > > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote:
> > >
From: Stefano Garzarella
> Sent: 23 October 2020 15:10
>
> On Fri, Oct 23, 2020 at 01:21:13PM +0100, Colin King wrote:
> >From: Colin Ian King
> >
> >When exercising the kernel with stress-ng with some ioctl tests the
> >"Unknown ioctl" error message is spamming the kernel log at a high
> >rate
From: Segher Boessenkool
> Sent: 23 October 2020 19:27
>
> On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote:
> > On Fri, Oct 23, 2020 at 03:09:30PM +0200, David Hildenbrand wrote:
> >
> > > Now, I am not a compiler expert, but as I already cited, at least on
> > > x86-64 clang expects that
From: David Hildenbrand
> Sent: 23 October 2020 15:33
...
> I just checked against upstream code generated by clang 10 and it
> properly discards the upper 32bit via a mov w23 w2.
>
> So at least clang 10 indeed properly assumes we could have garbage and
> masks it off.
>
> Maybe the issue is som
From: Arnd Bergmann
> Sent: 23 October 2020 14:23
>
> On Fri, Oct 23, 2020 at 2:46 PM David Laight wrote:
> >
> > From: Greg KH
> > > Sent: 22 October 2020 14:51
> >
> > I've rammed the code into godbolt.
> >
> > https://godbolt.org/
From: Greg KH
> Sent: 22 October 2020 14:51
I've rammed the code into godbolt.
https://godbolt.org/z/9v5PPW
Definitely a clang bug.
Search for [wx]24 in the clang output.
nr_segs comes in as w2 and the initial bound checks are done on w2.
w24 is loaded from w2 - I don't believe this changes th
From: Jakub Kicinski
> Sent: 23 October 2020 00:06
>
> On Thu, 22 Oct 2020 13:04:32 -0700 Kees Cook wrote:
> > > > > From: Francis Laniel
> > > > >
> > > > > Calls to nla_strlcpy are now replaced by calls to nla_strscpy which
> > > > > is the
> > > > > new name of this function.
> > > > >
> > >
From: Al Viro
> Sent: 22 October 2020 20:25
>
> On Thu, Oct 22, 2020 at 12:04:52PM -0700, Nick Desaulniers wrote:
>
> > Passing an `unsigned long` as an `unsigned int` does no such
> > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail
> > calls, no masking instructions).
> > So
From: Nick Desaulniers
> Sent: 22 October 2020 20:05
>
...
> Passing an `unsigned long` as an `unsigned int` does no such
> narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail
> calls, no masking instructions).
Right but is the called function going to use 32bit ops
and/or mask th
From: Matthew Wilcox
> Sent: 22 October 2020 17:41
>
> On Thu, Oct 22, 2020 at 04:35:17PM +0000, David Laight wrote:
> > Wait...
> > readv(2) defines:
> > ssize_t readv(int fd, const struct iovec *iov, int iovcnt);
>
> It doesn't really matter what
From: Christoph Hellwig
> Sent: 22 October 2020 14:24
>
> On Thu, Oct 22, 2020 at 11:36:40AM +0200, David Hildenbrand wrote:
> > My thinking: if the compiler that calls import_iovec() has garbage in
> > the upper 32 bit
> >
> > a) gcc will zero it out and not rely on it being zero.
> > b) clang wi
From: Greg KH
> Sent: 22 October 2020 15:40
>
> On Thu, Oct 22, 2020 at 04:28:20PM +0200, Arnd Bergmann wrote:
...
> > Can you attach the iov_iter.s files from the broken build, plus the
> > one with 'noinline' for comparison? Maybe something can be seen
> > in there.
>
> I don't know how to extr
From: David Hildenbrand
> Sent: 22 October 2020 10:25
...
> ... especially because I recall that clang and gcc behave slightly
> differently:
>
> https://github.com/hjl-tools/x86-psABI/issues/2
>
> "Function args are different: narrow types are sign or zero extended to
> 32 bits, depending on the
From: David Hildenbrand
> Sent: 22 October 2020 10:19
>
> On 22.10.20 11:01, Greg KH wrote:
> > On Thu, Oct 22, 2020 at 10:48:59AM +0200, David Hildenbrand wrote:
> >> On 22.10.20 10:40, David Laight wrote:
> >>> From: David Hildenbrand
> >>>> Se
From: Greg KH
> Sent: 22 October 2020 10:02
...
> I'm running some more tests, trying to narrow things down as just adding
> a "noinline" to the function that got moved here doesn't work on Linus's
> tree at the moment because the function was split into multiple
> functions.
I was going to look a
1 - 100 of 921 matches
Mail list logo
