linux-toradex.git/block, branch v2.6.34.11

block, blk-sysfs: Fix an err return path in blk_register_queue()

2012-03-14T14:57:21+00:00

commit ed5302d3c25006a9edc7a7fbea97a30483f89ef7 upstream.

We do not call blk_trace_remove_sysfs() in err return path
if kobject_add() fails. This path fixes it.

Signed-off-by: Liu Yuan 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

block: check for proper length of iov entries earlier in blk_rq_map_user_iov()

2011-04-17T20:16:17+00:00

commit 5478755616ae2ef1ce144dded589b62b2a50d575 upstream.

commit 9284bcf checks for proper length of iov entries in
blk_rq_map_user_iov(). But if the map is unaligned, kernel
will break out the loop without checking for the proper length.
So we need to check the proper length before the unalign check.

Signed-off-by: Xiaotian Feng 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead

2011-04-17T20:16:14+00:00

commit e692cb668fdd5a712c6ed2a2d6f2a36ee83997b4 upstream.

When stacking devices, a request_queue is not always available. This
forced us to have a no_cluster flag in the queue_limits that could be
used as a carrier until the request_queue had been set up for a
metadevice.

There were several problems with that approach. First of all it was up
to the stacking device to remember to set queue flag after stacking had
completed. Also, the queue flag and the queue limits had to be kept in
sync at all times. We got that wrong, which could lead to us issuing
commands that went beyond the max scatterlist limit set by the driver.

The proper fix is to avoid having two flags for tracking the same thing.
We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
block layer merging functions. The queue_limit 'no_cluster' is turned
into 'cluster' to avoid double negatives and to ease stacking.
Clustering defaults to being enabled as before. The queue flag logic is
removed from the stacking function, and explicitly setting the cluster
flag is no longer necessary in DM and MD.

Reported-by: Ed Lin 
Signed-off-by: Martin K. Petersen 
Acked-by: Mike Snitzer 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

block: check for proper length of iov entries in blk_rq_map_user_iov()

2011-04-17T20:15:36+00:00

commit 9284bcf4e335e5f18a8bc7b26461c33ab60d0689 upstream.

Ensure that we pass down properly validated iov segments before
calling into the mapping or copy functions.

Reported-by: Dan Rosenberg 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

block: take care not to overflow when calculating total iov length

2011-04-17T20:15:35+00:00

commit 9f864c80913467312c7b8690e41fb5ebd1b50e92 upstream.

Reported-by: Dan Rosenberg 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

block: Ensure physical block size is unsigned int

2011-04-17T20:15:35+00:00

commit 892b6f90db81cccb723d5d92f4fddc2d68b206e1 upstream.

Physical block size was declared unsigned int to accomodate the maximum
size reported by READ CAPACITY(16).  Make sure we use the right type in
the related functions.

Signed-off-by: Martin K. Petersen 
Acked-by: Mike Snitzer 
Signed-off-by: Jens Axboe 
Signed-off-by: Paul Gortmaker

bsg: fix incorrect device_status value

2011-01-06T23:08:15+00:00

commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream.

bsg incorrectly returns sg's masked_status value for device_status.

[jejb: fix up expression logic]
Reported-by: Douglas Gilbert 
Signed-off-by: FUJITA Tomonori 
Signed-off-by: James Bottomley 
Signed-off-by: Paul Gortmaker

block: Don't count_vm_events for discard bio in submit_bio.

2010-08-02T17:30:18+00:00

commit 1b99973f1c82707e46e8cb9416865a1e955e8f8c upstream.

In submit_bio, we count vm events by check READ/WRITE.
But actually DISCARD_NOBARRIER also has the WRITE flag set.
It looks as if in blkdev_issue_discard, we also add a
page as the payload and the bio_has_data check isn't enough.
So add another check for discard bio.

Signed-off-by: Tao Ma 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

cfq: Don't allow queue merges for queues that have no process references

2010-08-02T17:29:47+00:00

commit c10b61f0910466b4b99c266a7d76ac4390743fb5 upstream.

Hi,

A user reported a kernel bug when running a particular program that did
the following:

created 32 threads
- each thread took a mutex, grabbed a global offset, added a buffer size
  to that offset, released the lock
- read from the given offset in the file
- created a new thread to do the same
- exited

The result is that cfq's close cooperator logic would trigger, as the
threads were issuing I/O within the mean seek distance of one another.
This workload managed to routinely trigger a use after free bug when
walking the list of merge candidates for a particular cfqq
(cfqq->new_cfqq).  The logic used for merging queues looks like this:

