[PATCH][RESEND] zlib : Fix usage example of zlib_adler32()

[Anish Bhatt]

alder32 was renamed to zlib_adler32 since before 2.6.11, update
the example accordingly. This code does not seem to have an
assigned maintainer.

Signed-off-by: Anish Bhatt 
---
 include/linux/zutil.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/zutil.h b/include/linux/zutil.h
index 6adfa9a..6636895 100644
--- a/include/linux/zutil.h
+++ b/include/linux/zutil.h
@@ -68,10 +68,10 @@ typedef uLong (*check_func) (uLong check, const Byte *buf,
An Adler-32 checksum is almost as reliable as a CRC32 but can be computed
much faster. Usage example:
 
- uLong adler = adler32(0L, NULL, 0);
+ uLong adler = zlib_adler32(0L, NULL, 0);
 
  while (read_buffer(buffer, length) != EOF) {
-   adler = adler32(adler, buffer, length);
+   adler = zlib_adler32(adler, buffer, length);
  }
  if (adler != original_adler) error();
 */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RESEND] zlib : Fix usage example of zlib_adler32()

[Anish Bhatt]

On Mon, Oct 5, 2015 at 1:27 PM, Andrew Morton  wrote:
> On Mon,  5 Oct 2015 13:23:58 -0700 Anish Bhatt  wrote:
>
>> alder32 was renamed to zlib_adler32 since before 2.6.11, update
>> the example accordingly. This code does not seem to have an
>> assigned maintainer.
>>
>> ...
>>
>> --- a/include/linux/zutil.h
>> +++ b/include/linux/zutil.h
>> @@ -68,10 +68,10 @@ typedef uLong (*check_func) (uLong check, const Byte 
>> *buf,
>> An Adler-32 checksum is almost as reliable as a CRC32 but can be computed
>> much faster. Usage example:
>>
>> - uLong adler = adler32(0L, NULL, 0);
>> + uLong adler = zlib_adler32(0L, NULL, 0);
>>
>>   while (read_buffer(buffer, length) != EOF) {
>> -   adler = adler32(adler, buffer, length);
>> +   adler = zlib_adler32(adler, buffer, length);
>>   }
>>   if (adler != original_adler) error();
>>  */
>
> I applied this September 15.  You should have received the commit
> email on that date.  I'm not a spammer, honest.

That is weird, I don't see a notification in the spam folder either, but I do
see that the code has changed. Sorry about the noise.

-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] zlib : Fix usage example of zlib_adler32()

[Anish Bhatt]

Signed-off-by: Anish Bhatt 
---
 include/linux/zutil.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/zutil.h b/include/linux/zutil.h
index 6adfa9a..6636895 100644
--- a/include/linux/zutil.h
+++ b/include/linux/zutil.h
@@ -68,10 +68,10 @@ typedef uLong (*check_func) (uLong check, const Byte *buf,
An Adler-32 checksum is almost as reliable as a CRC32 but can be computed
much faster. Usage example:
 
- uLong adler = adler32(0L, NULL, 0);
+ uLong adler = zlib_adler32(0L, NULL, 0);
 
  while (read_buffer(buffer, length) != EOF) {
-   adler = adler32(adler, buffer, length);
+   adler = zlib_adler32(adler, buffer, length);
  }
  if (adler != original_adler) error();
 */
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][RESEND] zlib : Fix usage example of zlib_adler32()

[Anish Bhatt]

alder32 was renamed to zlib_adler32 since before 2.6.11, this code
does not seem to have an assigned maintainer.

Signed-off-by: Anish Bhatt 
---
 include/linux/zutil.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/zutil.h b/include/linux/zutil.h
index 6adfa9a..6636895 100644
--- a/include/linux/zutil.h
+++ b/include/linux/zutil.h
@@ -68,10 +68,10 @@ typedef uLong (*check_func) (uLong check, const Byte *buf,
An Adler-32 checksum is almost as reliable as a CRC32 but can be computed
much faster. Usage example:
 
- uLong adler = adler32(0L, NULL, 0);
+ uLong adler = zlib_adler32(0L, NULL, 0);
 
  while (read_buffer(buffer, length) != EOF) {
-   adler = adler32(adler, buffer, length);
+   adler = zlib_adler32(adler, buffer, length);
  }
  if (adler != original_adler) error();
 */
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] csiostor:Fix locking issues in the function csio_scsim_cleanup_io_lnode

[Anish Bhatt]

> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, September 2, 2015 10:36 AM
> To: jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish
> Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] csiostor:Fix locking issues in the function
> csio_scsim_cleanup_io_lnode
> 
> This fixes locking issues in the function csio_scsim_cleanup_io_lnode by
> locking around the call to the function csio_csci_gather_active_ios with the
> function pair spin_lock_irq/spin_unlock_irq as any function calling this
> particular function must do in order to avoid concurrent threads of execution
> on the passed structure pointer of type csio_hw as this structure pointer can
> be shared across mutliple threads in the kernel.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/scsi/csiostor/csio_scsi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/scsi/csiostor/csio_scsi.c 
> b/drivers/scsi/csiostor/csio_scsi.c
> index 2c4562d..c318855 100644
> --- a/drivers/scsi/csiostor/csio_scsi.c
> +++ b/drivers/scsi/csiostor/csio_scsi.c
> @@ -1327,7 +1327,9 @@ csio_scsim_cleanup_io_lnode(struct csio_scsim
> *scm, struct csio_lnode *ln)
>   sld.level = CSIO_LEV_LNODE;
>   sld.lnode = ln;
>   INIT_LIST_HEAD(&ln->cmpl_q);
> + spin_lock_irq(&hw->lock);
>   csio_scsi_gather_active_ios(scm, &sld, &ln->cmpl_q);
> + spin_unlock_irq(&hw->lock);
> 
>   /* No I/Os pending on this lnode  */
>   if (list_empty(&ln->cmpl_q))
> --
> 2.1.4

Acked-By:  Anish Bhatt 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] csiostor:Fix locking issues in the function csio_scsim_cleanup_io_lnode

[Anish Bhatt]

> -Original Message-
> From: Praveen Madhavan
> Sent: Friday, September 4, 2015 6:12 AM
> To: Anish Bhatt; Nicholas Krause; jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net;
> Hariprasad S; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] csiostor:Fix locking issues in the function
> csio_scsim_cleanup_io_lnode
> 
> csio_scsim_cleanup_io_lnode always called with spin_lock_irq held.
> Please refer:
> csio_attr.c:624:csio_scsim_cleanup_io_lnode(csio_hw_to_scsim(hw),
> ln);
> csio_attr.c:649:
> csio_scsim_cleanup_io_lnode(csio_hw_to_scsim(hw), ln);
> 
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Anish Bhatt
> Sent: Thursday, September 03, 2015 7:07 AM
> To: Nicholas Krause; jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net;
> Hariprasad S; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] csiostor:Fix locking issues in the function
> csio_scsim_cleanup_io_lnode
> 
> > -Original Message-
> > From: Nicholas Krause [mailto:xerofo...@gmail.com]
> > Sent: Wednesday, September 2, 2015 10:36 AM
> > To: jbottom...@odin.com
> > Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish
> > Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] csiostor:Fix locking issues in the function
> > csio_scsim_cleanup_io_lnode
> >
> > This fixes locking issues in the function csio_scsim_cleanup_io_lnode
> > by locking around the call to the function csio_csci_gather_active_ios
> > with the function pair spin_lock_irq/spin_unlock_irq as any function
> > calling this particular function must do in order to avoid concurrent
> > threads of execution on the passed structure pointer of type csio_hw
> > as this structure pointer can be shared across mutliple threads in the
> kernel.
> >
> > Signed-off-by: Nicholas Krause 
> > ---
> >  drivers/scsi/csiostor/csio_scsi.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/scsi/csiostor/csio_scsi.c
> > b/drivers/scsi/csiostor/csio_scsi.c
> > index 2c4562d..c318855 100644
> > --- a/drivers/scsi/csiostor/csio_scsi.c
> > +++ b/drivers/scsi/csiostor/csio_scsi.c
> > @@ -1327,7 +1327,9 @@ csio_scsim_cleanup_io_lnode(struct csio_scsim
> > *scm, struct csio_lnode *ln)
> > sld.level = CSIO_LEV_LNODE;
> > sld.lnode = ln;
> > INIT_LIST_HEAD(&ln->cmpl_q);
> > +   spin_lock_irq(&hw->lock);
> > csio_scsi_gather_active_ios(scm, &sld, &ln->cmpl_q);
> > +   spin_unlock_irq(&hw->lock);
> >
> > /* No I/Os pending on this lnode  */
> > if (list_empty(&ln->cmpl_q))
> > --
> > 2.1.4
> 
> Acked-By:  Anish Bhatt 

My bad, NACK.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] csiostor:Fix backwards locking in the function __csio_unreg_rnode

[Anish Bhatt]

> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Thursday, September 3, 2015 10:09 AM
> To: jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish
> Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] csiostor:Fix backwards locking in the function
> __csio_unreg_rnode
> 
> This fixes backwards locking in the function __csio_unreg_rnode to properly
> lock before the call to the function csio_unreg_rnode and not unlock with
> spin_unlock_irq as this would not allow the proper protection for concurrent
> access on the shared csio_hw structure pointer hw. In addition switch the
> locking after the critical region function call to properly unlock instead 
> with
> spin_unlock_irq on the shared structure pointer.
> 
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/scsi/csiostor/csio_rnode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/csiostor/csio_rnode.c
> b/drivers/scsi/csiostor/csio_rnode.c
> index e9c3b04..029a09e 100644
> --- a/drivers/scsi/csiostor/csio_rnode.c
> +++ b/drivers/scsi/csiostor/csio_rnode.c
> @@ -580,9 +580,9 @@ __csio_unreg_rnode(struct csio_rnode *rn)
>   ln->last_scan_ntgts--;
>   }
> 
> - spin_unlock_irq(&hw->lock);
> - csio_unreg_rnode(rn);
>   spin_lock_irq(&hw->lock);
> + csio_unreg_rnode(rn);
> + spin_unlock_irq(&hw->lock);
> 
>   /* Cleanup I/Os that were waiting for rnode to unregister */
>   if (cmpl)
> --
> 2.1.4

NACK, function is called with lock held.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] csiostor:Fix locking requirements for function call in the function csio_alloc_rnode

[Anish Bhatt]

> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Thursday, September 3, 2015 10:44 AM
> To: jbottom...@odin.com
> Cc: h...@suse.de; micha...@cs.wisc.edu; da...@davemloft.net; Anish
> Bhatt; Hariprasad S; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] csiostor:Fix locking requirements for function call in the
> function csio_alloc_rnode
> 
> This fixes locking requirements for the function call to the function
> csio_rnode_init to properly lock and disable irqs before calling this function
> with spin_lock_irq on the structure pointer hw of type csio_hw and unlocking
> after the function call with spin_unlock_irq in order to prevent concurrent
> access on the shared structure pointer hw of type csio_hw with other
> threads of execution accessing this structure
> 
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/scsi/csiostor/csio_rnode.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/csiostor/csio_rnode.c
> b/drivers/scsi/csiostor/csio_rnode.c
> index e9c3b04..85635f4 100644
> --- a/drivers/scsi/csiostor/csio_rnode.c
> +++ b/drivers/scsi/csiostor/csio_rnode.c
> @@ -222,9 +222,13 @@ csio_alloc_rnode(struct csio_lnode *ln)
>   goto err;
> 
>   memset(rn, 0, sizeof(struct csio_rnode));
> - if (csio_rnode_init(rn, ln))
> + spin_lock_irq(&hw->lock);
> + if (csio_rnode_init(rn, ln)) {
> + spin_unlock_irq(&hw->lock);
>   goto err_free;
> -
> + }
> +
> + spin_unlock_irq(&hw->lock);
>   CSIO_INC_STATS(ln, n_rnode_alloc);
> 
>   return rn;
> --
> 2.1.4

NACK. Function called from csio_fcoe_fwevt_handler() with lock held.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the net-next tree

[Anish Bhatt]

This is totally my bad. Already posted the fix some time ago.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: linux-next: Tree for Sep 19

[Anish Bhatt]

If you're just bisecting, you probably want my very first commit that started 
this :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=c99d667e852766afc755fa4430be64bb94e5ea1c

Essentially, the bnx2 modules would silently disable ipv6 support if ipv6 was 
compiled as a module, but cnic was inbuilt. Then it turned out that the select
on CNIC would override the tristate for CNIC, causing build failures.

The fix for CNIC caused introduced recursive dependencies, requiring this :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=5d6be6a5d4864712832822efeb9c2d54e4063949

which further required this :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=95cd6f488d164de462a8279e802a0ad05c33d167

Turns out this was not enough either, requiring this fix :
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=6a38792ca8a5da28f65dc42eeb73d9a431f8d0fd

and so on and so forth. According to the last message, Randy might be
 working on a proper fix for this :
http://www.spinics.net/lists/linux-scsi/msg78416.html

Most of this seems to be that the default configs do not select NET, but select 
SCSI_FC* 
which used to previously select NET on it's own (via SCSI_NET_LINK), maybe this 
is wrong too ?
-Anish


From: Guenter Roeck [groe...@gmail.com] on behalf of Guenter Roeck 
[li...@roeck-us.net]
Sent: Friday, September 19, 2014 2:14 PM
To: Stephen Rothwell
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; 
David S. Miller; James E.J. Bottomley
Subject: Re: linux-next: Tree for Sep 19

On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20140917:
>
> The fsl tree still had its build failure so I used the version from
> next-20140917.
>
> The v4l-dvb tree lost its build failure.
>
> The security tree gained a conflict against the file-locks tree.
>
> Non-merge commits (relative to Linus' tree): 6014
>  5488 files changed, 217522 insertions(+), 129375 deletions(-)
>
> 
>
Guess this is most difficult one.

mips:nlm_xlp_defconfig:

warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)
warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)

followed by:

ERROR: "scsi_is_fc_rport" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "fc_get_event_number" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "skb_trim" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "fc_host_post_event" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "__alloc_skb" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "fc_remote_port_delete" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "kfree_skb" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "fc_block_scsi_eh" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "fc_remote_port_add" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "skb_put" [drivers/scsi/libfc/libfc.ko] undefined!
ERROR: "skb_clone" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "dev_get_by_name" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "register_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "unregister_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_trim" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "__netdev_alloc_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "__pskb_pull_tail" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_queue_purge" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "__ethtool_get_settings" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_push" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_pull" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "init_net" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_queue_tail" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "kfree_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_dequeue" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "consume_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "dev_queue_xmit" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "skb_put" [drivers/scsi/fcoe/libfcoe.ko] undefined!
ERROR: "dev_get_stats" [drivers/scsi/fcoe/libfcoe.ko] undefined!

The problem is that there are many different errors seen at various stages
during bisect, making a bisect a bit tricky.


At commit 'xfrm: Generate blackhole ro

RE: linux-next: Tree for Sep 19

[Anish Bhatt]

Is it completely acceptable to have default configs that select menu entries 
but not their dependencies ? Since essentially earlier the select on 
SCSI_NETLINK select used to select NET but no longer does, so I'm wondering
 if this was an oversight earlier.  Is this something that's supposed to be 
automatically resolved ?
-Anish

From: Randy Dunlap [rdun...@infradead.org]
Sent: Friday, September 19, 2014 3:21 PM
To: Guenter Roeck; Stephen Rothwell
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; 
David S. Miller; James E.J. Bottomley
Subject: Re: linux-next: Tree for Sep 19

On 09/19/14 14:14, Guenter Roeck wrote:
> On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20140917:
>>
>> The fsl tree still had its build failure so I used the version from
>> next-20140917.
>>
>> The v4l-dvb tree lost its build failure.
>>
>> The security tree gained a conflict against the file-locks tree.
>>
>> Non-merge commits (relative to Linus' tree): 6014
>>  5488 files changed, 217522 insertions(+), 129375 deletions(-)
>>
>> 
>>
> Guess this is most difficult one.
>
> mips:nlm_xlp_defconfig:
>
> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)
> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)

Yes, I have a patch sitting on my hard drive that makes LIBFCOE and TCM_QLA2XXX
and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about
having to hunt these down (even with the help of kconfig warnings).

I'm pretty sure that I can fix these (above and build errors below), but
there is still a bunch of nasty kconfig warnings that I don't understand
and don't know how to fix:

(powerpc ppc64_defconfig) produced these warnings:

warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 
440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 
440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects 
IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && 
NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 
460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet 
direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 
440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 
440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has 
unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects 
IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && 
NET_VENDOR_IBM)
warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 
460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet 
direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM)


git bisect also points to the SCSI_NETLINK dependency commit for these (unless
I did the bisect incorrectly).

Does anyone have a clue on these?
Thanks.


> followed by:
>
> ERROR: "scsi_is_fc_rport" [drivers/scsi/libfc/libfc.ko] undefined!
> ERROR: "fc_get_event_number" [drivers/scsi/libfc/libfc.ko] undefined!
> ERROR: "skb_trim" [drivers/scsi/libfc/libfc.ko] undefined!
> ERROR: "fc

RE: [PATCH] scsi: fix SCSI_BNX2X_FCOE dependencies and build errors

[Anish Bhatt]

Leaves only 1 warning still reproduceable : 
(LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies 
(SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS),
 so maybe that needs a fix too ? All the other fcoe/scsi menu entries behave 
as expected.

Tested-by: Anish Bhatt 

From: Randy Dunlap [rdun...@infradead.org]
Sent: Friday, September 19, 2014 3:38 PM
To: net...@vger.kernel.org; David Miller
Cc: LKML; Anish Bhatt; James Bottomley
Subject: [PATCH] scsi: fix SCSI_BNX2X_FCOE dependencies and build errors

From: Randy Dunlap 

Don't enable NETDEVICES when NET is not enabled. That causes
build warnings and errors.

warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects 
NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && 
SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies 
(NETDEVICES && NET)
warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has 
unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)

../drivers/net/ethernet/cisco/enic/enic_main.c: In function 
'enic_rq_indicate_buf':
../drivers/net/ethernet/cisco/enic/enic_main.c:1077:3: error: implicit 
declaration of function 'skb_mark_napi_id' 
[-Werror=implicit-function-declaration]
../drivers/net/ethernet/cisco/enic/enic_main.c:1078:3: error: implicit 
declaration of function 'enic_poll_busy_polling' 
[-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap 
---
 drivers/scsi/bnx2fc/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20140918.orig/drivers/scsi/bnx2fc/Kconfig
+++ linux-next-20140918/drivers/scsi/bnx2fc/Kconfig
@@ -1,7 +1,8 @@
 config SCSI_BNX2X_FCOE
tristate "QLogic NetXtreme II FCoE support"
-   depends on PCI
+   depends on PCI && NET
depends on (IPV6 || IPV6=n)
+   depends on SCSI_FC_ATTRS
select NETDEVICES
select ETHERNET
select NET_VENDOR_BROADCOM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: Tree for Sep 19

[Anish Bhatt]

Original config causing issues can be seen here :
https://lkml.org/lkml/2014/9/9/500

As CNIC depends on IPV6, CNIC can be only compiled as a module when IPV6 is 
compiled as a module. This was the patch I originally commited. Previous 
behaviour was to disable all ipv6 code in such a case. However, having bnx2fc/i 
 as built-in overrides CNIC's tristate from m to built-in (as they select 
CNIC), 
 causing build issues. As far as I know, there is no way to control the state 
that select sets.
 -Anish

From: Randy Dunlap [rdun...@infradead.org]
Sent: Friday, September 19, 2014 6:09 PM
To: Guenter Roeck; Stephen Rothwell
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; 
David S. Miller; James E.J. Bottomley
Subject: Re: linux-next: Tree for Sep 19

On 09/19/14 17:15, Guenter Roeck wrote:
> On 09/19/2014 03:21 PM, Randy Dunlap wrote:
>> On 09/19/14 14:14, Guenter Roeck wrote:
>>> On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20140917:
>>>>
>>>> The fsl tree still had its build failure so I used the version from
>>>> next-20140917.
>>>>
>>>> The v4l-dvb tree lost its build failure.
>>>>
>>>> The security tree gained a conflict against the file-locks tree.
>>>>
>>>> Non-merge commits (relative to Linus' tree): 6014
>>>>   5488 files changed, 217522 insertions(+), 129375 deletions(-)
>>>>
>>>> 
>>>>
>>> Guess this is most difficult one.
>>>
>>> mips:nlm_xlp_defconfig:
>>>
>>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
>>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)
>>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has
>>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS)
>>
>> Yes, I have a patch sitting on my hard drive that makes LIBFCOE and 
>> TCM_QLA2XXX
>> and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about
>> having to hunt these down (even with the help of kconfig warnings).
>>
>
> One key problem is that nlm_xlp_defconfig does not configure NET anymore.
> this is after 'scsi_netlink : Make SCSI_NETLINK dependent on NET instead
> of selecting NET' was applied.
>
> In fact, there are many more affected configurations; the change from
> "select XXX" to "depends XXX" has far reaching consequences, as many
> configurations are no longer valid. For mips alone I find that this commit
> changes the following configurations.
>
> e55_defconfig
> gpr_defconfig
> ip27_defconfig
> jazz_defconfig
> loongson3_defconfig
> malta_defconfig
> malta_kvm_defconfig
> malta_kvm_guest_defconfig
> mtx1_defconfig
> nlm_xlp_defconfig
> nlm_xlr_defconfig
> rm200_defconfig
>
> e55_defconfig is almost the same as before, but only because CONFIG_NET
> was not configured for it to start with. For all others, CONFIG_NET is
> no longer set. This effectively means that out of 55 mips configurations,
> 11 or 20% are now bad. This is 3.17-rc5. vs. next-20140919.
>
> Frankly, I don't think this change was really helpful. On the contrary,
> we will be in a lot of trouble when this change makes it upstream.
> It might be be a good idea to be much more careful when making such
> changes. Cleaning up configuration dependencies is a laudable goal,
> but when it breaks configurations all over the place it does more damage
> than it is worth.

