Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1511083 > unrolled thread

Re: [RFC v1 08/14] bus1: implement peer management context

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v1 08/14] bus1: implement peer management context Richard Weinberger <richard.weinberger@gmail.com> - 2016-10-28 14:10 +0200
    Re: [RFC v1 08/14] bus1: implement peer management context Tom Gundersen <teg@jklm.no> - 2016-10-28 15:20 +0200
      Re: [RFC v1 08/14] bus1: implement peer management context Richard Weinberger <richard@nod.at> - 2016-10-28 15:30 +0200

#1511083 — Re: [RFC v1 08/14] bus1: implement peer management context

David, Tom,

On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> +struct bus1_peer *bus1_peer_new(void)
> +{
> +       static atomic64_t peer_ids = ATOMIC64_INIT(0);
> +       const struct cred *cred = current_cred();
> +       struct bus1_peer *peer;
> +       struct bus1_user *user;
> +
> +       user = bus1_user_ref_by_uid(cred->uid);
> +       if (IS_ERR(user))
> +               return ERR_CAST(user);
> +
> +       peer = kmalloc(sizeof(*peer), GFP_KERNEL);
> +       if (!peer) {
> +               bus1_user_unref(user);
> +               return ERR_PTR(-ENOMEM);
> +       }
> +
> +       /* initialize constant fields */
> +       peer->id = atomic64_inc_return(&peer_ids);

What is the purpose of this id? Do other components depend on it
and are they aware of possible overflows?
Since it is an 64bit integer overflowing it is hard but not impossible.

-- 
Thanks,
//richard

[toc] | [next] | [standalone]

#1511124

On Fri, Oct 28, 2016 at 2:06 PM, Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> David, Tom,
>
> On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> +struct bus1_peer *bus1_peer_new(void)
>> +{
>> +       static atomic64_t peer_ids = ATOMIC64_INIT(0);
>> +       const struct cred *cred = current_cred();
>> +       struct bus1_peer *peer;
>> +       struct bus1_user *user;
>> +
>> +       user = bus1_user_ref_by_uid(cred->uid);
>> +       if (IS_ERR(user))
>> +               return ERR_CAST(user);
>> +
>> +       peer = kmalloc(sizeof(*peer), GFP_KERNEL);
>> +       if (!peer) {
>> +               bus1_user_unref(user);
>> +               return ERR_PTR(-ENOMEM);
>> +       }
>> +
>> +       /* initialize constant fields */
>> +       peer->id = atomic64_inc_return(&peer_ids);
>
> What is the purpose of this id? Do other components depend on it
> and are they aware of possible overflows?

The id is used purely to give a name to the peer in debugfs.

> Since it is an 64bit integer overflowing it is hard but not impossible.

Hm, what scenario do you have in mind? I cannot see how this could
happen (short of creating peers in a loop for hundreds of years).

Cheers,

Tom

[toc] | [prev] | [next] | [standalone]

#1511129

On 28.10.2016 15:18, Tom Gundersen wrote:
> On Fri, Oct 28, 2016 at 2:06 PM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>> David, Tom,
>>
>> On Wed, Oct 26, 2016 at 9:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> +struct bus1_peer *bus1_peer_new(void)
>>> +{
>>> +       static atomic64_t peer_ids = ATOMIC64_INIT(0);
>>> +       const struct cred *cred = current_cred();
>>> +       struct bus1_peer *peer;
>>> +       struct bus1_user *user;
>>> +
>>> +       user = bus1_user_ref_by_uid(cred->uid);
>>> +       if (IS_ERR(user))
>>> +               return ERR_CAST(user);
>>> +
>>> +       peer = kmalloc(sizeof(*peer), GFP_KERNEL);
>>> +       if (!peer) {
>>> +               bus1_user_unref(user);
>>> +               return ERR_PTR(-ENOMEM);
>>> +       }
>>> +
>>> +       /* initialize constant fields */
>>> +       peer->id = atomic64_inc_return(&peer_ids);
>>
>> What is the purpose of this id? Do other components depend on it
>> and are they aware of possible overflows?
> 
> The id is used purely to give a name to the peer in debugfs.

Okay.

>> Since it is an 64bit integer overflowing it is hard but not impossible.
> 
> Hm, what scenario do you have in mind? I cannot see how this could
> happen (short of creating peers in a loop for hundreds of years).

When it is purely for naming creating peers is slow enough it is no problem
at all. That's why I was asking.

Thanks,
//richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web