LinuxLists.cc - [GIT PULL] block drivers for 2.6.39-rc

2011-03-26 18:56:18

Subject: [GIT PULL] block drivers for 2.6.39-rc

Hi Linus,

This is the pull request for the block driver updates for 2.6.39. Two
things here:

- Big drbd update, as per usual...
- cciss update.

Please pull.

git://git.kernel.dk/linux-2.6-block.git for-2.6.39/drivers

Andreas Gruenbacher (22):
drbd: Removed an unnecessary #undef
drbd: Make sure that drbd_send() has sent the right number of bytes
drbd: Remove left-over prototype
drbd: Rename drbd_make_request_26 to drbd_make_request
drbd: Get rid of unnecessary macros (1)
drbd: Get rid of unnecessary macros (2)
drbd: Rename enum drbd_ret_codes to enum drbd_ret_code
drbd: Rename enum drbd_state_ret_codes to enum drbd_state_rv
drbd: Be more explicit about functions that return an enum drbd_state_rv
drbd: Another small enum drbd_state_rv cleanup
drbd: This code is dead now
drbd: Use the standard bool, true, and false keywords
drbd: drbd_nl_disk_conf: Avoid a compiler warning
drbd: receive_bitmap: Fix the wrong return value
drbd: receive_bitmap: Avoid casting enum drbd_state_rv to int
drbd: receive_bitmap: Missing free_page() on error path
drbd: send_bitmap_rle_or_plain: Get rid of ugly and useless enum
drbd: receive_bitmap_plain: Get rid of ugly and useless enum
drbd: Fix: drbd_bitmap_io does not return an enum determine_dev_size
drbd: Rename __inc_ap_bio_cond to may_inc_ap_bio
drbd: Remove useless / wrong comments
drbd: Remove unused function atodb_endio()

Bud Brown (1):
cciss: fix lost command issue

Jens Axboe (1):
Revert "cciss: Add missing allocation in scsi_cmd_stack_setup and corresponding deallocation"

Lars Ellenberg (49):
drbd: only reset online-verify start sector if verify completed
drbd: improve online-verify progress tracking
drbd: initialize online-verify progress tracking on verify target
drbd: factor out advancement of resync marks for progress reporting
drbd: advance progress step marks for online-verify
drbd: show progress bar and ETA for online-verify
drbd: factor out drbd_rs_controller_reset
drbd: factor out drbd_rs_number_requests
drbd: use the resync controller for online-verify requests as well
drbd: fix potential wrap of 32bit oos:%lu display in /proc/drbd
drbd: further converge progress display of resync and online-verify
drbd: detect modification of in-flight buffers
drbd: debug: limit nelink-broadcast of request on digest mismatch to 32k
drbd: properly use max_hw_sectors to limit the our bio size
drbd: restore compatibility with 32bit kernels
drbd: Renamed write_flags_to_bio() to wire_flags_to_bio()
drbd: increase module count on /proc/drbd access
drbd: remove /proc/drbd before unregistering from netlink
drbd: use kzalloc and memset(,0,) to start with clean buffers in drbd_nl
drbd: add packet_type 27 (return_code_only) to netlink api
drbd: fix regression, we need to close drbd epochs during normal operation
drbd: fix incomplete error message
drbd: bitmap: don't count unused bits (fix non-terminating resync)
drbd: store in-core bitmap little endian, regardless of architecture
drbd: bitmap keep track of changes vs on-disk bitmap
drbd: allow petabyte storage on 64bit arch
drbd: get rid of unused debug code
drbd: Removed a reference to debug macros removed long time ago
drbd: move bitmap write from resync_finished to after_state_change
drbd: fix potential dereference of NULL pointer
drbd: add debugging assert to make sure the protocol is clean
drbd: serialize sending of resync uuid with pending w_send_oos
drbd: be less noisy with some log messages
drbd: spelling fix in log message
drbd: improve on bitmap write out timing
drbd: fix potential access of on-stack wait_queue_head_t after return
drbd: ratelimit io error messages
drbd: only generate and send a new sync uuid after a successful state change
drbd: serialize admin requests for new resync with pending bitmap io
drbd: don't pointlessly queue bitmap send, if we lost connection
drbd: queue bitmap writeout more intelligently
drbd: log UUIDs whenever they change
drbd: describe bitmap locking for bulk operation in finer detail
drbd: silence some noisy log messages during disconnect
drbd: fix potential imbalance of ap_in_flight
drbd: serialize admin requests for new verify run with pending bitmap io
drbd: don't BUG_ON, if bio_add_page of a single page to an empty bio fails
drbd: kill dead code
drbd: improve log message if received sector offset exceeds local capacity