static void cfq_setup_merge(struct cfq_queue *cfqq, struct cfq_queue *new_cfqq)
{
	int process_refs, new_process_refs;
	struct cfq_queue *__cfqq;

	/* Avoid a circular list and skip interim queue merges */
	while ((__cfqq = new_cfqq->new_cfqq)) {
		if (__cfqq == cfqq)
			return;
		new_cfqq = __cfqq;
	}

	process_refs = cfqq_process_refs(cfqq);
	/*
	 * If the process for the cfqq has gone away, there is no
	 * sense in merging the queues.
	 */
	if (process_refs == 0)
		return;

	/*
	 * Merge in the direction of the lesser amount of work.
	 */
	new_process_refs = cfqq_process_refs(new_cfqq);
	if (new_process_refs >= process_refs) {
		cfqq->new_cfqq = new_cfqq;
		atomic_add(process_refs, &new_cfqq->ref);
	} else {
		new_cfqq->new_cfqq = cfqq;
		atomic_add(new_process_refs, &cfqq->ref);
	}
}

When a merge candidate is found, we add the process references for the
queue with less references to the queue with more.  The actual merging
of queues happens when a new request is issued for a given cfqq.  In the
case of the test program, it only does a single pread call to read in
1MB, so the actual merge never happens.

Normally, this is fine, as when the queue exits, we simply drop the
references we took on the other cfqqs in the merge chain:

	/*
	 * If this queue was scheduled to merge with another queue, be
	 * sure to drop the reference taken on that queue (and others in
	 * the merge chain).  See cfq_setup_merge and cfq_merge_cfqqs.
	 */
	__cfqq = cfqq->new_cfqq;
	while (__cfqq) {
		if (__cfqq == cfqq) {
			WARN(1, "cfqq->new_cfqq loop detected\n");
			break;
		}
		next = __cfqq->new_cfqq;
		cfq_put_queue(__cfqq);
		__cfqq = next;
	}

However, there is a hole in this logic.  Consider the following (and
keep in mind that each I/O keeps a reference to the cfqq):

q1->new_cfqq = q2   // q2 now has 2 process references
q3->new_cfqq = q2   // q2 now has 3 process references

// the process associated with q2 exits
// q2 now has 2 process references

// queue 1 exits, drops its reference on q2
// q2 now has 1 process reference

// q3 exits, so has 0 process references, and hence drops its references
// to q2, which leaves q2 also with 0 process references

q4 comes along and wants to merge with q3

q3->new_cfqq still points at q2!  We follow that link and end up at an
already freed cfqq.

So, the fix is to not follow a merge chain if the top-most queue does
not have a process reference, otherwise any queue in the chain could be
already freed.  I also changed the logic to disallow merging with a
queue that does not have any process references.  Previously, we did
this check for one of the merge candidates, but not the other.  That
doesn't really make sense.

Without the attached patch, my system would BUG within a couple of
seconds of running the reproducer program.  With the patch applied, my
system ran the program for over an hour without issues.

This addresses the following bugzilla:
    https://bugzilla.kernel.org/show_bug.cgi?id=16217

Thanks a ton to Phil Carns for providing the bug report and an excellent
reproducer.

[ Note for stable: this applies to 2.6.32/33/34 ].

Signed-off-by: Jeff Moyer 
Reported-by: Phil Carns 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

cfq-iosched: fix an oops caused by slab leak

2010-07-05T18:22:50+00:00

commit d02a2c077fb81f3224c770be62a318165b23b486 upstream.

I got below oops when unloading cfq-iosched. Considering scenario:
queue A merge to B, C merge to D and B will be merged to D. Before B is merged
to D, we do split B. We should put B's reference for D.

[  807.768536] =============================================================================
[  807.768539] BUG cfq_queue: Objects remaining on kmem_cache_close()
[  807.768541] -----------------------------------------------------------------------------
[  807.768543]
[  807.768546] INFO: Slab 0xffffea0003e6b4e0 objects=26 used=1 fp=0xffff88011d584fd8 flags=0x200000000004082
[  807.768550] Pid: 5946, comm: rmmod Tainted: G        W   2.6.34-07097-gf4b87de-dirty #724
[  807.768552] Call Trace:
[  807.768560]  [] slab_err+0x8f/0x9d
[  807.768564]  [] ? flush_cpu_slab+0x0/0x93
[  807.768569]  [] ? add_preempt_count+0xe/0xca
[  807.768572]  [] ? sub_preempt_count+0xe/0xb6
[  807.768577]  [] ? _raw_spin_unlock+0x15/0x30
[  807.768580]  [] ? sub_preempt_count+0xe/0xb6
[  807.768584]  [] list_slab_objects+0x9b/0x19f
[  807.768588]  [] ? add_preempt_count+0xc6/0xca
[  807.768591]  [] kmem_cache_destroy+0x13f/0x21d
[  807.768597]  [] cfq_slab_kill+0x1a/0x43 [cfq_iosched]
[  807.768601]  [] cfq_exit+0x93/0x9e [cfq_iosched]
[  807.768606]  [] sys_delete_module+0x1b1/0x219
[  807.768612]  [] system_call_fastpath+0x16/0x1b
[  807.768618] INFO: Object 0xffff88011d584618 @offset=1560
[  807.768622] INFO: Allocated in cfq_get_queue+0x11e/0x274 [cfq_iosched] age=7173 cpu=1 pid=5496
[  807.768626] =============================================================================

Signed-off-by: Shaohua Li 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman