Re: [PATCH,net-next,0/2] Improve code coverage of syzkaller

On Wed, Sep 20, 2017 at 2:08 AM, David Miller [off-list ref] wrote:

From: Petar Penkov <redacted>
Date: Tue, 19 Sep 2017 21:26:14 -0700

quoted

Furthermore, in a way testing already requires specific kernel
configuration.  In this particular example, syzkaller prefers
synchronous operation and therefore needs 4KSTACKS disabled. Other
features that require rebuilding are KASAN and dbx. From this point
of view, I still think that having the TUN_NAPI flag has value.

Then I think this path could be enabled/disabled with a runtime flag
just as easily, no?

I think that the compile time option was chosen because of the ns_capable
check, so that with user namespaces unprivileged processes can control this
path. Perhaps we can require capable() only to set IFF_NAPI_FRAGS.

Then we can convert the napi_gro_receive path to be conditional on a new
IFF_NAPI flag instead of this compile time option.