Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751950AbbEFTAq (ORCPT ); Wed, 6 May 2015 15:00:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751740AbbEFTAp (ORCPT ); Wed, 6 May 2015 15:00:45 -0400 From: Denys Vlasenko To: Philipp Reisner Cc: Denys Vlasenko , Andreas Gruenbacher , Lars Ellenberg , Jens Axboe , drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org Subject: [PATCH] drbd: deinline __drbd_chk_io_error_() Date: Wed, 6 May 2015 21:00:21 +0200 Message-Id: <1430938821-6390-1-git-send-email-dvlasenk@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5875 Lines: 161 The function compiles to 552 bytes of machine code. On x86 allyesconfig build it has 8 callsites. Deinlining it shrinks kernel by more than 1k: text data bss dec hex filename 82433898 22255384 20627456 125316738 7782e82 vmlinux.before 82432426 22255384 20627456 125315266 77828c2 vmlinux Signed-off-by: Denys Vlasenko CC: Andreas Gruenbacher CC: Philipp Reisner CC: Lars Ellenberg CC: Jens Axboe CC: drbd-dev@lists.linbit.com CC: linux-kernel@vger.kernel.org --- drivers/block/drbd/drbd_int.h | 55 ++---------------------------------------- drivers/block/drbd/drbd_main.c | 55 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+), 53 deletions(-) diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h index b905e98..74a7afd 100644 --- a/drivers/block/drbd/drbd_int.h +++ b/drivers/block/drbd/drbd_int.h @@ -1727,60 +1727,9 @@ enum drbd_force_detach_flags { }; #define __drbd_chk_io_error(m,f) __drbd_chk_io_error_(m,f, __func__) -static inline void __drbd_chk_io_error_(struct drbd_device *device, +void __drbd_chk_io_error_(struct drbd_device *device, enum drbd_force_detach_flags df, - const char *where) -{ - enum drbd_io_error_p ep; - - rcu_read_lock(); - ep = rcu_dereference(device->ldev->disk_conf)->on_io_error; - rcu_read_unlock(); - switch (ep) { - case EP_PASS_ON: /* FIXME would this be better named "Ignore"? */ - if (df == DRBD_READ_ERROR || df == DRBD_WRITE_ERROR) { - if (__ratelimit(&drbd_ratelimit_state)) - drbd_err(device, "Local IO failed in %s.\n", where); - if (device->state.disk > D_INCONSISTENT) - _drbd_set_state(_NS(device, disk, D_INCONSISTENT), CS_HARD, NULL); - break; - } - /* NOTE fall through for DRBD_META_IO_ERROR or DRBD_FORCE_DETACH */ - case EP_DETACH: - case EP_CALL_HELPER: - /* Remember whether we saw a READ or WRITE error. - * - * Recovery of the affected area for WRITE failure is covered - * by the activity log. - * READ errors may fall outside that area though. Certain READ - * errors can be "healed" by writing good data to the affected - * blocks, which triggers block re-allocation in lower layers. - * - * If we can not write the bitmap after a READ error, - * we may need to trigger a full sync (see w_go_diskless()). - * - * Force-detach is not really an IO error, but rather a - * desperate measure to try to deal with a completely - * unresponsive lower level IO stack. - * Still it should be treated as a WRITE error. - * - * Meta IO error is always WRITE error: - * we read meta data only once during attach, - * which will fail in case of errors. - */ - set_bit(WAS_IO_ERROR, &device->flags); - if (df == DRBD_READ_ERROR) - set_bit(WAS_READ_ERROR, &device->flags); - if (df == DRBD_FORCE_DETACH) - set_bit(FORCE_DETACH, &device->flags); - if (device->state.disk > D_FAILED) { - _drbd_set_state(_NS(device, disk, D_FAILED), CS_HARD, NULL); - drbd_err(device, - "Local IO failed in %s. Detaching...\n", where); - } - break; - } -} + const char *where); /** * drbd_chk_io_error: Handle the on_io_error setting, should be called from all io completion handlers diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index 1fc8342..10f27e6 100644 --- a/drivers/block/drbd/drbd_main.c +++ b/drivers/block/drbd/drbd_main.c @@ -146,6 +146,61 @@ static const struct block_device_operations drbd_ops = { .release = drbd_release, }; +void __drbd_chk_io_error_(struct drbd_device *device, + enum drbd_force_detach_flags df, + const char *where) +{ + enum drbd_io_error_p ep; + + rcu_read_lock(); + ep = rcu_dereference(device->ldev->disk_conf)->on_io_error; + rcu_read_unlock(); + switch (ep) { + case EP_PASS_ON: /* FIXME would this be better named "Ignore"? */ + if (df == DRBD_READ_ERROR || df == DRBD_WRITE_ERROR) { + if (__ratelimit(&drbd_ratelimit_state)) + drbd_err(device, "Local IO failed in %s.\n", where); + if (device->state.disk > D_INCONSISTENT) + _drbd_set_state(_NS(device, disk, D_INCONSISTENT), CS_HARD, NULL); + break; + } + /* NOTE fall through for DRBD_META_IO_ERROR or DRBD_FORCE_DETACH */ + case EP_DETACH: + case EP_CALL_HELPER: + /* Remember whether we saw a READ or WRITE error. + * + * Recovery of the affected area for WRITE failure is covered + * by the activity log. + * READ errors may fall outside that area though. Certain READ + * errors can be "healed" by writing good data to the affected + * blocks, which triggers block re-allocation in lower layers. + * + * If we can not write the bitmap after a READ error, + * we may need to trigger a full sync (see w_go_diskless()). + * + * Force-detach is not really an IO error, but rather a + * desperate measure to try to deal with a completely + * unresponsive lower level IO stack. + * Still it should be treated as a WRITE error. + * + * Meta IO error is always WRITE error: + * we read meta data only once during attach, + * which will fail in case of errors. + */ + set_bit(WAS_IO_ERROR, &device->flags); + if (df == DRBD_READ_ERROR) + set_bit(WAS_READ_ERROR, &device->flags); + if (df == DRBD_FORCE_DETACH) + set_bit(FORCE_DETACH, &device->flags); + if (device->state.disk > D_FAILED) { + _drbd_set_state(_NS(device, disk, D_FAILED), CS_HARD, NULL); + drbd_err(device, + "Local IO failed in %s. Detaching...\n", where); + } + break; + } +} + struct bio *bio_alloc_drbd(gfp_t gfp_mask) { struct bio *bio; -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/