Re: busy loops in kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Do you have any idea about the two for loops near the end of the message below? It seems strange that they would be included, unless I am completely overlooking something.


On Sat, 21 Jan 2012, Asim wrote:

Yeah - most of the busy waits that are correct are short and fairly
obvious while loops and there are plenty of them. There are some
complex ones too.

However, we do have false positive rate of 5- 8% (as measured on
2.6.18 kernel) - so in some (~100) cases for example the while loops
where variables may be re-used it may report the false positive. As
far as kernel timing is concerned - we do have mechanisms to account
for these based on our experience with the timers used in 2.6 kernel.
I will add these timing mechanisms and refresh the results - and
continue to update as I encounter more diverse mechanisms to account
for timing. But I strongly believe this a good subset to look at to
catch these problems.


On Sat, Jan 21, 2012 at 11:04 AM, Julia Lawall <julia.lawall@xxxxxxx> wrote:
I looked at this one:

ticks 2  Infinite Loop:228  Infinite Loop:600    CC [M]

Line 200 looks like what you described in your previous message.  I don't
understand the problem in line 600, though:

       while ((fifo_space >= 2) && (first || (i2c->nmsgs > 1))) {
               if (!first) {
                       i2c->tx_pos = 0;
               } else
                       first = 0;

               if (i2c->tx_msg->flags & I2C_M_RD) {
                       /* we dont date putting several reads in the FIFO */
               } else {
                       if (xiic_tx_space(i2c) != 0) {
                               /* the message could not be completely sent

               fifo_space = xiic_tx_fifo_space(i2c);

It looks like on every iteration execpt the first one, i2c->nmsgs is
decremented, so it will not long be greater than one.

The next two rely on kernel timing mechansims:

ticks 1  Infinite Loop:284    CC [M]  drivers/i2c/busses/i2c-eg20t.o
  while (ktime_lt(ktime_get(), ns_val))
ticks 1  Infinite Loop:84    CC [M]  drivers/i2c/busses/i2c-pca-isa.o
  ret = time_before(jiffies, timeout); ... while (ret)

Are these timing mechanisms unsafe?

In this case:

ticks 1  Infinite Loop:338    CC [M]  drivers/infiniband/hw/amso1100/c2.o

it looks like it is actually the outer loop, starting on line 336, that is

For this one:

ticks 1  Infinite Loop:47    CC [M]

I am not completely sure to understand the code.  c2dev->hints_read is
nonlocal and is never explicitly reset to 0.  Perhaps this code is only
executed once per instance of cdev.  In any case hints_read is incremented
on each iteration.  But perhaps the value of be16_to_cpu(*c2dev->hint_count)
can also change at each access?

This is clearly the sort of loop you described:

ticks 1  Infinite Loop:735    CC [M]  drivers/infiniband/hw/amso1100/c2_qp.o

Skipping ahead a bit, I don't at all see the problem in the following code:

ticks 1  Infinite Loop:184    CC [M]

       for (i = 0; i < size; i += 0x100) {
               if (readl(mem + i)      == 0x12345678 &&
                   readl(mem + i + 4)  == 0x34567812 &&
                   readl(mem + i + 8)  == 0x56781234 &&
                   readl(mem + i + 12) == 0x78123456) {
                       return (volatile struct ivtv_mailbox __iomem *)(mem +
i + 16);

I don't see the problem here either:

ticks 1  Infinite Loop:93    CC [M]

       for (tcnt = 0; tcnt < EEPROM_SIZE; tcnt += pcnt) {
               pcnt = 16;
               if (pcnt + tcnt > EEPROM_SIZE) pcnt = EEPROM_SIZE-tcnt;

The next report is on similar code:

ticks 1  Infinite Loop:3536    CC [M]

These two indeed might be dangerous:

ticks 2  Infinite Loop:481  Infinite Loop:676    CC [M]


[Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]     [Free Dating]

Add to Google Powered by Linux