All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzbot <syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com>,
	David Miller <davem@davemloft.net>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-wireless@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	syzkaller-bugs@googlegroups.com
Subject: Re: WARNING in rfkill_alloc
Date: Mon, 15 Jan 2018 13:01:07 +0100	[thread overview]
Message-ID: <1516017667.410.12.camel@sipsolutions.net> (raw)
In-Reply-To: <CACT4Y+aO8kwS+ketv3rr0x3EecZ6j+7ep8Ag6PuTirO00SqRtw@mail.gmail.com> (sfid-20180115_101229_108798_C47519CB)

On Mon, 2018-01-15 at 10:12 +0100, Dmitry Vyukov wrote:

> However, there can be some surprising things, for example, executing
> one ioctl/setsockopt with data meant for another one, or these
> 0xffffffffffffffff are actually mean 0 (for involved reasons), 

I think those fff was actually what was throwing me off.

> or we
> can simply have bugs in these descriptions so they don't match C
> structures and then all data is messed/shifted.

No, I think this part was OK.

> If this representation does not make sense to you right away, your
> best bet is looking at/running the C reproducer where you can see true
> data layout:
> 
> 
[...]
Yeah, good point, I should've just done that.

> > Ah, then again, now I see the fault injection - I guess dev_set_name()
> > just failed and we didn't check the return value, will fix that.
> 
> Yes, it's highly likely the root cause. The raw.log file shows there
> there was an immediately preceding fault in kmalloc in the same
> process, in a close stack.

Yep, I submitted the fix now (with the correct reported-by).

Also for the other one, the wiphy_register() warning.

johannes

  reply	other threads:[~2018-01-15 12:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-13 22:37 WARNING in rfkill_alloc syzbot
2018-01-15  8:57 ` Johannes Berg
2018-01-15  9:12   ` Dmitry Vyukov
2018-01-15 12:01     ` Johannes Berg [this message]
2018-01-15 12:11       ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1516017667.410.12.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.