On Thu, 7 Jan 2021 11:47:02 -0800
Linus Torvalds wrote:
> On Wed, Jan 6, 2021 at 8:45 PM Willem de Bruijn wrote:
> >
> > But there are three other kmap_atomic callers under net/ that do not
> > loop at all, so assume non-compound pages. In esp_output_head,
> > esp6_output_head and skb_seq_read.
On Wed, Jan 6, 2021 at 8:45 PM Willem de Bruijn wrote:
>
> But there are three other kmap_atomic callers under net/ that do not
> loop at all, so assume non-compound pages. In esp_output_head,
> esp6_output_head and skb_seq_read. The first two directly use
> skb_page_frag_refill, which can allocat
On Wed, 6 Jan 2021 17:03:48 -0800
Linus Torvalds wrote:
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -366,7 +366,7 @@ static inline void skb_frag_size_sub(skb_frag_t *frag,
> int delta)
> static inline bool skb_frag_must_loop(struct page *p)
> {
> #if defined(CONFIG_HIGH
On Wed, 6 Jan 2021 17:03:48 -0800 Linus Torvalds wrote:
> I wonder whether there is other code that "knows" about kmap() only
> affecting PageHighmem() pages thing that is no longer true.
>
> Looking at some other code, skb_gro_reset_offset() looks suspiciously
> like it also thinks highmem pages
On Wed, 6 Jan 2021 17:03:48 -0800
Linus Torvalds wrote:
> (although I wonder how/why the heck you've enabled
> CC_OPTIMIZE_FOR_SIZE=y, which is what causes "memcpy()" to be done as
> that "rep movsb". I thought we disabled it because it's so bad on most
> cpus).
Why?
Because to test x86_32, I h
On Wed, Jan 6, 2021 at 3:01 PM Steven Rostedt wrote:
>
> I triggered the following crash on x86_32 by simply doing a:
>
> (ssh'ing into the box)
>
> # head -100 /tmp/output-file
>
> Where the /tmp/output-file was the output of a trace-cmd report.
> Even after rebooting and not running the tracin
