netdev - Re: [PATCH net-next 8/9] genetlink: use per-op policy for CTRL_CMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <131f3d344499ec58fa653a8d7c15e646ff8f98d0.camel@sipsolutions.net>
Date:   Thu, 01 Oct 2020 23:10:10 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, andrew@...n.ch,
        jiri@...nulli.us, mkubecek@...e.cz, dsahern@...nel.org,
        pablo@...filter.org
Subject: Re: [PATCH net-next 8/9] genetlink: use per-op policy for
 CTRL_CMD_GETPOLICY

On Thu, 2020-10-01 at 14:09 -0700, Jakub Kicinski wrote:
> On Thu, 01 Oct 2020 22:55:09 +0200 Johannes Berg wrote:
> > On Thu, 2020-10-01 at 11:30 -0700, Jakub Kicinski wrote:
> > > Wire up per-op policy for CTRL_CMD_GETPOLICY.
> > > This saves us a call to genlmsg_parse() and will soon allow
> > > dumping this policy.  
> > 
> > Hmm. Probably should've asked this before - I think the code makes
> > perfect sense, but I'm not sure how "this" follows?
> > 
> > I mean, we could've saved the genlmsg_parse() call before, with much the
> > same patch, having the per-op policy doesn't really have any bearing for
> > that? It was just using a different policy - the family one - instead of
> > the per-op one, but ...
> > 
> > Am I missing something?
> 
> Hm, not as far as I can tell, I was probably typing out the message
> fast cause the commit is kinda obivious.
> 
> Looking at the code again now I can't tell why it was calling
> genlmsg_parse() in the first place. LMK if you remember if there 
> was a reason.

Quite possibly it was just old code? I _think_, but didn't check now,
that the parsing for dumpit was added later. Hence the "don't parse"
validate flag, because it wasn't always done and thus would've accepted
any kind of junk as input ...

johannes