* qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
@ 2015-05-12 18:42 Joe Perches
2015-05-13 13:19 ` Dan Carpenter
0 siblings, 1 reply; 6+ messages in thread
From: Joe Perches @ 2015-05-12 18:42 UTC (permalink / raw)
To: Jitendra Kalsaria, Ron Mercer, linux-driver; +Cc: netdev, Dan Carpenter
In ql_reset_work (line 3620)
The ql_reset_work function uses an "or" of 2 enum values.
enum { QL_RESET_DONE = 1, /* Reset finished. */
QL_RESET_ACTIVE = 2, /* Waiting for reset to finish. */
QL_RESET_START = 3, /* Please reset the chip. */
QL_RESET_PER_SCSI = 4, /* SCSI driver requests reset. */
QL_TX_TIMEOUT = 5, /* Timeout in progress. */
QL_LINK_MASTER = 6, /* This driver controls the link. */
QL_ADAPTER_UP = 7, /* Adapter has been brought up. */
The values (3 and 4) or'd (added) together are
QL_ADAPTER_UP
If that's really what's desired, it'd be better to use
QL_ADAPTER_UP directly, though I'd expect this should
test both bits independently instead.
---
static void ql_reset_work(struct work_struct *work)
{
struct ql3_adapter *qdev =
container_of(work, struct ql3_adapter, reset_work.work);
struct net_device *ndev = qdev->ndev;
u32 value;
struct ql_tx_buf_cb *tx_cb;
int max_wait_time, i;
struct ql3xxx_port_registers __iomem *port_regs =
qdev->mem_map_registers;
unsigned long hw_flags;
if (test_bit((QL_RESET_PER_SCSI | QL_RESET_START), &qdev->flags)) {
clear_bit(QL_LINK_MASTER, &qdev->flags);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
2015-05-12 18:42 qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c Joe Perches
@ 2015-05-13 13:19 ` Dan Carpenter
2015-05-13 16:08 ` Joe Perches
2015-05-13 17:34 ` Joe Perches
0 siblings, 2 replies; 6+ messages in thread
From: Dan Carpenter @ 2015-05-13 13:19 UTC (permalink / raw)
To: Joe Perches; +Cc: Jitendra Kalsaria, Ron Mercer, linux-driver, netdev
Good eye, Joe.
I wrote a Smatch check to find similar bugs. They weren't any other
places which tried to do bitwise OR. The bug that happens occasionally
is:
#define MY_FLAG BIT(1)
if (test_bit(MY_FLAG, &map)) {
...
It's not normally harmful if it's used consistently, but ath9k had
memory corruption because they do:
set_bit(BIT(6), &some_unsigned_long);
Anyway, I'll send patches for the bugs I found and push the Smatch
check. Thanks!
regards,
dan carpenter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
2015-05-13 13:19 ` Dan Carpenter
@ 2015-05-13 16:08 ` Joe Perches
2015-05-13 17:34 ` Joe Perches
1 sibling, 0 replies; 6+ messages in thread
From: Joe Perches @ 2015-05-13 16:08 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Ron Mercer, linux-driver, netdev
On Wed, 2015-05-13 at 16:19 +0300, Dan Carpenter wrote:
> I wrote a Smatch check to find similar bugs.
Nice.
It didn't look like something coccinelle could do and
I didn't know smatch syntax well enough (OK, I don't
know smatch syntax at all), to write something to find
these defects but I thought, if anyone, you could.
Thanks Dan for doing it.
> ath9k had memory corruption because they do:
> set_bit(BIT(6), &some_unsigned_long);
> Anyway, I'll send patches for the bugs I found and push the Smatch
> check.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
2015-05-13 13:19 ` Dan Carpenter
2015-05-13 16:08 ` Joe Perches
@ 2015-05-13 17:34 ` Joe Perches
2015-05-14 8:01 ` Dan Carpenter
1 sibling, 1 reply; 6+ messages in thread
From: Joe Perches @ 2015-05-13 17:34 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Ron Mercer, linux-driver, netdev
On Wed, 2015-05-13 at 16:19 +0300, Dan Carpenter wrote:
> Good eye, Joe.
>
> I wrote a Smatch check to find similar bugs. Te rhey weren't any other
> places which tried to do bitwise OR. The bug that happens occasionally
> is:
>
> #define MY_FLAG BIT(1)
>
> if (test_bit(MY_FLAG, &map)) {
> ...
>
> It's not normally harmful if it's used consistently, but ath9k had
> memory corruption because they do:
>
> set_bit(BIT(6), &some_unsigned_long);
>
> Anyway, I'll send patches for the bugs I found and push the Smatch
> check. Thanks!
In case the patches you found weren't of this type,
there are other possibly suspicious uses with & like:
drivers/usb/host/ehci-tegra.c: set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
2015-05-13 17:34 ` Joe Perches
@ 2015-05-14 8:01 ` Dan Carpenter
2015-05-14 8:22 ` Joe Perches
0 siblings, 1 reply; 6+ messages in thread
From: Dan Carpenter @ 2015-05-14 8:01 UTC (permalink / raw)
To: Joe Perches; +Cc: Ron Mercer, linux-driver, netdev
On Wed, May 13, 2015 at 10:34:51AM -0700, Joe Perches wrote:
> On Wed, 2015-05-13 at 16:19 +0300, Dan Carpenter wrote:
> > Good eye, Joe.
> >
> > I wrote a Smatch check to find similar bugs. Te rhey weren't any other
> > places which tried to do bitwise OR. The bug that happens occasionally
> > is:
> >
> > #define MY_FLAG BIT(1)
> >
> > if (test_bit(MY_FLAG, &map)) {
> > ...
> >
> > It's not normally harmful if it's used consistently, but ath9k had
> > memory corruption because they do:
> >
> > set_bit(BIT(6), &some_unsigned_long);
> >
> > Anyway, I'll send patches for the bugs I found and push the Smatch
> > check. Thanks!
>
> In case the patches you found weren't of this type,
> there are other possibly suspicious uses with & like:
>
> drivers/usb/host/ehci-tegra.c: set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
>
That's puzzling, yes, but my instinct without looking at the context is
that it's probably valid. I didn't look at that that one, but I looked
at a bunch of similar cases.
My test only looked at test_bit(). I'll update it to look at set_bit()
and clear_bit() as well. It only complains about "test_bit(x | y, " and
"test_bit(x < y, ".
Btw, Smatch already has a check for when people do:
set_bit(FOO_BIT, &flags);
...
if (flags & FOO_BIT) {
It looks uses the macro names, so if you open code it then it won't
catch the inconsistency, but mostly it works.
regards,
dan carpenter
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c
2015-05-14 8:01 ` Dan Carpenter
@ 2015-05-14 8:22 ` Joe Perches
0 siblings, 0 replies; 6+ messages in thread
From: Joe Perches @ 2015-05-14 8:22 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Ron Mercer, linux-driver, netdev
On Thu, 2015-05-14 at 11:01 +0300, Dan Carpenter wrote:
> On Wed, May 13, 2015 at 10:34:51AM -0700, Joe Perches wrote:
> > In case the patches you found weren't of this type,
> > there are other possibly suspicious uses with & like:
> > drivers/usb/host/ehci-tegra.c: set_bit((wIndex & 0xff) - 1, &ehci->suspended_ports);
> That's puzzling, yes, but my instinct without looking at the context is
> that it's probably valid.
It may be valid, but at a minimum it's bad code.
Assuming wIndex is guaranteed non-zero, it likely
should be something like:
(wIndex % BITS_PER_LONG) - 1
or suspended_ports should be more than a single ulong
Anyway, thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-05-14 8:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-12 18:42 qla3xxx: Odd likely incorrect use of test_bit in qla3xxx.c Joe Perches
2015-05-13 13:19 ` Dan Carpenter
2015-05-13 16:08 ` Joe Perches
2015-05-13 17:34 ` Joe Perches
2015-05-14 8:01 ` Dan Carpenter
2015-05-14 8:22 ` Joe Perches
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.