linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] ib_srpt: Make compilation with BUG=n proceed
@ 2011-11-17 19:25 Bart Van Assche
  2011-11-17 23:45 ` Roland Dreier
  0 siblings, 1 reply; 6+ messages in thread
From: Bart Van Assche @ 2011-11-17 19:25 UTC (permalink / raw)
  To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-next-u79uwXL29TY76Z2rM5mHXA, Nicholas Bellinger,
	Roland Dreier, Christoph Hellwig, Randy Dunlap, Stephen Rothwell

With CONFIG_BUG=n the __WARN() macro is not defined. Avoid that
building with CONFIG_BUG=n fails by replacing __WARN() with
WARN_ON(true). Also make sure that each such statement is preceeded
by an appropriate pr_err() statement.

Signed-off-by: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
Cc: Nicholas Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
Cc: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
Cc: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
---
 drivers/infiniband/ulp/srpt/ib_srpt.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 48b3e19..f09d483 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1464,9 +1464,9 @@ static void srpt_handle_rdma_comp(struct srpt_rdma_ch *ch,
 	} else if (opcode == SRPT_RDMA_ABORT) {
 		ioctx->rdma_aborted = true;
 	} else {
-		__WARN();
-		printk(KERN_ERR "%s[%d]: scmnd == NULL (opcode %d)", __func__,
-				__LINE__, opcode);
+		pr_err("%s[%d]: unexpected opcode %d", __func__, __LINE__,
+		       opcode);
+		WARN_ON(true);
 	}
 }
 
@@ -2737,7 +2737,9 @@ static void srpt_cm_dreq_recv(struct ib_cm_id *cm_id)
 		break;
 	case CH_DISCONNECTING:
 	case CH_DRAINING:
-		__WARN();
+		pr_err("%s[%d]: unexpected state %d\n", __func__, __LINE__,
+		       ch->state);
+		WARN_ON(true);
 		break;
 	}
 	spin_unlock_irqrestore(&ch->spinlock, flags);
@@ -2966,7 +2968,9 @@ static int srpt_write_pending(struct se_cmd *se_cmd)
 	switch (ch_state) {
 	case CH_CONNECTING:
 		/* This code should never be reached. */
-		__WARN();
+		pr_err("%s[%d]: unexpected state %d\n", __func__, __LINE__,
+		       ch_state);
+		WARN_ON(true);
 		ret = -EINVAL;
 		goto out;
 	case CH_LIVE:
@@ -3030,9 +3034,9 @@ static int srpt_queue_response(struct se_cmd *cmd)
 		ioctx->state = SRPT_STATE_MGMT_RSP_SENT;
 		break;
 	default:
-		printk(KERN_ERR "ch %p; cmd %d: unexpected command state %d\n",
+		pr_err("ch %p; cmd %d: unexpected command state %d\n",
 		       ch, ioctx->ioctx.index, ioctx->state);
-		__WARN();
+		WARN_ON(true);
 		break;
 	}
 	spin_unlock_irqrestore(&ioctx->spinlock, flags);
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] ib_srpt: Make compilation with BUG=n proceed
  2011-11-17 19:25 [PATCH] ib_srpt: Make compilation with BUG=n proceed Bart Van Assche
@ 2011-11-17 23:45 ` Roland Dreier
       [not found]   ` <CAL1RGDV+vgQ7J1VtyeGi-eNw00Bxe35xRJgBu0X4-5PAG4q-nQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Roland Dreier @ 2011-11-17 23:45 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: linux-rdma, linux-next, Nicholas Bellinger, Christoph Hellwig,
	Randy Dunlap, Stephen Rothwell

On Thu, Nov 17, 2011 at 11:25 AM, Bart Van Assche <bvanassche@acm.org> wrote:
> +               pr_err("%s[%d]: unexpected opcode %d", __func__, __LINE__,
> +                      opcode);
> +               WARN_ON(true);

Not a big deal, but I guess this could just be

        WARN(1, "unexpected opcode %d", opcode);

etc.

 - R.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ib_srpt: Make compilation with BUG=n proceed
       [not found]   ` <CAL1RGDV+vgQ7J1VtyeGi-eNw00Bxe35xRJgBu0X4-5PAG4q-nQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-11-18  7:52     ` Bart Van Assche
  2011-11-18 20:10       ` Roland Dreier
  0 siblings, 1 reply; 6+ messages in thread
From: Bart Van Assche @ 2011-11-18  7:52 UTC (permalink / raw)
  To: Roland Dreier
  Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Nicholas Bellinger,
	Christoph Hellwig, Randy Dunlap, Stephen Rothwell

On Fri, Nov 18, 2011 at 12:45 AM, Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org> wrote:
> On Thu, Nov 17, 2011 at 11:25 AM, Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
>> +               pr_err("%s[%d]: unexpected opcode %d", __func__, __LINE__,
>> +                      opcode);
>> +               WARN_ON(true);
>
> Not a big deal, but I guess this could just be
>
>        WARN(1, "unexpected opcode %d", opcode);

As far as I can see with CONFIG_BUG=n WARN() is defined as follows:

#define WARN(condition, format...) ({                                   \
        int __ret_warn_on = !!(condition);                              \
        unlikely(__ret_warn_on);                                        \
})

So the changing pr_err(); WARN_ON(true); into WARN(1, ...) would cause
no error message to be printed if CONFIG_BUG=n. Is that the way kernel
code should behave if CONFIG_BUG=n ?

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ib_srpt: Make compilation with BUG=n proceed
  2011-11-18  7:52     ` Bart Van Assche
@ 2011-11-18 20:10       ` Roland Dreier
  2011-11-19  9:11         ` Bart Van Assche
  0 siblings, 1 reply; 6+ messages in thread
From: Roland Dreier @ 2011-11-18 20:10 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: linux-rdma, linux-next, Nicholas Bellinger, Christoph Hellwig,
	Randy Dunlap, Stephen Rothwell

On Thu, Nov 17, 2011 at 11:52 PM, Bart Van Assche <bvanassche@acm.org> wrote:
> As far as I can see with CONFIG_BUG=n WARN() is defined as follows:
>
> #define WARN(condition, format...) ({                                   \
>        int __ret_warn_on = !!(condition);                              \
>        unlikely(__ret_warn_on);                                        \
> })
>
> So the changing pr_err(); WARN_ON(true); into WARN(1, ...) would cause
> no error message to be printed if CONFIG_BUG=n. Is that the way kernel
> code should behave if CONFIG_BUG=n ?

I don't know the code well enough to know what it *should* do ...
pretty much all WARN (or WARN_ON or __WARN) gives over a
printk is that it includes the backtrace.  Which might not be particularly
useful in this case.

So maybe pr_err() without WARN_ON is the best thing.  I was
just responding microlocally to the couple of lines here without
thinking through what output is actually useful.

What are these error messages for?  A "can never happen" bug
in the ib_srpt logic, or something that could be triggered by an
insane initiator sending a bogus sequence?

 - R.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] ib_srpt: Make compilation with BUG=n proceed
  2011-11-18 20:10       ` Roland Dreier
