On Mon 30-01-17 17:15:08, Daniel Borkmann wrote:
On 01/30/2017 08:56 AM, Michal Hocko wrote:
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
On 01/27/2017 11:05 AM, Michal Hocko wrote:[...]
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
So to answer your second email with the bpf and netfilter hunks, why
not replacing them with kvmalloc() and __GFP_NORETRY flag and add that
big fat FIXME comment above there, saying explicitly that __GFP_NORETRY
is not harmful though has only /partial/ effect right now and that full
support needs to be implemented in future. That would still be better
that not having it, imo, and the FIXME would make expectations clear
to anyone reading that code.
Well, we can do that, I just would like to prevent from this (ab)use
if there is no _real_ and _sensible_ usecase for it. Having a real bug
report or a fallback mechanism you are mentioning above would justify
the (ab)use IMHO. But that abuse would be documented properly and have a
real reason to exist. That sounds like a better approach to me.
But if you absolutely _insist_ I can change that.
Yeah, please do (with a big FIXME comment as mentioned), this originally
came from a real bug report. Anyway, feel free to add my Acked-by then.
Thanks! I will repost the whole series today.
Looks like I got only Cc'ed on the cover letter of your v3 from today
(should have been v4 actually?).
Anyway, I looked up the last patch
on lkml  and it seems you forgot the __GFP_NORETRY we talked about?
I misread your response. I thought you were OK with the FIXME
At least that was what was discussed above (insisting on __GFP_NORETRY
plus FIXME comment) for providing my Acked-by then. Can you still fix
that up in a final respin?
I will probably just drop that last patch instead. I am not convinced
that we should bend the new API over and let people mimic that
throughout the code. I have just seen too many examples of this pattern
I would also like to prevent the next rebase, unless there any issues
with some patches of course.