DriverDev-Devel Archive on lore.kernel.org
 help / color / Atom feed
* monthly summary emails
@ 2019-11-22 11:32 Dan Carpenter
  2019-11-23  6:00 ` Dmitry Vyukov
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Carpenter @ 2019-11-22 11:32 UTC (permalink / raw)
  To: dvyukov; +Cc: devel, syzkaller-bugs

Hi Dmitry,

I help maintain drivers/staging.  Would it be possible to send us a
monthly summary of outstanding staging bugs?  I never remember to check
the website.

regards,
dan carpenter
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: monthly summary emails
  2019-11-22 11:32 monthly summary emails Dan Carpenter
@ 2019-11-23  6:00 ` Dmitry Vyukov
  0 siblings, 0 replies; 2+ messages in thread
From: Dmitry Vyukov @ 2019-11-23  6:00 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: open list:ANDROID DRIVERS, syzkaller, syzkaller-bugs, Eric Biggers

On Fri, Nov 22, 2019 at 12:32 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> Hi Dmitry,
>
> I help maintain drivers/staging.  Would it be possible to send us a
> monthly summary of outstanding staging bugs?  I never remember to check
> the website.

Hi Dan,

syzbot does not have such functionality. Maybe you seen +Eric's
emails, but that's purely manual effort at the moment. The issue to
follow for pings is: https://github.com/google/syzkaller/issues/550

But I am not sure syzkaller have any good coverage for
drivers/staging. In fact, now looking at coverage we report -- we
don't have any (except for android/{ion,ashmem}). So if you are
interested in drivers/staging quality, the first thing would be adding
syzkaller descriptions for code in drivers/staging, see:
https://github.com/google/syzkaller/blob/master/docs/syscall_descriptions.md#describing-new-system-calls
However, if the code is written in a way that makes untestable without
actual hardware, then syzbot won't help. But this also means the code
is not unit-tested and unit-testing is generally higher priority than
fuzzing (fuzzing is meant to find trickier bugs in a way that makes
them harder to debug and fix). If that's the case, then we need to
make it unit-testable/testable without hardware, which will ensure
some basic quality and will also open the road for fuzzing. Sorry, no
magic here...
Kunit may help with making code testable, see this for our recent
experiment for faking hardware:
https://groups.google.com/g/syzkaller/c/QyexLE6M3kM/m/Hwid5kk0CwAJ
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-22 11:32 monthly summary emails Dan Carpenter
2019-11-23  6:00 ` Dmitry Vyukov

DriverDev-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/driverdev-devel/0 driverdev-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 driverdev-devel driverdev-devel/ https://lore.kernel.org/driverdev-devel \
		driverdev-devel@linuxdriverproject.org devel@driverdev.osuosl.org
	public-inbox-index driverdev-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxdriverproject.driverdev-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git