From: Willem de Bruijn
Date: Wed, 20 Sep 2017 11:38:45 -0400
> 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
On Wed, Sep 20, 2017 at 2:08 AM, David Miller wrote:
> From: Petar Penkov
> Date: Tue, 19 Sep 2017 21:26:14 -0700
>
>> Furthermore, in a way testing already requires specific kernel
>> configuration. In this particular example, syzkaller prefers
>> synchronous operation and therefore needs 4KSTA
From: Petar Penkov
Date: Tue, 19 Sep 2017 21:26:14 -0700
> 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 KAS
On Tue, Sep 19, 2017 at 4:01 PM, David Miller wrote:
> From: Petar Penkov
> Date: Tue, 19 Sep 2017 00:34:00 -0700
>
>> The following patches address this by providing the user(syzkaller)
>> with the ability to send via napi_gro_receive() and napi_gro_frags().
>> Additionally, syzkaller can specif
From: Petar Penkov
Date: Tue, 19 Sep 2017 00:34:00 -0700
> The following patches address this by providing the user(syzkaller)
> with the ability to send via napi_gro_receive() and napi_gro_frags().
> Additionally, syzkaller can specify how many fragments there are and
> how much data per fragmen
The following patches address this by providing the user(syzkaller)
with the ability to send via napi_gro_receive() and napi_gro_frags().
Additionally, syzkaller can specify how many fragments there are and
how much data per fragment there is. This is done by exploiting the
convenient structure of
