All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Max Gurtovoy <maxg@mellanox.com>,
	matanb@mellanox.com, leon@leon.nu, sagi@grimberg.me,
	linux-rdma@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] IB/core: Fix different types mix in ib_device_cap_flags structure values
Date: Tue, 31 May 2016 11:13:06 -0600	[thread overview]
Message-ID: <20160531171306.GA6618@obsidianresearch.com> (raw)
In-Reply-To: <08df9022-e575-da0d-c76d-a28185c9db2d@sandisk.com>

On Tue, May 31, 2016 at 08:35:10AM -0700, Bart Van Assche wrote:
> On 05/30/16 03:09, Max Gurtovoy wrote:
> >ib_device_cap_flags 64-bit expansion caused a possible caps overlapping
> >(depending on machine endianness) and made consumers read wrong device
> >capabilities. For example IB_DEVICE_SG_GAPS_REG was falsely read by the
> >iser driver causing it to use a non-existing capability. Fix this by
> >casting ib_device_cap_flags enumerations to ULL.
> >
> > [ ... ]
> >diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> >[ ... ]
> > enum ib_device_cap_flags {
> >       [ ... ]
> > 	IB_DEVICE_SG_GAPS_REG			= (1ULL << 32),
> >      [ ... ]
> > };
> 
> How can this patch make a difference? The presence of any constant
> in an enum that does not fit in a 32-bit integer makes an enum 64
> bits wide. In other words, all the changes from "1" into "1ULL" in
> this patch do not have

The expressions are evaluated before the enum type is decided, the
enum type has no impact on the type of the expressions.

(1<<32) is always undefined behavior because '1' is only a 32 bit type.

I'm confused why we didn't get any static checker hits on the shift
overflow - modern compilers warn on that??

Jason

  reply	other threads:[~2016-05-31 17:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 10:09 [PATCH] IB/core: Fix different types mix in ib_device_cap_flags structure values Max Gurtovoy
2016-05-31 15:36 ` Bart Van Assche
2016-05-31 15:36   ` Bart Van Assche
     [not found]   ` <4156c03f-4977-17eb-db64-6df775b6e592-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-05-31 19:14     ` Max Gurtovoy
2016-05-31 19:14       ` Max Gurtovoy
     [not found] ` <1464602994-21226-1-git-send-email-maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2016-05-31 15:35   ` Bart Van Assche
2016-05-31 15:35     ` Bart Van Assche
2016-05-31 17:13     ` Jason Gunthorpe [this message]
     [not found]       ` <20160531171306.GA6618-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-05-31 17:30         ` Leon Romanovsky
2016-05-31 17:30           ` Leon Romanovsky
     [not found]           ` <20160531173033.GC7477-2ukJVAZIZ/Y@public.gmane.org>
2016-05-31 18:05             ` Bart Van Assche
2016-05-31 18:05               ` Bart Van Assche
2016-05-31 18:12               ` Leon Romanovsky
     [not found]                 ` <20160531181223.GE7477-2ukJVAZIZ/Y@public.gmane.org>
2016-05-31 18:21                   ` Jason Gunthorpe
2016-05-31 18:21                     ` Jason Gunthorpe
     [not found]                     ` <20160531182100.GC21834-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-05-31 18:54                       ` Leon Romanovsky
2016-05-31 18:54                         ` Leon Romanovsky
2016-05-31 19:39                         ` Jason Gunthorpe
2016-06-01 12:04                           ` Max Gurtovoy
2016-06-01 12:04                             ` Max Gurtovoy
     [not found]                             ` <574ECF44.3070003-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2016-06-01 15:35                               ` Sagi Grimberg
2016-06-01 15:35                                 ` Sagi Grimberg
2016-05-31 18:43                   ` Bart Van Assche
2016-05-31 18:43                     ` Bart Van Assche
2016-05-31 18:16               ` Jason Gunthorpe
2016-05-31 19:16   ` Robert LeBlanc
2016-05-31 19:16     ` Robert LeBlanc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160531171306.GA6618@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=leon@leon.nu \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matanb@mellanox.com \
    --cc=maxg@mellanox.com \
    --cc=sagi@grimberg.me \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.