Or Gerlitz (1):
drbd: drop code present under #ifdef which is relevant to 2.6.28 and below

Philipp Reisner (40):
drbd: Track the numbers of sectors in flight
drbd: New configuration parameters for dealing with network congestion
drbd: Implemented two new connection states Ahead/Behind
drbd: New packet for Ahead/Behind mode: P_OUT_OF_SYNC
drbd: When proxy's buffer drained off go into regular resync mode
drbd: Do not cleanup resync LRU for the Ahead/Behind SyncSource/SyncTarget transitions
drbd: Implemented priority inheritance for resync requests
drbd: Make some functions static
drbd: Implemented side-stepping in drbd_res_begin_io()
drbd: Begin to account BIO processing time before inc_ap_bio()
drbd: use test_and_set_bit() to decide if bm_io_work should be queued
drbd: Fixed inc_ap_bio()
drbd: Fixed race condition in drbd_queue_bitmap_io
drbd: Improvements in sanitize_state()
drbd: Starting with protocol 96 we can allow app-IO while receiving the bitmap
drbd: Becoming sync target may not happen out of < C_WF_REPORT_PARAMS
drbd: Removed 20 seconds upper bound for side-stepping
drbd: --force option for disconnect
drbd: Implemented the before-resync-source handler
drbd: Documenting drbd_should_do_remote() and drbd_should_send_oos()
drbd: There might be a resync after unfreezing IO due to no disk [Bugz 332]
drbd: Fixed an issue with AHEAD -> SYNC_SOURCE transitions
drbd: No longer answer P_RS_DATA_REQUEST packets when in C_AHEAD mode
drbd: Be more careful with SyncSource -> Ahead transitions
drbd: Cleaned up the resync timer logic
drbd: Corrected off-by-one error in DRBD_MINOR_COUNT_MAX
drbd: Do not full sync if a P_SYNC_UUID packet gets lost
drbd: Nothing should stop SyncSource -> Ahead transitions
drbd: Work on the Ahead -> SyncSource transition
drbd: Do not drop net config if sending in drbd_send_protocol() fails
drbd: Killed an assert that is no longer valid
drbd: Fixed P_NEG_ACK processing for protocol A and B
drbd: Ensure that an epoch contains only requests of one kind
drbd: cleaned up __set_current_state() followed by schedule_timeout() calls
drbd: Provide hints with the error message when clearing the sync pause flag
drbd: We can not process BIOs with a size of 0
drbd: Removed left over, now wrong comments
drbd: Implemented real timeout checking for request processing time
drbd: Fixed handling of read errors on a 'VerifyT' node
drbd: Fixed handling of read errors on a 'VerifyS' node

Stephen M. Cameron (7):
cciss: export resettable host attribute
cciss: Add missing allocation in scsi_cmd_stack_setup and corresponding deallocation
cciss: hoist tag masking out of loop
cciss: Inform controller we are using 32-bit tags.
cciss: Mask off error bits of c->busaddr in cmd_special_free when calling pci_free_consistent
cciss: remove unnecessary casts
cciss: fix missed command status value CMD_UNABORTABLE

Stephen Rothwell (1):
drbd: need include for bitops functions declarations

.../ABI/testing/sysfs-bus-pci-devices-cciss | 12 +
drivers/block/cciss.c | 86 ++-
drivers/block/cciss.h | 1 +
drivers/block/cciss_cmd.h | 1 +
drivers/block/cciss_scsi.c | 13 +-
drivers/block/drbd/drbd_actlog.c | 335 +++-------
drivers/block/drbd/drbd_bitmap.c | 752 +++++++++++++-------
drivers/block/drbd/drbd_int.h | 270 +++++---
drivers/block/drbd/drbd_main.c | 673 ++++++++++++------
drivers/block/drbd/drbd_nl.c | 183 ++++--
drivers/block/drbd/drbd_proc.c | 114 +++-
drivers/block/drbd/drbd_receiver.c | 608 ++++++++++------
drivers/block/drbd/drbd_req.c | 169 ++++-
drivers/block/drbd/drbd_req.h | 36 +-
drivers/block/drbd/drbd_strings.c | 6 +-
drivers/block/drbd/drbd_worker.c | 360 +++++-----
drivers/block/drbd/drbd_wrappers.h | 2 +-
include/linux/drbd.h | 23 +-
include/linux/drbd_limits.h | 12 +-
include/linux/drbd_nl.h | 13 +-
include/linux/drbd_tag_magic.h | 1 +
21 files changed, 2267 insertions(+), 1403 deletions(-)