@ 2011-11-19  9:11         ` Bart Van Assche
  0 siblings, 0 replies; 6+ messages in thread
From: Bart Van Assche @ 2011-11-19  9:11 UTC (permalink / raw)
  To: Roland Dreier
  Cc: linux-rdma, linux-next, Nicholas Bellinger, Christoph Hellwig,
	Randy Dunlap, Stephen Rothwell

On Fri, Nov 18, 2011 at 9:10 PM, Roland Dreier <roland@purestorage.com> wrote:
> On Thu, Nov 17, 2011 at 11:52 PM, Bart Van Assche <bvanassche@acm.org> wrote:
> > As far as I can see with CONFIG_BUG=n WARN() is defined as follows:
> >
> > #define WARN(condition, format...) ({                                   \
> >        int __ret_warn_on = !!(condition);                              \
> >        unlikely(__ret_warn_on);                                        \
> > })
> >
> > So the changing pr_err(); WARN_ON(true); into WARN(1, ...) would cause
> > no error message to be printed if CONFIG_BUG=n. Is that the way kernel
> > code should behave if CONFIG_BUG=n ?
>
> I don't know the code well enough to know what it *should* do ...
> pretty much all WARN (or WARN_ON or __WARN) gives over a
> printk is that it includes the backtrace.  Which might not be particularly
> useful in this case.
>
> So maybe pr_err() without WARN_ON is the best thing.  I was
> just responding microlocally to the couple of lines here without
> thinking through what output is actually useful.

According to the description in init/Kconfig, BUG=n should only be
used on embedded systems with no facilities for error reporting. I do
not expect that anyone will miss the pr_err() output on such a system.

> What are these error messages for?  A "can never happen" bug
> in the ib_srpt logic, or something that could be triggered by an
> insane initiator sending a bogus sequence?

These messages are present in code paths that should never be reached,
no matter how the initiator or the IB network behaves. These messages
have been useful while making ib_srpt robust against IB cable pulling
- see e.g. http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg09664.html.

Bart.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] ib_srpt: Make compilation with BUG=n proceed
@ 2011-11-18 17:32 Bart Van Assche
  0 siblings, 0 replies; 6+ messages in thread
From: Bart Van Assche @ 2011-11-18 17:32 UTC (permalink / raw)
  To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-next-u79uwXL29TY76Z2rM5mHXA, Nicholas Bellinger,
	Roland Dreier, Christoph Hellwig, Randy Dunlap, Stephen Rothwell

With CONFIG_BUG=n the __WARN() macro is not defined. Avoid that
building with CONFIG_BUG=n fails by changing pr_err(...);
_WARN() into WARN(true, ...).

Signed-off-by: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
Cc: Nicholas Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
Cc: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
Cc: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
---
 drivers/infiniband/ulp/srpt/ib_srpt.c |   14 +++++---------
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 49ae767..6376e2a 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1462,9 +1462,7 @@ static void srpt_handle_rdma_comp(struct srpt_rdma_ch *ch,
 	} else if (opcode == SRPT_RDMA_ABORT) {
 		ioctx->rdma_aborted = true;
 	} else {
-		__WARN();
-		printk(KERN_ERR "%s[%d]: scmnd == NULL (opcode %d)", __func__,
-				__LINE__, opcode);
+		WARN(true, "unexpected opcode %d\n", opcode);
 	}
 }
 
@@ -2735,7 +2733,7 @@ static void srpt_cm_dreq_recv(struct ib_cm_id *cm_id)
 		break;
 	case CH_DISCONNECTING:
 	case CH_DRAINING:
-		__WARN();
+		WARN(true, "unexpected channel state %d\n", ch->state);
 		break;
 	}
 	spin_unlock_irqrestore(&ch->spinlock, flags);
@@ -2963,8 +2961,7 @@ static int srpt_write_pending(struct se_cmd *se_cmd)
 	ch_state = ch->state;
 	switch (ch_state) {
 	case CH_CONNECTING:
-		/* This code should never be reached. */
-		__WARN();
+		WARN(true, "unexpected channel state %d\n", ch_state);
 		ret = -EINVAL;
 		goto out;
 	case CH_LIVE:
@@ -3028,9 +3025,8 @@ static int srpt_queue_response(struct se_cmd *cmd)
 		ioctx->state = SRPT_STATE_MGMT_RSP_SENT;
 		break;
 	default:
-		printk(KERN_ERR "ch %p; cmd %d: unexpected command state %d\n",
-		       ch, ioctx->ioctx.index, ioctx->state);
-		__WARN();
+		WARN(true, "ch %p; cmd %d: unexpected command state %d\n",
+		     ch, ioctx->ioctx.index, ioctx->state);
 		break;
 	}
 	spin_unlock_irqrestore(&ioctx->spinlock, flags);
-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-11-19  9:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-17 19:25 [PATCH] ib_srpt: Make compilation with BUG=n proceed Bart Van Assche
2011-11-17 23:45 ` Roland Dreier
     [not found]   ` <CAL1RGDV+vgQ7J1VtyeGi-eNw00Bxe35xRJgBu0X4-5PAG4q-nQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-11-18  7:52     ` Bart Van Assche
2011-11-18 20:10       ` Roland Dreier
2011-11-19  9:11         ` Bart Van Assche
2011-11-18 17:32 Bart Van Assche

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).