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: <bc64b4640906040751i3c64c317i4eedb7d53307092a@mail.gmail.com>
Date:	Thu, 4 Jun 2009 18:51:58 +0400
From:	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	sfr@...b.auug.org.au, slapin@...fans.org
Subject: Re: [PATCH 4/6] net: add NL802154 interface for configuration of 
	802.15.4 devices

2009/6/4 Johannes Berg <johannes@...solutions.net>:
> On Wed, 2009-06-03 at 16:27 +0400, Dmitry Eremin-Solenikov wrote:
>
>> > > +static int ieee802154_nl_put_failure(struct sk_buff *msg)
>> > > +{
>> > > + void *hdr = genlmsg_data(NLMSG_DATA(msg->data)); /* XXX: nlh is right at the start of msg */
>> > > + genlmsg_cancel(msg, hdr);
>> > > + nlmsg_free(msg);
>> > > + return -ENOBUFS;
>> > > +}
>> >
>> > This seems weird.
>>
>> Why?
>
> Because it's strange to cancel then free?

>From looking at the other code, the usual pattern for netlink is
(please, correct me if I'm wrong):

int fill (....)
{
   genlmsg_put();
   NLA_PUT(...)
   NLA_PUT(...)
   return genlmsg_end();

nla_put_failure:
   genlmsg_cancel();
   return -EMSGSIZE;
}

int cmd(...)
{
    int rc;
    nlmsg_new();

    rc = fill();
    if (rc < 0)
        goto out;

    genlmsg_unicast();

out:
    nlmsg_free();
    return -ENOBUFS;
}

This is equivalent to our code:

sk_buff *new()
{
   msg = nlmsg_new();
   genlmsg_put();
   return msg;
}

int finish()
{
    genlmsg_end();
    return genlmsg_unicast(); /*multicast in our case, but doesn't matter */
}

int cancel()
{
   genlmsg_cancel();
   nlmsg_free();
   return -ENOBUFS;
}

int cmd()
{
  msg = new();
  NLA_PUT()
  NLA_PUT();
  return finish();
nla_put_failure:
  return cancel();
}

>> > > +static int ieee802154_associate_req(struct sk_buff *skb, struct genl_info *info)
>> > > +{
>> > > + struct net_device *dev;
>> > > + struct ieee802154_addr addr;
>> > > + int ret = -EINVAL;
>> > > +
>> > > + if (!info->attrs[IEEE802154_ATTR_CHANNEL]
>> > > +  || !info->attrs[IEEE802154_ATTR_COORD_PAN_ID]
>> > > +  || (!info->attrs[IEEE802154_ATTR_COORD_HW_ADDR] && !info->attrs[IEEE802154_ATTR_COORD_SHORT_ADDR])
>> > > +  || !info->attrs[IEEE802154_ATTR_CAPABILITY])
>> > > +         return -EINVAL;
>> >
>> > That's some odd coding style.
>>
>> Could you please elaborate this? What seems odd to you?
>
> if (X
>    && Y)
>
> vs
>
> if (X &&
>    Y)
>
> where the latter is used for all other sources files in the kernel. Try
> applying that to _all_ your patches while you rework the sources to fit
> into 80 columns.

Fine, I'll apply the latter pattern and try to reformat code to fit to
80 columns.

-- 
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