Yes, I suspect that we should just drop this effort and redo the original
problem's "fix".

Dave?

Anish, if you can remind me of the original problem and hopefully a kernel
.config file for it, I'll try to help with it.

--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: mmotm 2014-09-22-16-57 uploaded

[Anish Bhatt]

> > cc'ing Anish Bhatt.
> >
> He knows about it, as do David Miller and Randy Dunlap (who proposed it)
> [1].
> There just doesn't seem to be an agreement on how to fix the problem.
> A simple revert doesn't work anymore since there are multiple follow-up
> patches, and if I understand correctly David is opposed to a revert anyway.

Dave is working on  a patch based on Randy's last solution :
http://www.spinics.net/lists/netdev/msg297593.html

Not sure of the current status.
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry

[Anish Bhatt]

The MSR_SYSCALL_MASK, which is responsible for clearing specific EFLAGS on
 syscall entry, should also clear the nested task (NT) flag to be safe from
 userspace injection. Without this fix the application segmentation
 faults on syscall return because of the changed meaning of the IRET
 instruction.

Further details can be seen here https://bugs.winehq.org/show_bug.cgi?id=33275

Signed-off-by: Anish Bhatt 
Signed-off-by: Sebastian Lackner 
---
 arch/x86/kernel/cpu/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b4..3126558 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1184,7 +1184,7 @@ void syscall_init(void)
/* Flags to clear on syscall */
wrmsrl(MSR_SYSCALL_MASK,
   X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|
-  X86_EFLAGS_IOPL|X86_EFLAGS_AC);
+  X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
 }
 
 /*
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry

[Anish Bhatt]

> -Original Message-
> From: Chuck Ebbert [mailto:cebbert.l...@gmail.com]
> Sent: Friday, September 26, 2014 3:01 PM
> To: Anish Bhatt
> Cc: linux-kernel@vger.kernel.org; x...@kernel.org; t...@linutronix.de;
> mi...@redhat.com; h...@zytor.com; sebast...@fds-team.de; Linus
> Torvalds
> Subject: Re: [PATCH] x86 : Ensure X86_FLAGS_NT is cleared on syscall entry
> 
> On Thu, 25 Sep 2014 12:42:51 -0700
> Anish Bhatt  wrote:
> 
> > The MSR_SYSCALL_MASK, which is responsible for clearing specific
> > EFLAGS on  syscall entry, should also clear the nested task (NT) flag
> > to be safe from  userspace injection. Without this fix the application
> > segmentation  faults on syscall return because of the changed meaning
> > of the IRET  instruction.
> >
> > Further details can be seen here
> > https://bugs.winehq.org/show_bug.cgi?id=33275
> >
> > Signed-off-by: Anish Bhatt 
> > Signed-off-by: Sebastian Lackner 
> > ---
> >  arch/x86/kernel/cpu/common.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/cpu/common.c
> > b/arch/x86/kernel/cpu/common.c index e4ab2b4..3126558 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -1184,7 +1184,7 @@ void syscall_init(void)
> > /* Flags to clear on syscall */
> > wrmsrl(MSR_SYSCALL_MASK,
> >X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|
> > -  X86_EFLAGS_IOPL|X86_EFLAGS_AC);
> > +  X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
> >  }
> >
> >  /*
> 
> I don't get it. Why isn't this patch acceptable, at least on x86-64 where NT 
> is
> never valid?
> 
> Bueller?

Chuck, I don't think anyone has gotten around to reviewing, accepting or 
 rejecting this patch yet.
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] checkpatch: Warn on unnecessary void function return statements

[Anish Bhatt]

On Wed 18 Jun 2014 10:44:44 AM PDT, Joe Perches wrote:
> With some exceptions, warn on void functions that end with a
> "return;", because it's unnecessary.
>
> Check the closing brace at the start of a line.
> If the line before that has a single tab, then return;
> look at the line before that.  If it's not a label,
> emit a warning.
>
> So, emit a warning on:
>
> void function(...)
> {
>   [...]
>   return;
> }
>
> but do not emit a warning on the below because
> gcc requires any statement (including a bare
> semicolon) before the closing function brace:
>
> void function(...)
> {
>   [...]
>   goto label;
>   [...]
>
> label:
>   return;
> }
>
> Signed-off-by: Joe Perches 
> ---
>
> V2: The previous patch had a few too many false positives
> on styles that should be acceptable.
>
>  scripts/checkpatch.pl | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 862cc7a..b191c88 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3470,6 +3470,18 @@ sub process {
>   }
>   }
>
> +# unnecessary return in a void function
> +# at end-of-function, with the previous line a single leading tab, then 
> return;
> +# and the line before that not a goto label target like "out:"
> + if ($sline =~ /^[ \+]}\s*$/ &&
> + $prevline =~ /^\+\treturn\s*;\s*$/ &&
> + $linenr >= 3 &&
> + $lines[$linenr - 3] =~ /^[ +]/ &&
> + $lines[$linenr - 3] !~ /^[ +]\s*$Ident\s*:/) {
> + WARN("RETURN_VOID",
> +  "void function return statements are not generally 
> useful\n" . $hereprev);
> +   }
> +
>  # if statements using unnecessary parentheses - ie: if ((foo == bar))
>   if ($^V && $^V ge 5.10.0 &&
>   $line =~ /\bif\s*((?:\(\s*){2,})/) {
>
>

Confirming, no longer hitting previous false positives for me.
-Anish

--
As long as the music's loud enough, we won't hear the world falling 
apart.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Bug report] Hit false positives bug with script/checkpatch.pl

[Anish Bhatt]

Parantheses/do {...} while(0) would not work for direct value substituons like 
this obviously but fixing this false positive seems hard. An exception case 
that is something like "macros with complex values separated by commas but no 
statements terminated by semicolons" is my best but seems-very-vague guess.
-Anish

From: Joe Perches [j...@perches.com]
Sent: Tuesday, July 15, 2014 9:20 PM
To: Ethan Zhao
Cc: Anish Bhatt; a...@canonical.com; linux-kernel@vger.kernel.org; 
ethan.ker...@gmail.com; joe@oracle.com
Subject: Re: [Bug report] Hit false positives bug with script/checkpatch.pl

On Wed, 2014-07-16 at 10:50 +0800, Ethan Zhao wrote:
> Hi,
>  I hit a false positives bug when run script/checkpatch.pl to my patch,
> It reported  errors to following macro definition, but in fact the macro is
> correct, I couldn't change that macro according to the error message output
> by script/checkpatch.pl. because of this bug, my patch was rejected by some
> guy's patchwork.

You could tell the guy checkpatch isn't always right.

You could also change the macro to something like:

#define NETXEN_NIC_STAT(name, m)\
{   \
.name = name,   \
.type = m,  \
.sizeof_stat = FIELD_SIZEOF(struct netxen_adapter, m),  \
.stat_offset = offsetof(struct netxen_adapter, m)   \
}

and change the uses like:

static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
NETXEN_NIC_STAT("xmit called", stats.xmitcalled),
NETXEN_NIC_STAT("xmit_finished", stats.xmitfinished),

etc...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Anish Bhatt]

This seems to ignore the ability to exit from void return functions via a 
`return;` in case of an error or similar. Any attempt to bail out generates 
warnings with checkpathch.pl Perhaps it should check for returns only at the 
end of the function ? If not, is there a suggested way to do this ? goto labels 
can't be directly used in place either

-Anish Bhatt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Anish Bhatt]

My code has multiple exit lables:
void function(void)
{
...

if (err1)
goto exit1;
...
if (err2)
goto exit2;

...
return; /* Good return, no errors */
exit1:
printk(err1);
return;
exit2:
printk(err2);
}