--
Jens Axboe

2011-03-28 04:23:21

(No filename) (285.98 kB)
config (58.82 kB)
Download all attachments

2011-03-29 11:38:39

by Jens Axboe

[permalink] [raw]

Subject: Re: [sporadic crash] blk: request botched

On 2011-03-29 13:17, Ingo Molnar wrote:
>
> FYI, i'm seeing a new block IO related boot failure. It starts by the kernel spewing:
>
> [ 84.434778] blk: request botched
> [ 84.437546] blk: request botched
> [ 84.441532] blk: request botched
>
> And after more dying noises, a colorful kernel crash in an apparently rarely
> excercised error handler:

I don't think it's the error handler being broken, it simply looks like
a request that is in a bad bad state thus causing the normal rq -> bio
-> bvec run through to bomb out.

So the 'request botched' is the real BUG here.

Is that part reproducible? If so, can you please try with this patch?

diff --git a/block/blk-core.c b/block/blk-core.c
index e0a0623..3045d0e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2163,7 +2163,8 @@ bool blk_update_request(struct request *req, int error, unsigned int nr_bytes)
* size, something has gone terribly wrong.
*/
if (blk_rq_bytes(req) < blk_rq_cur_bytes(req)) {
- printk(KERN_ERR "blk: request botched\n");
+ blk_dump_rq_flags(req, "request botched");
+ WARN_ON(1);
req->__data_len = blk_rq_cur_bytes(req);
}

--
Jens Axboe

2011-03-29 13:18:27

by Stephen M. Cameron

[permalink] [raw]

Subject: Re: [GIT PULL] block drivers for 2.6.39-rc

On Tue, Mar 29, 2011 at 08:34:02AM +0200, Jens Axboe wrote:
> On 2011-03-29 01:06, Linus Torvalds wrote:
> > On Sat, Mar 26, 2011 at 11:56 AM, Jens Axboe <[email protected]> wrote:
> >> Hi Linus,
> >>
> >> This is the pull request for the block driver updates for 2.6.39. Two
> >> things here:
> >>
> >> - Big drbd update, as per usual...
> >> - cciss update.
> >
> > Btw, that cciss thing causes a very annoying compiler warning:
> >
> > drivers/block/cciss.c: In function ‘dev_show_unique_id’:
> > drivers/block/cciss.c:617:7: warning: ‘sn[0]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[1]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[2]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[3]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[4]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[5]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[6]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[7]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[8]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[9]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[10]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[11]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[12]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[13]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[14]’ may be used
> > uninitialized in this function
> > drivers/block/cciss.c:617:7: warning: ‘sn[15]’ may be used
> > uninitialized in this function
> >
> > which is because the compiler doesn't really notice that those things
> > are only used if the error return isn't being set.
> >
> > So it's a compiler mis-feature, but the thing is, the warning could
> > easily be avoided by just writing the code more prettily.
> >
> > Just do the memcpy() unconditionally: we know that 'drv' is a valid
> > pointer (we just loaded 'h' off it), and we're talking about a nice
> > constant 16-byte copy.
> >
> > IOW, a patch something like the attached.
> >
> > Untested, but it looks really obvious. Hmm?
>
> Looks good to me. I'm curious, you get a warning in dev_show_unique_id()
> but not in dev_show_vendor() or any of the other following 4-5 functions
> written in the same style?
>
> My gcc here does not warn for any of them. But it is very convoluted for
> what it does

Looks ok to me.

FWIW, I've also not seen warnings for any of those from gcc on several
distros (rhel5, rhel6, sles10, sles11).

The convolutedness was probably just me trying to be overly economical
though that "else" after the return and just before the snprintf is
kinda nuts.

-- steve