Re: busy loops in kernel

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


I looked at this one:

ticks 2 Infinite Loop:228 Infinite Loop:600 CC [M] drivers/i2c/busses/i2c-xiic.o

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->nmsgs--;
                        i2c->tx_msg++;
                        i2c->tx_pos = 0;
                } else
                        first = 0;

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

		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 unsafe.

For this one:

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

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]  drivers/media/video/ivtv/ivtv-firmware.o

        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]  drivers/media/video/pvrusb2/pvrusb2-eeprom.o

        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]  drivers/media/video/pvrusb2/pvrusb2-hdw.o

These two indeed might be dangerous:

ticks 2  Infinite Loop:481  Infinite Loop:676    CC [M]  drivers/media/video/saa7134/saa7134-tvaudio.o

julia
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[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