The single tabbed return was required to prevent the good return & err1 
messages cascading down. The extra exit label with a noop looks weird, 
but is passing checkpatch.pl --strict, so I will go with that, thanks.
-Anish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Anish Bhatt]

On 06/16/2014 07:00 PM, Joe Perches wrote:
> On Mon, 2014-06-16 at 17:44 -0700, Anish Bhatt wrote:
>> My code has multiple exit lables:
>> void function(void)
>> {
>>  ...
>>
>>  if (err1)
>>  goto exit1;
>>  ...
>>  if (err2)
>>  goto exit2;
>>
>>  ...
>>  return; /* Good return, no errors */
>> exit1:
>>  printk(err1);
>>  return;
>> exit2:
>>  printk(err2);
>> }
>>
>> The single tabbed return was required to prevent the good return & err1 
>> messages cascading down. The extra exit label with a noop looks weird, 
>> but is passing checkpatch.pl --strict, so I will go with that, thanks.
>> -Anish
>>
> 
> Hmm, those return uses seem reasonable
> to me.
> 
> Perhaps the test should warn only on
> this specific 3 line sequence:
> 
> [any line but a label]
>   return;
> }
> 
> Andrew?  Anyone else?  Opinions?
> 
I think simply 

return;
}

should trigger the warning. If you are using a label just to exit, you could 
just do it in-place (though possibly someone might want to a goto instead of 
multiple returns)

-Anish

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: randconfig build error with next-20140909, in drivers/net/ethernet/broadcom/cnic.c

[Anish Bhatt]

This is caused by c99d667e8527  ("cnic : Cleanup CONFIG_IPV6 & VLAN check")

So I'm not really sure what the fix for this is. CNIC will properly only 
support 
[m] or [n] when IPV6 is compiled as a module, but if you set SCSI_BNX2X_FCOE or 
SCSI_BNX2_ISCSI to be in built, there is a 'select CNIC' that forces CNIC to be 
inbuilt, even though this is not supported by Kconfig. I was under the 
assumption that select will not forcibly change m to inbuilt (or perhaps I'm 
missing some syntax suboption ?)

This is still fixable in SCSI_BNX2_ISCSI using the same logic used in the above 
mentioned commit, but not so in SCSI_BNX2X_FCOE where it causes a recursive 
dependency error (thought it is fixing the issue nevertheless), and none of the 
 other solutions I tried seemed to work either.

Looking at previous code, the earlier approach used to just disable ipv6 code 
in such a situation.
-Anish


From: Jim Davis [jim.ep...@gmail.com]
Sent: Tuesday, September 09, 2014 7:38 AM
To: Stephen Rothwell; linux-next; linux-kernel; Anish Bhatt; 
mc...@broadcom.com; David S. Miller; netdev
Subject: randconfig build error with next-20140909, in 
drivers/net/ethernet/broadcom/cnic.c

Building with the attached random configuration file,

drivers/built-in.o: In function `cnic_get_v6_route':
cnic.c:(.text+0x3a4168): undefined reference to `ip6_route_output'
make: *** [vmlinux] Error 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: randconfig build error with next-20140909, in drivers/net/ethernet/broadcom/cnic.c

[Anish Bhatt]

> Adding depends on IPV6 || IPV6=n doesn't work for SCSI_BNX2X_FCOE, but
> works for SCSI_BNX2_ISCSI?

It fixes the config issue for both, but with FCOE; make scripts will complain 
about recursive dependencies with the following :

scripts/kconfig/conf --silentoldconfig Kconfig
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5:  symbol NET is selected by SCSI_NETLINK
drivers/scsi/Kconfig:43:symbol SCSI_NETLINK is selected by SCSI_FC_ATTRS
drivers/scsi/Kconfig:258:   symbol SCSI_FC_ATTRS is selected by LIBFC
drivers/scsi/Kconfig:586:   symbol LIBFC is selected by SCSI_BNX2X_FCOE
drivers/scsi/bnx2fc/Kconfig:1:  symbol SCSI_BNX2X_FCOE depends on IPV6
net/ipv6/Kconfig:6: symbol IPV6 depends on NET


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: randconfig build error with next-20140909, in drivers/net/ethernet/broadcom/cnic.c

[Anish Bhatt]

> It would be really good if SCSI_NETLINK depended on NET instead of selected 
> NET.
> We shouldn't have kconfig symbols that use 'select' on entire subsystems.

As a test, I was able to fix this by this approach : change SCSI_NETLINK to 
depend  
on NET instead of selecting NET, and replacing 'select NETDEVICES ETHERNET 
NET_VENDOR_BROADCOM CNIC' to 'depends on CNIC' in bnx2i & bnx2fc. (as CNIC 
already has a dependency on those). This removes the need to check for IPV6 in 
bnx2i/fc Kconfigs as well.

The side effect is that you won't see BNX2 drivers unless CNIC is selected, 
similar
for SCSI_NETLINK as well, not sure if there are any other implications.
-Anish--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: randconfig build error with next-20140909, in drivers/net/ethernet/broadcom/cnic.c

[Anish Bhatt]

> -Original Message-
> From: Michael Chan [mailto:mc...@broadcom.com]
> Sent: Tuesday, September 9, 2014 4:21 PM
> To: Anish Bhatt
> Cc: Randy Dunlap; eddie@broadcom.com; Jim Davis; Stephen Rothwell;
> linux-next; linux-kernel; David S. Miller; netdev; James Bottomley
> Subject: RE: randconfig build error with next-20140909, in
> drivers/net/ethernet/broadcom/cnic.c
> 
> On Tue, 2014-09-09 at 23:16 +, Anish Bhatt wrote:
> > > It would be really good if SCSI_NETLINK depended on NET instead of
> selected NET.
> > > We shouldn't have kconfig symbols that use 'select' on entire
> subsystems.
> >
> > As a test, I was able to fix this by this approach : change
> > SCSI_NETLINK to depend on NET instead of selecting NET, and replacing
> > 'select NETDEVICES ETHERNET NET_VENDOR_BROADCOM CNIC' to
> 'depends on
> > CNIC' in bnx2i & bnx2fc. (as CNIC already has a dependency on those).
> > This removes the need to check for IPV6 in bnx2i/fc Kconfigs as well.
> >
> > The side effect is that you won't see BNX2 drivers unless CNIC is
> > selected, similar for SCSI_NETLINK as well, not sure if there are any other
> implications.
> 
> Right.  I think it is more user-friendly for BNX2I and BNX2FC to select CNIC.
> CNIC is not useful by itself and it makes more sense to select it 
> automatically
> when BNX2I/BNX2FC are enabled.
> 

Ok, it can work leaving 'select CNIC' as is, the key is changing the dependency
for SCSI_NETLINK from 'select  NET' to 'depends on NET' and is basically what 
fixes the issue with make.   removing  'select NETDEVICES ETHERNET 
NET_VENDOR_BROADCOM' from the bnx2i/fc modules is just cleanup.

bnx2i/bnx2fc need a check on IPV6 if we leave 'select CNIC' as is.

I have a patch for this ready, but I don't know too much about SCSI_NETLINK,
so maybe some else can chime in if this is a good idea ?
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 2/3] cxgb4: use module_long_probe_init()

[Anish Bhatt]

Adding Casey who's actually incharge of this code and missing from the CC list
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LKP] [cxgb4i] INFO: suspicious RCU usage. ]

[Anish Bhatt]

One socket to bind them all

From: Aaron Lu 
Sent: Jul 27, 2014 7:05 PM
To: Anish Bhatt
Cc: "David S. Miller" ;LKML;l...@01.org
Subject: [LKP] [cxgb4i] INFO: suspicious RCU usage. ]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 759a0cc5a3e1bc2cc48fa3c0b91bdcad8b8f87d6 ("cxgb4i: Add ipv6 code to 
driver, call into libcxgbi ipv6 api")



[7.671997] Key type encrypted registered
[7.676647]
[7.676874] ===
[7.677354] [ INFO: suspicious RCU usage. ]
[7.677867] 3.16.0-rc6-01233-gac3d2e5 #1272 Not tainted
[7.678466] ---
[7.678973] include/linux/rcupdate.h:513 Illegal context switch in RCU 
read-side critical section!
[7.680252]
[7.680252] other info that might help us debug this:
[7.680252]
[7.681194]
[7.681194] rcu_scheduler_active = 1, debug_locks = 1
[7.682071] 3 locks held by swapper/1:
[7.682667]  #0:  (rtnl_mutex){+.+.+.}, at: [] 
rtnl_lock+0x17/0x19
[7.683990]  #1:  (rcu_read_lock){..}, at: [] 
__atomic_notifier_call_chain+0x5/0x105
[7.685606]  #2:  (rcu_read_lock){..}, at: [] 
cxgbi_inet6addr_handler+0x5/0x202
[7.687150]
[7.687150] stack backtrace:
[7.687837] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.16.0-rc6-01233-gac3d2e5 #1272
[7.689016]   880100d639f8 87e25ccc 
880100d63a28
[7.690951]  86cbc38c 885d9370 024a 

[7.692164]  880100c66000 880100d63a50 86cadfd4 
88ad4d90
[7.693375] Call Trace:
[7.693795]  [] dump_stack+0x19/0x1b
[7.694579]  [] lockdep_rcu_suspicious+0xe9/0xf2
[7.695533]  [] __might_sleep+0x58/0x1e9
[7.696372]  [] mutex_lock_nested+0x3b/0x3d3
[7.697265]  [] ? sched_clock_local.constprop.2+0x34/0xa1
[7.698323]  [] cxgbi_device_find_by_netdev+0x63/0x102
[7.699359]  [] cxgbi_inet6addr_handler+0xa1/0x202
[7.700380]  [] ? cxgbi_inet6addr_handler+0x5/0x202
[7.701384]  [] notifier_call_chain+0xf4/0x126
[7.702322]  [] __atomic_notifier_call_chain+0x9c/0x105
[7.703366]  [] ? __atomic_notifier_call_chain+0x5/0x105
[7.704241]  [] atomic_notifier_call_chain+0x14/0x16
[7.705234]  [] inet6addr_notifier_call_chain+0x1b/0x1d
[7.706505]  [] ipv6_add_addr+0x218/0x544
[7.707539]  [] ? ipv6_add_addr+0x65/0x544
[7.708484]  [] add_addr+0x31/0x93
[7.709420]  [] addrconf_notify+0x65e/0x9b9
[7.710559]  [] ? _raw_read_unlock+0x27/0x31
[7.711523]  [] ? __lock_is_held+0x37/0x4f
[7.712588]  [] notifier_call_chain+0xf4/0x126
[7.713683]  [] raw_notifier_call_chain+0x14/0x16
[7.714706]  [] call_netdevice_notifiers_info+0x71/0x7a
[7.715987]  [] call_netdevice_notifiers+0x13/0x15
[7.717071]  [] __dev_notify_flags+0x54/0x82
[7.718127]  [] dev_change_flags+0x4d/0x58
[7.719187]  [] ip_auto_config+0x177/0xdbf
[7.720146]  [] ? slob_free+0x2cb/0x2d8
[7.721173]  [] ? root_nfs_parse_addr+0xa3/0xaf
[7.722309]  [] ? do_one_initcall+0x98/0x1d0
[7.723252]  [] ? root_nfs_parse_addr+0xaf/0xaf
[7.724522]  [] do_one_initcall+0x1bb/0x1d0
[7.725547]  [] ? param_array_set+0x82/0x11e
[7.726539]  [] ? parse_args+0x1a5/0x27f
[7.727463]  [] kernel_init_freeable+0xf8/0x17d
[7.728598]  [] ? initcall_blacklist+0x9f/0x9f
[7.729585]  [] ? rest_init+0x136/0x136
[7.730678]  [] kernel_init+0xe/0xda
[7.731661]  [] ret_from_fork+0x7a/0xb0
[7.732532]  [] ? rest_init+0x136/0x136
[7.734390] IP-Config: Failed to open gretap0
[7.735138] IP-Config: No network devices available
[7.736057] ALSA device list:



Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Thanks,
Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: build failure after merge of the scsi tree

[Anish Bhatt]

Fix for this was sent out on thursday itself, but does not seem to be applied 
yet :
http://marc.info/?l=linux-scsi&m=141529629911520&w=2

From: Stephen Rothwell [s...@canb.auug.org.au]
Sent: Sunday, November 09, 2014 10:15 PM
To: James Bottomley
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; 
Christoph Hellwig; Karen Xie
Subject: linux-next: build failure after merge of the scsi tree

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'do_abort_req_rss':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:942:3: error: too many arguments to function 
'send_tx_flowc_wr'
   send_tx_flowc_wr(csk, 0);
   ^
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:492:20: note: declared here
 static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
^

Caused by commit 4be50d4f7649 ("cxgb4i: send abort_rpl correctly").

I have used the scsi tree from next-20141106 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Fix -Wmaybe-uninitialized warning seen with make menuconfig

[Anish Bhatt]

Fixes the following :

scripts/kconfig/menu.c: In function 'get_symbol_str':
scripts/kconfig/menu.c:590:18: warning: 'jump' may be used uninitialized in
this function [-Wmaybe-uninitialized]
 jump->offset = strlen(r->s);
  ^
scripts/kconfig/menu.c:551:19: note: 'jump' was declared here
  struct jump_key *jump;

Signed-off-by: Anish Bhatt 
---
 scripts/kconfig/menu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index a26cc5d..584e0fc 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -548,7 +548,7 @@ static void get_prompt_str(struct gstr *r, struct property 
*prop,
 {
int i, j;
struct menu *submenu[8], *menu, *location = NULL;
-   struct jump_key *jump;
+   struct jump_key *jump = NULL;
 
str_printf(r, _("Prompt: %s\n"), _(prop->text));
menu = prop->menu->parent;
-- 
2.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] Fix -Wmaybe-uninitialized warning seen with make menuconfig

[Anish Bhatt]

Aah, ignore this please. Somehow I missed the two other recent mail chains
about this very thing, and my patch only covers part of it anyways.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: cxgb4: CONFIG_CXGB4_DCB?

[Anish Bhatt]

It got to the maintainer nevertheless. Thanks for bringing this to our notice 
Paul, fix for this is already in the patchwork queue :
https://patchwork.ozlabs.org/patch/434279/
-Anish
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] csiostor:Make the function csio_ln_prep_ecwr have a return type of void

[Anish Bhatt]

Acked-by: Anish Bhatt --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/