Re: BUG: Null pointer dereference in fs/open.c

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

 



On Mon, 23 Apr 2007, Andrew Morton wrote:

Try this:

--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
		rq->cmd_flags |= REQ_QUIET;

	blk_execute_rq(rq->q, pd->bdev->bd_disk, rq, 0);
-	ret = rq->errors;
+	if (rq->errors)
+		ret = -EIO;
out:
	blk_put_request(rq);
	return ret;
_


The packet driver was assuming that request.errors is an errno, but it
isn't - it's some sort of diagnostic bitfield thing.  Now why would the
packet driver have though that?  Let's go read the comments:
...
Well there's your root cause right there.

I don't know why this wasn't oopsing in eariler kernels.  Perhaps something
else is broken.  Please test this urgently.

The code used to return -EIO until commit 406c9b605cbc45151c03ac9a3f95e9acf050808c, which was commited 2007-01-05, so that would explain why older kernels didn't crash.

What the heck _is_ in request.errors?

According to linux/Documentation/block/request.txt, it is an error counter. The info in that text file would probably do a lot more good as comments in the structure definition though.

Should the packet driver even be looking at it?

I think so. How else is it supposed to know if the request failed?

--
Peter Osterlund - [email protected]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux