[PATCH 5/6] staging: wlan-ng: Open parenthesis alignemnt fix

2016-01-08 Thread Pranjal Bhor 
Alignments on new lines have been matched with the open parenthesis.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 19801df..117dff8 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -215,8 +215,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
  p80211_wep->iv, p80211_wep->icv);
if (foo) {
netdev_warn(wlandev->netdev,
-  "Host en-WEP failed, dropping frame (%d).\n",
-  foo);
+   "Host en-WEP failed, dropping frame 
(%d).\n",
+   foo);
return 2;
}
fc |= cpu_to_le16(WLAN_SET_FC_ISWEP(1));
@@ -330,10 +330,10 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
return 1;
}
foo = wep_decrypt(wlandev, skb->data + payload_offset + 4,
-  payload_length - 8, -1,
-  skb->data + payload_offset,
-  skb->data + payload_offset +
-  payload_length - 4);
+ payload_length - 8, -1,
+ skb->data + payload_offset,
+ skb->data + payload_offset +
+ payload_length - 4);
if (foo) {
/* de-wep failed, drop skb. */
pr_debug("Host de-WEP failed, dropping frame (%d).\n",
@@ -371,7 +371,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been encap'd. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "ENCAP frame too large (%d > %d)\n",
-  payload_length, netdev->mtu + ETH_HLEN);
+  payload_length, netdev->mtu + ETH_HLEN);
return 1;
}

@@ -400,7 +400,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "SNAP frame too large (%d > %d)\n",
-  payload_length, netdev->mtu);
+  payload_length, netdev->mtu);
return 1;
}

@@ -433,9 +433,9 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "DIXII frame too large (%ld > %d)\n",
-  (long int)(payload_length -
-   sizeof(struct wlan_llc) -
-   sizeof(struct wlan_snap)), netdev->mtu);
+  (long int)(payload_length -
+  sizeof(struct wlan_llc) -
+  sizeof(struct wlan_snap)), netdev->mtu);
return 1;
}

@@ -468,7 +468,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "OTHER frame too large (%d > %d)\n",
-  payload_length, netdev->mtu);
+  payload_length, netdev->mtu);
return 1;
}

--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/6] drivers/staging/wlan-ng/p80211conv.c: Fixed block comment coding style

2016-01-08 Thread Dan Carpenter 
You're almost there...  Just resend with the correct patch prefix.

[PATCH 1/6] Staging: wlan-ng: Fixed block comment coding style in p80211conv.c

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

2016-01-08 Thread James Bottomley 
On Fri, 2016-01-08 at 18:58 +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com
> > ]
> > Sent: Thursday, January 7, 2016 3:49 PM
> > To: KY Srinivasan ; gre...@linuxfoundation.org;
> > linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; 
> > oher...@suse.com;
> > jbottom...@parallels.com; h...@infradead.org; 
> > linux-s...@vger.kernel.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > martin.peter...@oracle.com; h...@suse.de
> > Cc: sta...@vger.kernel.org
> > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the
> > error
> > handling function
> > 
> > On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > > The macro startget_to_rport() can return NULL; handle that case
> > > properly.
> > 
> > OK, can we unwind why you think you could possibly need this?  It
> > would
> > mean that fc_timed_out was called for a non-FC device, which was
> > thought to be an impossibility when the fc transport class was
> > designed.
> 
> As you know, on Hyper-V, FC devices are handled exactly like normal 
> scsi devices and the only additional information that is provided for 
> FC devices is the WWN for port and node. Till recently, I was not 
> publishing the WWN in the guest and so I was not even using the FC 
> transport. Recently, I implemented support for publishing the WWN in 
> the guest and for that I am using the FC transport for FC hosts. When 
> an FC LUN is dynamically removed, sometimes I see the timeout occurri
> ng and since there is no rport associated with these devices I am 
> hitting the issue this patch is addressing. I could have addressed 
> this problem by establishing a storvsc specific time out function 
> even for FC devices - the same timeout function that I currently use 
> for scsi devices -  storvsc_eh_timed_out(). I chose to instead fix 
> the fc_timed_out() function since the code was not handling a
> possible condition.

OK, so the specific problem is that the device is partly torn down when
the timeout fires?  I'm having a hard time seeing how we get a null
rport in that case.  The starget_to_rport() can only return NULL if the
parent isn't an rport ... that shouldn't depend on the state of the FC
device because the parent is torn down after the child.

In any case, returning BLK_EH_RESET_TIMER will cause all sorts of
problems because it resets the timer to fire again for the device. 
 What you want is something to return BLK_EH_HANDLED which will just
complete the request ... probably at a generic level, since this
doesn't sound to be specific to FC.

Something like the below ... assuming the teardown issue is the real
problem.

James

---

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 984ddcb..3c514c6 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -273,6 +273,10 @@ enum blk_eh_timer_return scsi_times_out(struct request 
*req)
enum blk_eh_timer_return rtn = BLK_EH_NOT_HANDLED;
struct Scsi_Host *host = scmd->device->host;
 
+   /* timeout for an already dead device, just kill the request */
+   if (scmd->device->sdev_state == SDEV_DEL)
+   return BLK_EH_HANDLED;
+
trace_scsi_dispatch_cmd_timeout(scmd);
scsi_log_completion(scmd, TIMEOUT_ERROR);
 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

2016-01-08 Thread KY Srinivasan 


> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Thursday, January 7, 2016 3:49 PM
> To: KY Srinivasan ; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Cc: sta...@vger.kernel.org
> Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error
> handling function
> 
> On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > The macro startget_to_rport() can return NULL; handle that case
> > properly.
> 
> OK, can we unwind why you think you could possibly need this?  It would
> mean that fc_timed_out was called for a non-FC device, which was
> thought to be an impossibility when the fc transport class was
> designed.

As you know, on Hyper-V, FC devices are handled exactly like normal scsi
devices and the only additional information that is provided for FC devices
is the WWN for port and node. Till recently, I was not publishing the WWN in
the guest and so I was not even using the FC transport. Recently, I implemented
support for publishing the WWN in the guest and for that I am using the FC 
transport
for FC hosts. When an FC LUN is dynamically removed, sometimes I see the timeout
occurring and since there is no rport associated with these devices I am 
hitting the issue
this patch is addressing. I could have addressed this problem by establishing a 
storvsc specific
time out function even for FC devices - the same timeout function that I 
currently use for scsi
devices -  storvsc_eh_timed_out(). I chose to instead fix the fc_timed_out() 
function since
the code was not handling a possible condition.

Regards,

K. Y
> 
> James
> 
> > Signed-off-by: K. Y. Srinivasan 
> > Cc: 
> > ---
> >  drivers/scsi/scsi_transport_fc.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/scsi/scsi_transport_fc.c
> > b/drivers/scsi/scsi_transport_fc.c
> > index 24eaaf6..42a908f 100644
> > --- a/drivers/scsi/scsi_transport_fc.c
> > +++ b/drivers/scsi/scsi_transport_fc.c
> > @@ -2081,7 +2081,7 @@ fc_timed_out(struct scsi_cmnd *scmd)
> >  {
> > struct fc_rport *rport = starget_to_rport(scsi_target(scmd
> > ->device));
> >
> > -   if (rport->port_state == FC_PORTSTATE_BLOCKED)
> > +   if ((rport == NULL) || (rport->port_state ==
> > FC_PORTSTATE_BLOCKED))
> > return BLK_EH_RESET_TIMER;
> >
> > return BLK_EH_NOT_HANDLED;

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] storvsc: fix typo in MODULE_PARM_DESC

2016-01-08 Thread Martin K. Petersen 
> "Dan" == Dan Carpenter  writes:

Dan> The module_param is "storvsc_vcpus_per_sub_channel" so we need to
Dan> use that for MODULE_PARM_DESC() as well.

Applied to 4.5/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/6] drivers/staging/wlan-ng/p80211conv.c: Fixed block comment coding style

2016-01-08 Thread Pranjal Bhor 
Block comments now end with '*/' on a newline and all lines
of block comments now begin with '*'

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 37 ++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 1b02cdf..8175f17 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -49,7 +49,8 @@
 *
 * 
 *
-* */
+*
+*/

 #include 
 #include 
@@ -101,7 +102,8 @@ static u8 oui_8021h[] = { 0x00, 0x00, 0xf8 };
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb, union p80211_hdr *p80211_hdr,
struct p80211_metawep *p80211_wep)
@@ -238,7 +240,8 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
int i;

/* Gather wireless spy statistics: for each packet, compare the
-* source address with out list, and if match, get the stats... */
+* source address with out list, and if match, get the stats...
+*/

for (i = 0; i < wlandev->spy_number; i++) {

@@ -273,7 +276,8 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb)
 {
@@ -421,7 +425,8 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
&& (e_llc->ctl == 0x03)) {
pr_debug("802.1h/RFC1042 len: %d\n", payload_length);
/* it's an 802.1h frame || (an RFC1042 && protocol not in STT)
-  build a DIXII + RFC894 */
+* build a DIXII + RFC894
+*/

/* Test for an overlength frame */
if ((payload_length - sizeof(struct wlan_llc) -
@@ -521,14 +526,15 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int p80211_stt_findproto(u16 proto)
 {
-   /* Always return found for now.  This is the behavior used by the */
-   /*  Zoom Win95 driver when 802.1h mode is selected */
-   /* TODO: If necessary, add an actual search we'll probably
-  need this to match the CMAC's way of doing things.
-  Need to do some testing to confirm.
+   /* Always return found for now.  This is the behavior used by the
+* Zoom Win95 driver when 802.1h mode is selected
+* TODO: If necessary, add an actual search we'll probably
+* need this to match the CMAC's way of doing things.
+* Need to do some testing to confirm.
 */

if (proto == ETH_P_AARP)/* APPLETALK */
@@ -551,7 +557,8 @@ int p80211_stt_findproto(u16 proto)
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 void p80211skb_rxmeta_detach(struct sk_buff *skb)
 {
struct p80211_rxmeta *rxmeta;
@@ -595,7 +602,8 @@ void p80211skb_rxmeta_detach(struct sk_buff *skb)
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int p80211skb_rxmeta_attach(struct wlandevice *wlandev, struct sk_buff *skb)
 {
int result = 0;
@@ -648,7 +656,8 @@ exit:
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 void p80211skb_free(struct wlandevice *wlandev, struct sk_buff *skb)
 {
struct p80211_frmmeta *meta;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/6] drivers/staging/wlan-ng/p80211conv.c: Unnecessary blank lines removed

2016-01-08 Thread Pranjal Bhor 
Blank lines after opening curly braces and before closing curly
braces have been removed.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 5a6d1d5..2a6e818 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -108,7 +108,6 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb, union p80211_hdr *p80211_hdr,
struct p80211_metawep *p80211_wep)
 {
-
__le16 fc;
u16 proto;
struct wlan_ethhdr e_hdr;
@@ -169,7 +168,6 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
e_llc->dsap = 0xAA; /* SNAP, see IEEE 802 */
e_llc->ssap = 0xAA;
e_llc->ctl = 0x03;
-
}
}

@@ -244,7 +242,6 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
 */

for (i = 0; i < wlandev->spy_number; i++) {
-
if (!memcmp(wlandev->spy_address[i], mac, ETH_ALEN)) {
memcpy(wlandev->spy_address[i], mac, ETH_ALEN);
wlandev->spy_stat[i].level = rxmeta->signal;
@@ -486,7 +483,6 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,

/* chop off the 802.11 CRC */
skb_trim(skb, skb->len - WLAN_CRC_LEN);
-
}

/*
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/6] drivers/staging/wlan-ng/p80211conv.c: Logical continuation fix

2016-01-08 Thread Pranjal Bhor 
Logical continuation added to the 'if', 'else if' and 'else' blocks.
Logical operators now follow after conditions on the same line.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 47 ++--
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 8175f17..5a6d1d5 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -153,8 +153,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
(struct wlan_snap *) skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
-   if (ethconv == WLAN_ETHCONV_8021h
-   && p80211_stt_findproto(proto)) {
+   if (ethconv == WLAN_ETHCONV_8021h &&
+   p80211_stt_findproto(proto)) {
memcpy(e_snap->oui, oui_8021h,
   WLAN_IEEE_OUI_LEN);
} else {
@@ -204,8 +204,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

p80211_wep->data = NULL;

-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED)
-   && (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
/*  need to pick keynum other than default? */

p80211_wep->data = kmalloc(skb->len, GFP_ATOMIC);
@@ -304,12 +304,12 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
if ((WLAN_GET_FC_TODS(fc) == 0) && (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a2);
-   } else if ((WLAN_GET_FC_TODS(fc) == 0)
-   && (WLAN_GET_FC_FROMDS(fc) == 1)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 0) &&
+  (WLAN_GET_FC_FROMDS(fc) == 1)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a3);
-   } else if ((WLAN_GET_FC_TODS(fc) == 1)
-   && (WLAN_GET_FC_FROMDS(fc) == 0)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 1) &&
+  (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a3);
ether_addr_copy(saddr, w_hdr->a3.a2);
} else {
@@ -324,8 +324,9 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
}

/* perform de-wep if necessary.. */
-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) && WLAN_GET_FC_ISWEP(fc)
-   && (wlandev->hostwep & HOSTWEP_DECRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   WLAN_GET_FC_ISWEP(fc) &&
+   (wlandev->hostwep & HOSTWEP_DECRYPT)) {
if (payload_length <= 8) {
netdev_err(netdev,
   "WEP frame too short (%u).\n", skb->len);
@@ -383,15 +384,15 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
skb_trim(skb, skb->len - WLAN_CRC_LEN);

} else if ((payload_length >= sizeof(struct wlan_llc) +
-   sizeof(struct wlan_snap))
-   && (e_llc->dsap == 0xaa)
-   && (e_llc->ssap == 0xaa)
-   && (e_llc->ctl == 0x03)
-  &&
-  (((memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) == 0)
-&& (ethconv == WLAN_ETHCONV_8021h)
-&& (p80211_stt_findproto(le16_to_cpu(e_snap->type
-   || (memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) !=
+   sizeof(struct wlan_snap)) &&
+   (e_llc->dsap == 0xaa) &&
+   (e_llc->ssap == 0xaa) &&
+   (e_llc->ctl == 0x03) &&
+   (((memcmp(e_snap->oui, oui_rfc1042,
+   WLAN_IEEE_OUI_LEN) == 0) &&
+   (ethconv == WLAN_ETHCONV_8021h) &&
+   (p80211_stt_findproto(le16_to_cpu(e_snap->type ||
+   (memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) !=
0))) {
pr_debug("SNAP+RFC1042 len: %d\n", payload_length);
/* it's a SNAP + RFC1042 frame && protocol is in STT */
@@ -419,10 +420,10 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
skb_trim(skb, skb->len - WLAN_CRC_LEN);

} else if ((payload_length >= sizeof(struct wlan_llc) +
-   sizeof(struct wlan_snap))
-   && (e_llc->dsap == 0xaa)
-   && (e_llc->ssap == 0xaa)
-   && (e_llc->ctl == 0x03)) {
+   sizeof(struct wlan_snap)) &&
+   (e_llc->dsap == 0xaa) &&
+   (e_llc->ssap == 0xaa) &&
+   (e_llc->ctl == 0x03)) {

[PATCH 6/6] drivers/staging/wlan-ng/p80211conv.c: NULL compare fixes

2016-01-08 Thread Pranjal Bhor 
Elegance added to NULL comparisons.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 117dff8..f8eb861 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -562,17 +562,17 @@ void p80211skb_rxmeta_detach(struct sk_buff *skb)
struct p80211_frmmeta *frmmeta;

/* Sanity checks */
-   if (skb == NULL) {  /* bad skb */
+   if (!skb) { /* bad skb */
pr_debug("Called w/ null skb.\n");
return;
}
frmmeta = P80211SKB_FRMMETA(skb);
-   if (frmmeta == NULL) {  /* no magic */
+   if (!frmmeta) { /* no magic */
pr_debug("Called w/ bad frmmeta magic.\n");
return;
}
rxmeta = frmmeta->rx;
-   if (rxmeta == NULL) {   /* bad meta ptr */
+   if (!rxmeta) {  /* bad meta ptr */
pr_debug("Called w/ bad rxmeta ptr.\n");
return;
}
@@ -608,7 +608,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)
struct p80211_frmmeta *frmmeta;

/* If these already have metadata, we error out! */
-   if (P80211SKB_RXMETA(skb) != NULL) {
+   if (P80211SKB_RXMETA(skb)) {
netdev_err(wlandev->netdev,
   "%s: RXmeta already attached!\n", wlandev->name);
result = 0;
@@ -618,7 +618,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)
/* Allocate the rxmeta */
rxmeta = kzalloc(sizeof(struct p80211_rxmeta), GFP_ATOMIC);

-   if (rxmeta == NULL) {
+   if (!rxmeta) {
netdev_err(wlandev->netdev,
   "%s: Failed to allocate rxmeta.\n", wlandev->name);
result = 1;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/6] drivers/staging/wlan-ng/p80211conv.c: Open parenthesis alignemnt fix

2016-01-08 Thread Pranjal Bhor 
Alignments on new lines have been matched with the open parenthesis.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 19801df..117dff8 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -215,8 +215,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
  p80211_wep->iv, p80211_wep->icv);
if (foo) {
netdev_warn(wlandev->netdev,
-  "Host en-WEP failed, dropping frame (%d).\n",
-  foo);
+   "Host en-WEP failed, dropping frame 
(%d).\n",
+   foo);
return 2;
}
fc |= cpu_to_le16(WLAN_SET_FC_ISWEP(1));
@@ -330,10 +330,10 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
return 1;
}
foo = wep_decrypt(wlandev, skb->data + payload_offset + 4,
-  payload_length - 8, -1,
-  skb->data + payload_offset,
-  skb->data + payload_offset +
-  payload_length - 4);
+ payload_length - 8, -1,
+ skb->data + payload_offset,
+ skb->data + payload_offset +
+ payload_length - 4);
if (foo) {
/* de-wep failed, drop skb. */
pr_debug("Host de-WEP failed, dropping frame (%d).\n",
@@ -371,7 +371,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been encap'd. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "ENCAP frame too large (%d > %d)\n",
-  payload_length, netdev->mtu + ETH_HLEN);
+  payload_length, netdev->mtu + ETH_HLEN);
return 1;
}

@@ -400,7 +400,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "SNAP frame too large (%d > %d)\n",
-  payload_length, netdev->mtu);
+  payload_length, netdev->mtu);
return 1;
}

@@ -433,9 +433,9 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "DIXII frame too large (%ld > %d)\n",
-  (long int)(payload_length -
-   sizeof(struct wlan_llc) -
-   sizeof(struct wlan_snap)), netdev->mtu);
+  (long int)(payload_length -
+  sizeof(struct wlan_llc) -
+  sizeof(struct wlan_snap)), netdev->mtu);
return 1;
}

@@ -468,7 +468,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
/* A bogus length ethfrm has been sent. */
/* Is someone trying an oflow attack? */
netdev_err(netdev, "OTHER frame too large (%d > %d)\n",
-  payload_length, netdev->mtu);
+  payload_length, netdev->mtu);
return 1;
}

--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/6] drivers/staging/wlan-ng/p80211conv.c: Spaces after casting operators removed

2016-01-08 Thread Pranjal Bhor 
Spaces after the casting operators have been removed.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 2a6e818..19801df 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -149,7 +149,7 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

/* tack on SNAP */
e_snap =
-   (struct wlan_snap *) skb_push(skb,
+   (struct wlan_snap *)skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
if (ethconv == WLAN_ETHCONV_8021h &&
@@ -163,7 +163,7 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

/* tack on llc */
e_llc =
-   (struct wlan_llc *) skb_push(skb,
+   (struct wlan_llc *)skb_push(skb,
sizeof(struct wlan_llc));
e_llc->dsap = 0xAA; /* SNAP, see IEEE 802 */
e_llc->ssap = 0xAA;
@@ -294,7 +294,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
payload_length = skb->len - WLAN_HDR_A3_LEN - WLAN_CRC_LEN;
payload_offset = WLAN_HDR_A3_LEN;

-   w_hdr = (union p80211_hdr *) skb->data;
+   w_hdr = (union p80211_hdr *)skb->data;

/* setup some vars for convenience */
fc = le16_to_cpu(w_hdr->a3.fc);
@@ -352,11 +352,11 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
wlandev->rx.decrypt++;
}

-   e_hdr = (struct wlan_ethhdr *) (skb->data + payload_offset);
+   e_hdr = (struct wlan_ethhdr *)(skb->data + payload_offset);

-   e_llc = (struct wlan_llc *) (skb->data + payload_offset);
+   e_llc = (struct wlan_llc *)(skb->data + payload_offset);
e_snap =
-   (struct wlan_snap *) (skb->data + payload_offset +
+   (struct wlan_snap *)(skb->data + payload_offset +
sizeof(struct wlan_llc));

/* Test for the various encodings */
@@ -631,7 +631,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)

/* Overlay a frmmeta_t onto skb->cb */
memset(skb->cb, 0, sizeof(struct p80211_frmmeta));
-   frmmeta = (struct p80211_frmmeta *) (skb->cb);
+   frmmeta = (struct p80211_frmmeta *)(skb->cb);
frmmeta->magic = P80211_FRMMETA_MAGIC;
frmmeta->rx = rxmeta;
 exit:
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-08 Thread KY Srinivasan 


> -Original Message-
> From: John Fastabend [mailto:john.fastab...@gmail.com]
> Sent: Thursday, January 7, 2016 10:17 PM
> To: KY Srinivasan ; Vitaly Kuznetsov
> ; Simon Xiao ; Eric Dumazet
> 
> Cc: Tom Herbert ; net...@vger.kernel.org;
> Haiyang Zhang ; de...@linuxdriverproject.org;
> linux-ker...@vger.kernel.org; David Miller 
> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct
> flow_keys layout
> 
> On 16-01-07 07:49 PM, KY Srinivasan wrote:
> >
> >
> >> -Original Message-
> >> From: John Fastabend [mailto:john.fastab...@gmail.com]
> >> Sent: Thursday, January 7, 2016 5:02 PM
> >> To: Vitaly Kuznetsov ; Simon Xiao
> >> ; Eric Dumazet 
> >> Cc: Tom Herbert ; net...@vger.kernel.org; KY
> >> Srinivasan ; Haiyang Zhang
> ;
> >> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; David Miller
> >> 
> >> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on
> struct
> >> flow_keys layout
> >>
> >> On 16-01-07 05:28 AM, Vitaly Kuznetsov wrote:
> >>> Eric Dumazet  writes:
> >>>
>  On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> > Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net:
> Add
> >  VLAN ID to flow_keys")) introduced a performance regression in
> netvsc
> > driver. Is problem is, however, not the above mentioned commit but
> the
> > fact that netvsc_set_hash() function did some assumptions on the
> struct
> > flow_keys data layout and this is wrong. We need to extract the data
> we
> > need (src/dst addresses and ports) after the dissect.
> >
> > The issue could also be solved in a completely different way: as
> suggested
> > by Eric instead of our own homegrown netvsc_set_hash() we could
> use
> > skb_get_hash() which does more or less the same. Unfortunately,
> the
> > testing done by Simon showed that Hyper-V hosts are not happy with
> our
> > Jenkins hash, selecting the output queue with the current algorithm
> based
> > on Toeplitz hash works significantly better.
> 
> >>
> >> Also can I ask the maybe naive question. It looks like the hypervisor
> >> is populating some table via a mailbox msg and this is used to select
> >> the queues I guess with some sort of weighting function?
> >>
> >> What happens if you just remove select_queue altogether? Or maybe
> just
> >> what is this 16 entry table doing? How does this work on my larger
> >> systems with 64+ cores can I only use 16 cores? Sorry I really have
> >> no experience with hyperV and this got me curious.
> >
> > We will limit the number of VRSS channels to the number of CPUs in
> > a NUMA node. If the number of CPUs in a NUMA node exceeds 8, we
> > will only open up 8 VRSS channels. On the host side currently traffic
> > spreading is done in software and we have found that limiting to 8 CPUs
> > gives us the best throughput. In Windows Server 2016, we will be
> > distributing traffic on the host in hardware; the heuristics in the guest
> > may change.
> >
> > Regards,
> >
> > K. Y
> 
> I think a better way to do this would be to query the numa node when
> the interface comes online via dev_to_node() and then use cpu_to_node()
> or create/find some better variant to get a list of cpus on the numa
> node.
> 
> At this point you can use the xps mapping interface
> netif_set_xps_queue() to get the right queue to cpu binding. If you want
> to cap it to max 8 queues that works as well. I don't think there is
> any value to have more tx queues than number of cpus in use.
> 
> If you do it this way all the normal mechanisms to setup queue mappings
> will work for users who are doing some special configuration and the
> default will still be what you want.
> 
> I guess I should go do this numa mapping for ixgbe and friends now that
> I mention it. Last perf numbers I had showed cross numa affinitizing
> was pretty bad.
> 
> Thanks,
> John
John,

I am little confused. In the guest, we need to first open the sub-channels 
(VRSS queues) based on what the host is offering. While we cannot open more 
sub-channels than what the host is offering, the guest can certainly open fewer 
sub-channels. I was describing the heuristics for how many sub-channels the 
guest currently opens. This is based on the NUMA topology presented to the 
guest and the number of VCPUs provisioned for the guest. The binding of VCPUs 
to the channels occur at the point of opening these channels.

Regards,

K. Y 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/6] drivers/staging/wlan-ng/p80211conv.c: Fixed block comment coding style

2016-01-08 Thread Dan Carpenter 
On Sat, Jan 09, 2016 at 12:20:48AM +0530, Pranjal wrote:
> 
> 
> On Friday 08 January 2016 11:42 PM, Dan Carpenter wrote:
> >You're almost there...  Just resend with the correct patch prefix.
> >
> >[PATCH 1/6] Staging: wlan-ng: Fixed block comment coding style in 
> >p80211conv.c
> >
> >regards,
> >dan carpenter
> >
> Do you mean to say that instead of
> drivers/staging/wlan-ng/p80211conv.c, I should write only wlan-ng ?

Staging: wlan-ng:

yes.

regards,
dan carpetner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/6] staging: wlan-ng: Spaces after casting operators removed

2016-01-08 Thread Pranjal Bhor 
Spaces after the casting operators have been removed.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 2a6e818..19801df 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -149,7 +149,7 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

/* tack on SNAP */
e_snap =
-   (struct wlan_snap *) skb_push(skb,
+   (struct wlan_snap *)skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
if (ethconv == WLAN_ETHCONV_8021h &&
@@ -163,7 +163,7 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

/* tack on llc */
e_llc =
-   (struct wlan_llc *) skb_push(skb,
+   (struct wlan_llc *)skb_push(skb,
sizeof(struct wlan_llc));
e_llc->dsap = 0xAA; /* SNAP, see IEEE 802 */
e_llc->ssap = 0xAA;
@@ -294,7 +294,7 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
payload_length = skb->len - WLAN_HDR_A3_LEN - WLAN_CRC_LEN;
payload_offset = WLAN_HDR_A3_LEN;

-   w_hdr = (union p80211_hdr *) skb->data;
+   w_hdr = (union p80211_hdr *)skb->data;

/* setup some vars for convenience */
fc = le16_to_cpu(w_hdr->a3.fc);
@@ -352,11 +352,11 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
wlandev->rx.decrypt++;
}

-   e_hdr = (struct wlan_ethhdr *) (skb->data + payload_offset);
+   e_hdr = (struct wlan_ethhdr *)(skb->data + payload_offset);

-   e_llc = (struct wlan_llc *) (skb->data + payload_offset);
+   e_llc = (struct wlan_llc *)(skb->data + payload_offset);
e_snap =
-   (struct wlan_snap *) (skb->data + payload_offset +
+   (struct wlan_snap *)(skb->data + payload_offset +
sizeof(struct wlan_llc));

/* Test for the various encodings */
@@ -631,7 +631,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)

/* Overlay a frmmeta_t onto skb->cb */
memset(skb->cb, 0, sizeof(struct p80211_frmmeta));
-   frmmeta = (struct p80211_frmmeta *) (skb->cb);
+   frmmeta = (struct p80211_frmmeta *)(skb->cb);
frmmeta->magic = P80211_FRMMETA_MAGIC;
frmmeta->rx = rxmeta;
 exit:
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/6] staging: wlan-ng: Logical continuation fix

2016-01-08 Thread Pranjal Bhor 
Logical continuation added to the 'if', 'else if' and 'else' blocks.
Logical operators now follow after conditions on the same line.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 47 ++--
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 8175f17..5a6d1d5 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -153,8 +153,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
(struct wlan_snap *) skb_push(skb,
sizeof(struct wlan_snap));
e_snap->type = htons(proto);
-   if (ethconv == WLAN_ETHCONV_8021h
-   && p80211_stt_findproto(proto)) {
+   if (ethconv == WLAN_ETHCONV_8021h &&
+   p80211_stt_findproto(proto)) {
memcpy(e_snap->oui, oui_8021h,
   WLAN_IEEE_OUI_LEN);
} else {
@@ -204,8 +204,8 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,

p80211_wep->data = NULL;

-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED)
-   && (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   (wlandev->hostwep & HOSTWEP_ENCRYPT)) {
/*  need to pick keynum other than default? */

p80211_wep->data = kmalloc(skb->len, GFP_ATOMIC);
@@ -304,12 +304,12 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
if ((WLAN_GET_FC_TODS(fc) == 0) && (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a2);
-   } else if ((WLAN_GET_FC_TODS(fc) == 0)
-   && (WLAN_GET_FC_FROMDS(fc) == 1)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 0) &&
+  (WLAN_GET_FC_FROMDS(fc) == 1)) {
ether_addr_copy(daddr, w_hdr->a3.a1);
ether_addr_copy(saddr, w_hdr->a3.a3);
-   } else if ((WLAN_GET_FC_TODS(fc) == 1)
-   && (WLAN_GET_FC_FROMDS(fc) == 0)) {
+   } else if ((WLAN_GET_FC_TODS(fc) == 1) &&
+  (WLAN_GET_FC_FROMDS(fc) == 0)) {
ether_addr_copy(daddr, w_hdr->a3.a3);
ether_addr_copy(saddr, w_hdr->a3.a2);
} else {
@@ -324,8 +324,9 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
}

/* perform de-wep if necessary.. */
-   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) && WLAN_GET_FC_ISWEP(fc)
-   && (wlandev->hostwep & HOSTWEP_DECRYPT)) {
+   if ((wlandev->hostwep & HOSTWEP_PRIVACYINVOKED) &&
+   WLAN_GET_FC_ISWEP(fc) &&
+   (wlandev->hostwep & HOSTWEP_DECRYPT)) {
if (payload_length <= 8) {
netdev_err(netdev,
   "WEP frame too short (%u).\n", skb->len);
@@ -383,15 +384,15 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
skb_trim(skb, skb->len - WLAN_CRC_LEN);

} else if ((payload_length >= sizeof(struct wlan_llc) +
-   sizeof(struct wlan_snap))
-   && (e_llc->dsap == 0xaa)
-   && (e_llc->ssap == 0xaa)
-   && (e_llc->ctl == 0x03)
-  &&
-  (((memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) == 0)
-&& (ethconv == WLAN_ETHCONV_8021h)
-&& (p80211_stt_findproto(le16_to_cpu(e_snap->type
-   || (memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) !=
+   sizeof(struct wlan_snap)) &&
+   (e_llc->dsap == 0xaa) &&
+   (e_llc->ssap == 0xaa) &&
+   (e_llc->ctl == 0x03) &&
+   (((memcmp(e_snap->oui, oui_rfc1042,
+   WLAN_IEEE_OUI_LEN) == 0) &&
+   (ethconv == WLAN_ETHCONV_8021h) &&
+   (p80211_stt_findproto(le16_to_cpu(e_snap->type ||
+   (memcmp(e_snap->oui, oui_rfc1042, WLAN_IEEE_OUI_LEN) !=
0))) {
pr_debug("SNAP+RFC1042 len: %d\n", payload_length);
/* it's a SNAP + RFC1042 frame && protocol is in STT */
@@ -419,10 +420,10 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
skb_trim(skb, skb->len - WLAN_CRC_LEN);

} else if ((payload_length >= sizeof(struct wlan_llc) +
-   sizeof(struct wlan_snap))
-   && (e_llc->dsap == 0xaa)
-   && (e_llc->ssap == 0xaa)
-   && (e_llc->ctl == 0x03)) {
+   sizeof(struct wlan_snap)) &&
+   (e_llc->dsap == 0xaa) &&
+   (e_llc->ssap == 0xaa) &&
+   (e_llc->ctl == 0x03)) {

[PATCH 6/6] staging: wlan-ng: NULL compare fixes

2016-01-08 Thread Pranjal Bhor 
Elegance added to NULL comparisons.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 117dff8..f8eb861 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -562,17 +562,17 @@ void p80211skb_rxmeta_detach(struct sk_buff *skb)
struct p80211_frmmeta *frmmeta;

/* Sanity checks */
-   if (skb == NULL) {  /* bad skb */
+   if (!skb) { /* bad skb */
pr_debug("Called w/ null skb.\n");
return;
}
frmmeta = P80211SKB_FRMMETA(skb);
-   if (frmmeta == NULL) {  /* no magic */
+   if (!frmmeta) { /* no magic */
pr_debug("Called w/ bad frmmeta magic.\n");
return;
}
rxmeta = frmmeta->rx;
-   if (rxmeta == NULL) {   /* bad meta ptr */
+   if (!rxmeta) {  /* bad meta ptr */
pr_debug("Called w/ bad rxmeta ptr.\n");
return;
}
@@ -608,7 +608,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)
struct p80211_frmmeta *frmmeta;

/* If these already have metadata, we error out! */
-   if (P80211SKB_RXMETA(skb) != NULL) {
+   if (P80211SKB_RXMETA(skb)) {
netdev_err(wlandev->netdev,
   "%s: RXmeta already attached!\n", wlandev->name);
result = 0;
@@ -618,7 +618,7 @@ int p80211skb_rxmeta_attach(struct wlandevice *wlandev, 
struct sk_buff *skb)
/* Allocate the rxmeta */
rxmeta = kzalloc(sizeof(struct p80211_rxmeta), GFP_ATOMIC);

-   if (rxmeta == NULL) {
+   if (!rxmeta) {
netdev_err(wlandev->netdev,
   "%s: Failed to allocate rxmeta.\n", wlandev->name);
result = 1;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/6] staging: wlan-ng: Unnecessary blank lines removed

2016-01-08 Thread Pranjal Bhor 
Blank lines after opening curly braces and before closing curly
braces have been removed.

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 5a6d1d5..2a6e818 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -108,7 +108,6 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb, union p80211_hdr *p80211_hdr,
struct p80211_metawep *p80211_wep)
 {
-
__le16 fc;
u16 proto;
struct wlan_ethhdr e_hdr;
@@ -169,7 +168,6 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
e_llc->dsap = 0xAA; /* SNAP, see IEEE 802 */
e_llc->ssap = 0xAA;
e_llc->ctl = 0x03;
-
}
}

@@ -244,7 +242,6 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
 */

for (i = 0; i < wlandev->spy_number; i++) {
-
if (!memcmp(wlandev->spy_address[i], mac, ETH_ALEN)) {
memcpy(wlandev->spy_address[i], mac, ETH_ALEN);
wlandev->spy_stat[i].level = rxmeta->signal;
@@ -486,7 +483,6 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,

/* chop off the 802.11 CRC */
skb_trim(skb, skb->len - WLAN_CRC_LEN);
-
}

/*
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/6] staging: wlan-ng: Fixed block comment coding style

2016-01-08 Thread Pranjal Bhor 
Block comments now end with '*/' on a newline and all lines
of block comments now begin with '*'

Signed-off-by: Pranjal Bhor 
---
 drivers/staging/wlan-ng/p80211conv.c | 37 ++--
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/wlan-ng/p80211conv.c 
b/drivers/staging/wlan-ng/p80211conv.c
index 1b02cdf..8175f17 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -49,7 +49,8 @@
 *
 * 
 *
-* */
+*
+*/

 #include 
 #include 
@@ -101,7 +102,8 @@ static u8 oui_8021h[] = { 0x00, 0x00, 0xf8 };
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int skb_ether_to_p80211(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb, union p80211_hdr *p80211_hdr,
struct p80211_metawep *p80211_wep)
@@ -238,7 +240,8 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
int i;

/* Gather wireless spy statistics: for each packet, compare the
-* source address with out list, and if match, get the stats... */
+* source address with out list, and if match, get the stats...
+*/

for (i = 0; i < wlandev->spy_number; i++) {

@@ -273,7 +276,8 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char 
*mac,
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
struct sk_buff *skb)
 {
@@ -421,7 +425,8 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 ethconv,
&& (e_llc->ctl == 0x03)) {
pr_debug("802.1h/RFC1042 len: %d\n", payload_length);
/* it's an 802.1h frame || (an RFC1042 && protocol not in STT)
-  build a DIXII + RFC894 */
+* build a DIXII + RFC894
+*/

/* Test for an overlength frame */
if ((payload_length - sizeof(struct wlan_llc) -
@@ -521,14 +526,15 @@ int skb_p80211_to_ether(wlandevice_t *wlandev, u32 
ethconv,
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int p80211_stt_findproto(u16 proto)
 {
-   /* Always return found for now.  This is the behavior used by the */
-   /*  Zoom Win95 driver when 802.1h mode is selected */
-   /* TODO: If necessary, add an actual search we'll probably
-  need this to match the CMAC's way of doing things.
-  Need to do some testing to confirm.
+   /* Always return found for now.  This is the behavior used by the
+* Zoom Win95 driver when 802.1h mode is selected
+* TODO: If necessary, add an actual search we'll probably
+* need this to match the CMAC's way of doing things.
+* Need to do some testing to confirm.
 */

if (proto == ETH_P_AARP)/* APPLETALK */
@@ -551,7 +557,8 @@ int p80211_stt_findproto(u16 proto)
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 void p80211skb_rxmeta_detach(struct sk_buff *skb)
 {
struct p80211_rxmeta *rxmeta;
@@ -595,7 +602,8 @@ void p80211skb_rxmeta_detach(struct sk_buff *skb)
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 int p80211skb_rxmeta_attach(struct wlandevice *wlandev, struct sk_buff *skb)
 {
int result = 0;
@@ -648,7 +656,8 @@ exit:
 *
 * Call context:
 *  May be called in interrupt or non-interrupt context
-*/
+*
+*/
 void p80211skb_free(struct wlandevice *wlandev, struct sk_buff *skb)
 {
struct p80211_frmmeta *meta;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

2016-01-08 Thread KY Srinivasan 


> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Friday, January 8, 2016 12:27 PM
> To: KY Srinivasan ; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Cc: sta...@vger.kernel.org
> Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error
> handling function
> 
> On Fri, 2016-01-08 at 20:12 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com
> > > ]
> > > Sent: Friday, January 8, 2016 11:21 AM
> > > To: KY Srinivasan ; gre...@linuxfoundation.org;
> > > linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > oher...@suse.com;
> > > jbottom...@parallels.com; h...@infradead.org;
> > > linux-s...@vger.kernel.org;
> > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > martin.peter...@oracle.com; h...@suse.de
> > > Cc: sta...@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the
> > > error
> > > handling function
> > >
> > > On Fri, 2016-01-08 at 18:58 +, KY Srinivasan wrote:
> > > >
> > > > > -Original Message-
> > > > > From: James Bottomley
> > > [mailto:james.bottom...@hansenpartnership.com
> > > > > ]
> > > > > Sent: Thursday, January 7, 2016 3:49 PM
> > > > > To: KY Srinivasan ;
> > > > > gre...@linuxfoundation.org;
> > > > > linux-
> > > > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > > > oher...@suse.com;
> > > > > jbottom...@parallels.com; h...@infradead.org;
> > > > > linux-s...@vger.kernel.org;
> > > > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > > > martin.peter...@oracle.com; h...@suse.de
> > > > > Cc: sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in
> > > > > the
> > > > > error
> > > > > handling function
> > > > >
> > > > > On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > > > > > The macro startget_to_rport() can return NULL; handle that
> > > > > > case
> > > > > > properly.
> > > > >
> > > > > OK, can we unwind why you think you could possibly need this?
> > > > >  It
> > > > > would
> > > > > mean that fc_timed_out was called for a non-FC device, which
> > > > > was
> > > > > thought to be an impossibility when the fc transport class was
> > > > > designed.
> > > >
> > > > As you know, on Hyper-V, FC devices are handled exactly like
> > > > normal
> > > > scsi devices and the only additional information that is provided
> > > > for
> > > > FC devices is the WWN for port and node. Till recently, I was not
> > > > publishing the WWN in the guest and so I was not even using the
> > > > FC
> > > > transport. Recently, I implemented support for publishing the WWN
> > > > in
> > > > the guest and for that I am using the FC transport for FC hosts.
> > > > When
> > > > an FC LUN is dynamically removed, sometimes I see the timeout
> > > > occurri
> > > > ng and since there is no rport associated with these devices I am
> > > > hitting the issue this patch is addressing. I could have
> > > > addressed
> > > > this problem by establishing a storvsc specific time out function
> > > > even for FC devices - the same timeout function that I currently
> > > > use
> > > > for scsi devices -  storvsc_eh_timed_out(). I chose to instead
> > > > fix
> > > > the fc_timed_out() function since the code was not handling a
> > > > possible condition.
> > >
> > > OK, so the specific problem is that the device is partly torn down
> > > when
> > > the timeout fires?  I'm having a hard time seeing how we get a null
> > > rport in that case.  The starget_to_rport() can only return NULL if
> > > the
> > > parent isn't an rport ... that shouldn't depend on the state of the
> > > FC
> > > device because the parent is torn down after the child.
> >
> > In our case, the parent is not an rport since I don't invoke
> > fc_remote_port_add() and so I do get a NULL value from the
> > starget_to_rport().
> 
> OK, so it's nothing to do with teardown? I'm going to need the FC
> people to comment on this.  The transport class was apparently designed
> to allow use without rports.  However, there are several places where
> we assume rports are present:  The times out and the port block
> interface ... I'm betting all current users are rport otherwise we
> would have spotted this problem sooner.
> 
> > > In any case, returning BLK_EH_RESET_TIMER will cause all sorts of
> > > problems because it resets the timer to fire again for the device.
> > >  What you want is something to return BLK_EH_HANDLED which will
> > > just
> > > complete the request ... probably at a generic level, since this
> >

Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

2016-01-08 Thread James Bottomley 
On Fri, 2016-01-08 at 20:12 +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com
> > ]
> > Sent: Friday, January 8, 2016 11:21 AM
> > To: KY Srinivasan ; gre...@linuxfoundation.org;
> > linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; 
> > oher...@suse.com;
> > jbottom...@parallels.com; h...@infradead.org; 
> > linux-s...@vger.kernel.org;
> > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > martin.peter...@oracle.com; h...@suse.de
> > Cc: sta...@vger.kernel.org
> > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the
> > error
> > handling function
> > 
> > On Fri, 2016-01-08 at 18:58 +, KY Srinivasan wrote:
> > > 
> > > > -Original Message-
> > > > From: James Bottomley
> > [mailto:james.bottom...@hansenpartnership.com
> > > > ]
> > > > Sent: Thursday, January 7, 2016 3:49 PM
> > > > To: KY Srinivasan ; 
> > > > gre...@linuxfoundation.org;
> > > > linux-
> > > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > > oher...@suse.com;
> > > > jbottom...@parallels.com; h...@infradead.org;
> > > > linux-s...@vger.kernel.org;
> > > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > > martin.peter...@oracle.com; h...@suse.de
> > > > Cc: sta...@vger.kernel.org
> > > > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in
> > > > the
> > > > error
> > > > handling function
> > > > 
> > > > On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > > > > The macro startget_to_rport() can return NULL; handle that
> > > > > case
> > > > > properly.
> > > > 
> > > > OK, can we unwind why you think you could possibly need this? 
> > > >  It
> > > > would
> > > > mean that fc_timed_out was called for a non-FC device, which
> > > > was
> > > > thought to be an impossibility when the fc transport class was
> > > > designed.
> > > 
> > > As you know, on Hyper-V, FC devices are handled exactly like
> > > normal
> > > scsi devices and the only additional information that is provided
> > > for
> > > FC devices is the WWN for port and node. Till recently, I was not
> > > publishing the WWN in the guest and so I was not even using the
> > > FC
> > > transport. Recently, I implemented support for publishing the WWN
> > > in
> > > the guest and for that I am using the FC transport for FC hosts.
> > > When
> > > an FC LUN is dynamically removed, sometimes I see the timeout
> > > occurri
> > > ng and since there is no rport associated with these devices I am
> > > hitting the issue this patch is addressing. I could have
> > > addressed
> > > this problem by establishing a storvsc specific time out function
> > > even for FC devices - the same timeout function that I currently
> > > use
> > > for scsi devices -  storvsc_eh_timed_out(). I chose to instead
> > > fix
> > > the fc_timed_out() function since the code was not handling a
> > > possible condition.
> > 
> > OK, so the specific problem is that the device is partly torn down
> > when
> > the timeout fires?  I'm having a hard time seeing how we get a null
> > rport in that case.  The starget_to_rport() can only return NULL if
> > the
> > parent isn't an rport ... that shouldn't depend on the state of the
> > FC
> > device because the parent is torn down after the child.
> 
> In our case, the parent is not an rport since I don't invoke 
> fc_remote_port_add() and so I do get a NULL value from the
> starget_to_rport().

OK, so it's nothing to do with teardown? I'm going to need the FC
people to comment on this.  The transport class was apparently designed
to allow use without rports.  However, there are several places where
we assume rports are present:  The times out and the port block
interface ... I'm betting all current users are rport otherwise we
would have spotted this problem sooner.

> > In any case, returning BLK_EH_RESET_TIMER will cause all sorts of
> > problems because it resets the timer to fire again for the device.
> >  What you want is something to return BLK_EH_HANDLED which will
> > just
> > complete the request ... probably at a generic level, since this
> > doesn't sound to be specific to FC.
> 
> On Hyper-V, the host implements a variety of recovery strategies and 
> for that reason, the  eh_timed_out handler for standard scsi devices 
> will effectively have infinite timeout value: storvsc_eh_timed_out() 
> just resets the timer. This is the behavior I wanted for the FC
> devices as well.

All the world isn't hyper-v.  If we change something in the generic
interface, it needs to work for everyone.  To me it looks like
fc_timed_out is designed to support the port block function.  If we
assume port block is not supported for non-rport devices, then
fc_timed_out should be returning BLK_EH_NOT_HANDLED for the non-rport
case.

James

___
devel mailing list
de...@linuxdriverproject.org

RE: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-08 Thread Haiyang Zhang 


> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Thursday, January 7, 2016 8:28 AM
> To: Simon Xiao ; Eric Dumazet
> 
> Cc: Tom Herbert ; net...@vger.kernel.org; KY
> Srinivasan ; Haiyang Zhang ;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; David Miller
> 
> Subject: Re: [PATCH net-next] hv_netvsc: don't make assumptions on
> struct flow_keys layout
> 
> Eric Dumazet  writes:
> 
> > On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
> >> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net:
> Add
> >>  VLAN ID to flow_keys")) introduced a performance regression in
> netvsc
> >> driver. Is problem is, however, not the above mentioned commit but
> the
> >> fact that netvsc_set_hash() function did some assumptions on the
> struct
> >> flow_keys data layout and this is wrong. We need to extract the data
> we
> >> need (src/dst addresses and ports) after the dissect.
> >>
> >> The issue could also be solved in a completely different way: as
> suggested
> >> by Eric instead of our own homegrown netvsc_set_hash() we could use
> >> skb_get_hash() which does more or less the same. Unfortunately, the
> >> testing done by Simon showed that Hyper-V hosts are not happy with
> our
> >> Jenkins hash, selecting the output queue with the current algorithm
> based
> >> on Toeplitz hash works significantly better.
> >
> > Were tests done on IPv6 traffic ?
> >
> 
> Simon, could you please test this patch for IPv6 and show us the numbers?
> 
> > Toeplitz hash takes at least 100 ns to hash 12 bytes (one iteration
> per
> > bit : 96 iterations)
> >
> > For IPv6 it is 3 times this, since we have to hash 36 bytes.
> >
> > I do not see how it can compete with skb_get_hash() that directly
> gives
> > skb->hash for local TCP flows.
> >
> 
> My guess is that this is not the bottleneck, something is happening
> behind the scene with out packets in Hyper-V host (e.g. re-distributing
> them to hardware queues?) but I don't know the internals, Microsoft
> folks could probably comment.

The Hyper-V vRSS protocol lets us use the Toeplitz hash algorithm. We are
currently running further tests, including IPv6 too, and will share the 
results when available.

Thanks,
- Haiyang

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error handling function

2016-01-08 Thread KY Srinivasan 


> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Friday, January 8, 2016 11:21 AM
> To: KY Srinivasan ; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com; h...@suse.de
> Cc: sta...@vger.kernel.org
> Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the error
> handling function
> 
> On Fri, 2016-01-08 at 18:58 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: James Bottomley
> [mailto:james.bottom...@hansenpartnership.com
> > > ]
> > > Sent: Thursday, January 7, 2016 3:49 PM
> > > To: KY Srinivasan ; gre...@linuxfoundation.org;
> > > linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > oher...@suse.com;
> > > jbottom...@parallels.com; h...@infradead.org;
> > > linux-s...@vger.kernel.org;
> > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > martin.peter...@oracle.com; h...@suse.de
> > > Cc: sta...@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] scsi: scsi_transport_fc: Fix a bug in the
> > > error
> > > handling function
> > >
> > > On Thu, 2016-01-07 at 16:40 -0800, K. Y. Srinivasan wrote:
> > > > The macro startget_to_rport() can return NULL; handle that case
> > > > properly.
> > >
> > > OK, can we unwind why you think you could possibly need this?  It
> > > would
> > > mean that fc_timed_out was called for a non-FC device, which was
> > > thought to be an impossibility when the fc transport class was
> > > designed.
> >
> > As you know, on Hyper-V, FC devices are handled exactly like normal
> > scsi devices and the only additional information that is provided for
> > FC devices is the WWN for port and node. Till recently, I was not
> > publishing the WWN in the guest and so I was not even using the FC
> > transport. Recently, I implemented support for publishing the WWN in
> > the guest and for that I am using the FC transport for FC hosts. When
> > an FC LUN is dynamically removed, sometimes I see the timeout occurri
> > ng and since there is no rport associated with these devices I am
> > hitting the issue this patch is addressing. I could have addressed
> > this problem by establishing a storvsc specific time out function
> > even for FC devices - the same timeout function that I currently use
> > for scsi devices -  storvsc_eh_timed_out(). I chose to instead fix
> > the fc_timed_out() function since the code was not handling a
> > possible condition.
> 
> OK, so the specific problem is that the device is partly torn down when
> the timeout fires?  I'm having a hard time seeing how we get a null
> rport in that case.  The starget_to_rport() can only return NULL if the
> parent isn't an rport ... that shouldn't depend on the state of the FC
> device because the parent is torn down after the child.

In our case, the parent is not an rport since I don't invoke 
fc_remote_port_add() and
so I do get a NULL value from the starget_to_rport().

> 
> In any case, returning BLK_EH_RESET_TIMER will cause all sorts of
> problems because it resets the timer to fire again for the device.
>  What you want is something to return BLK_EH_HANDLED which will just
> complete the request ... probably at a generic level, since this
> doesn't sound to be specific to FC.

On Hyper-V, the host implements a variety of recovery strategies and for that 
reason,
the  eh_timed_out handler for standard scsi devices will effectively have 
infinite timeout value:
storvsc_eh_timed_out() just resets the timer. This is the behavior I wanted for 
the FC devices as well.

K. Y

> 
> Something like the below ... assuming the teardown issue is the real
> problem.
> 
> James
> 
> ---
> 
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 984ddcb..3c514c6 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -273,6 +273,10 @@ enum blk_eh_timer_return scsi_times_out(struct
> request *req)
>   enum blk_eh_timer_return rtn = BLK_EH_NOT_HANDLED;
>   struct Scsi_Host *host = scmd->device->host;
> 
> + /* timeout for an already dead device, just kill the request */
> + if (scmd->device->sdev_state == SDEV_DEL)
> + return BLK_EH_HANDLED;
> +
>   trace_scsi_dispatch_cmd_timeout(scmd);
>   scsi_log_completion(scmd, TIMEOUT_ERROR);
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Attn: Lucky Winner!

2016-01-08 Thread LOTERIA DE CATALUNYA 




LOTERIA DE CATALUNYA
INTERNATIONAL PROMOTION PROGRAMME/ PRIZE AWARD DEPARTMENT
HEAD OFFICE/ CALLE ARABIO Nº: 67,
PUERTA DE SOL, 08046 BARCELONA, SPAIN.
DATE: 08/01/2016

Attn: Lucky Winner,

We wish to congratulate you over your Email success in our Coca-cola computer
Balloting. Your email address drew and has won you the sum of €935,470.00
( NINE HUNDRED AND THIRTY FIVE  THOUSAND FOUR  HUNDRED AND  SEVENTY  EUROS
ONLY) in COCA-COLA YEAR OF INTERNATIONAL E-MAIL AWARD PROMOTION PROGRAM 
2015.
In cash credited to file with WINNING REFERENCE NUMBER: ETA/3853490/16;
BATCH NUMBER: EURO/1007/444/606/16; LUCKY NUMBER: 23-7-2-6-12-9; SERIAL
NUMBER:6594 and PROMOTION DATE : 18th DECEMBER 2015. All Participants were
selected through a computer ballot system drawn from over 300,000
companies and 600,000 individual email addresses selected from the web. To
claim your winning prize, you are to contact the appointed agent directly
as soon as possible
 for the immediate release of your winnings, with your

7,AGE: .
 LUCKY NUMBER:23-7-2-6-12-9
2,BATCH NUMBER: EURO/1007/444/606/16
3,NAME:
4,ADDRESS:...
5,PHONE AND MOBILE:
6,FAX:.
Barcelona, 08th January 2016.
8,SEX:.
9,OCCUPATION:..
10,COUNTRY:
Fax (If available) To:……

DECA HOUSE SEGUROS S.A.
DR.VEDAL PEREZ
TEL: +34-658-310-731
FAX: +34-911-820-350.
Email:vedalpe...@europe.com

Congratulations once again from all our staff.
Mrs. Lisa Sanchez (Coca cola Lottery CO-Odinator)
International  Lottery commission.
1,WINNING REFERENCE NUMBER:ETA/3853490/16,


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next] hv_netvsc: don't make assumptions on struct flow_keys layout

2016-01-08 Thread Tom Herbert 
On Thu, Jan 7, 2016 at 4:52 AM, Eric Dumazet  wrote:
> On Thu, 2016-01-07 at 10:33 +0100, Vitaly Kuznetsov wrote:
>> Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
>>  VLAN ID to flow_keys")) introduced a performance regression in netvsc
>> driver. Is problem is, however, not the above mentioned commit but the
>> fact that netvsc_set_hash() function did some assumptions on the struct
>> flow_keys data layout and this is wrong. We need to extract the data we
>> need (src/dst addresses and ports) after the dissect.
>>
>> The issue could also be solved in a completely different way: as suggested
>> by Eric instead of our own homegrown netvsc_set_hash() we could use
>> skb_get_hash() which does more or less the same. Unfortunately, the
>> testing done by Simon showed that Hyper-V hosts are not happy with our
>> Jenkins hash, selecting the output queue with the current algorithm based
>> on Toeplitz hash works significantly better.
>
> Were tests done on IPv6 traffic ?
>
> Toeplitz hash takes at least 100 ns to hash 12 bytes (one iteration per
> bit : 96 iterations)
>
> For IPv6 it is 3 times this, since we have to hash 36 bytes.
>
> I do not see how it can compete with skb_get_hash() that directly gives
> skb->hash for local TCP flows.
>
> See commits b73c3d0e4f0e1961e15bec18720e48aabebe2109
> ("net: Save TX flow hash in sock and set in skbuf on xmit")
> and 877d1f6291f8e391237e324be58479a3e3a7407c
> ("net: Set sk_txhash from a random number")
>
> I understand Microsoft loves Toeplitz, but this looks not well placed
> here.
>
+1

We need a little more of an explanation on why "Toeplitz hash works
significantly better" than Jenkins hash. We already know that Toeplitz
is expensive to do in SW and there has been some proposals to optimize
it which don't seem to have been applied to hv_netvsc (I believe Eric
had a good implementation). Assuming skb_get_hash isn't sufficient the
Toeplitz hash should be in a common library anyway, we really don't
want drivers or modules inventing new ways to hash packets this point!

Tom

> I suspect there is another problem.
>
> Please share your numbers and test methodology, and the alternative
> patch Simon tested so that we can double check it.
>
> Thanks.
>
> PS: For the time being this patch can probably be applied on -net tree,
> as it fixes a real bug.
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH v9 4/7] PCI: Add fwnode_handle to pci_sysdata

2016-01-08 Thread Jake Oshins 
> -Original Message-
> From: ja...@microsoft.com [mailto:ja...@microsoft.com]
> Sent: Wednesday, December 9, 2015 2:55 PM
> To: gre...@linuxfoundation.org; KY Srinivasan ; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; vkuzn...@redhat.com; t...@linutronix.de; Haiyang
> Zhang ; marc.zyng...@arm.com;
> bhelg...@google.com; linux-...@vger.kernel.org
> Cc: Jake Oshins 
> Subject: [PATCH v9 4/7] PCI: Add fwnode_handle to pci_sysdata
> 
> From: Jake Oshins 
> 
> This patch adds an fwnode_handle to struct pci_sysdata, which is
> used by the next patch in the series when trying to locate an
> IRQ domain associated with a root PCI bus.
> 
> Signed-off-by: Jake Oshins 
> ---
>  arch/x86/include/asm/pci.h | 15 +++
>  drivers/pci/probe.c|  1 +
>  include/linux/pci.h|  4 
>  3 files changed, 20 insertions(+)
> 
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 4625943..6fc3c7c 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -20,6 +20,9 @@ struct pci_sysdata {
>  #ifdef CONFIG_X86_64
>   void*iommu; /* IOMMU private data */
>  #endif
> +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> + void*fwnode;/* IRQ domain for MSI assignment */
> +#endif
>  };
> 
>  extern int pci_routeirq;
> @@ -32,6 +35,7 @@ extern int noioapicreroute;
>  static inline int pci_domain_nr(struct pci_bus *bus)
>  {
>   struct pci_sysdata *sd = bus->sysdata;
> +
>   return sd->domain;
>  }
> 
> @@ -41,6 +45,17 @@ static inline int pci_proc_domain(struct pci_bus *bus)
>  }
>  #endif
> 
> +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> +static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
> +{
> + struct pci_sysdata *sd = bus->sysdata;
> +
> + return sd->fwnode;
> +}
> +
> +#define pci_root_bus_fwnode  _pci_root_bus_fwnode
> +#endif
> +
>  /* Can be used to override the logic in pci_scan_bus for skipping
> already-configured bus numbers - to be used for buggy BIOSes
> or architectures with incomplete PCI setup by the loader */
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index edb1984..750f907 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "pci.h"
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 6ae25aa..b414422 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1517,6 +1517,10 @@ static inline int pci_get_new_domain_nr(void) {
> return -ENOSYS; }
> 
>  #include 
> 
> +#ifndef pci_root_bus_fwnode
> +#define pci_root_bus_fwnode(bus) ((void)(bus), NULL)
> +#endif
> +
>  /* these helpers provide future and backwards compatibility
>   * for accessing popular PCI BAR info */
>  #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
> --
> 1.9.1


Bjorn, are you willing to take this patch and the next one in the series 
through your tree?  The other patches in this series have already been taken 
into linux-next by either Greg K-H or Thomas Gleixner, or they're dependent on 
these two.  Thomas has suggested that the PCI tree would be the right one to 
incorporate them.

Thanks,
Jake Oshins

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging/ion: Add support to get ion handle from dma buf

2016-01-08 Thread Sudip Mukherjee 
On Thu, Jan 07, 2016 at 11:57:34AM +0300, Dan Carpenter wrote:
> Hm...  Perhaps I should be CC'ing LKML more often.  What's the rule on
> this, should I just send bugfixes to LKML and whitespace changes to only
> subsystem list?

All my patches (whitespace, bugfix, build fail) always has CC to lkml.
Infact, I have setup an alias for that so that i don't have to add lkml
manually everytime.

sm = send-email --cc=linux-ker...@vger.kernel.org

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/6] staging: wlan-ng: Fixed block comment coding style

2016-01-08 Thread Pranjal 



On Saturday 09 January 2016 09:58 AM, Sudip Mukherjee wrote:

On Sat, Jan 09, 2016 at 12:29:21AM +0530, Pranjal Bhor wrote:

Block comments now end with '*/' on a newline and all lines
of block comments now begin with '*'

Signed-off-by: Pranjal Bhor 
---

something is wrong, when I am trying to test the patch, it is not
applying and git says patch is corrupt.

regards
sudip
I have checked it once again but everything seems to be fine. How can I 
reproduce your result?

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] scsi: storvsc: Miscellaneous fixes

2016-01-08 Thread K. Y. Srinivasan 
Some miscellaneous fixes.

K. Y. Srinivasan (2):
  scsi: storvsc: Install the storvsc specific timeout handler for FC
devices
  scsi: storvsc: Use the specified target ID in device lookup

 drivers/scsi/storvsc_drv.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] scsi: storvsc: Install the storvsc specific timeout handler for FC devices

2016-01-08 Thread K. Y. Srinivasan 
The default timeout routine used for FC transport is not
suitable for FC devices managed by storvsc since FC devices
managed by storvsc driver do not have an rport associated
with them. Use the time out handler used for SCSI devices
for FC devices as well.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 41c115c..622f64a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * All wire protocol details (storage protocol between the guest and the host)
@@ -1770,6 +1771,11 @@ static int __init storvsc_drv_init(void)
fc_transport_template = fc_attach_transport(_transport_functions);
if (!fc_transport_template)
return -ENODEV;
+
+   /*
+* Install Hyper-V specific timeout handler.
+*/
+   fc_transport_template->eh_timed_out = storvsc_eh_timed_out;
 #endif
 
ret = vmbus_driver_register(_drv);
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] scsi: storvsc: Use the specified target ID in device lookup

2016-01-08 Thread K. Y. Srinivasan 
The current code assumes that there is only one target in device lookup.
Fix this bug. This will alow us to correctly handle hot reomoval of LUNs.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/scsi/storvsc_drv.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 622f64a..5faf357 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -479,6 +479,7 @@ struct storvsc_scan_work {
struct work_struct work;
struct Scsi_Host *host;
uint lun;
+   uint tgt_id;
 };
 
 static void storvsc_device_scan(struct work_struct *work)
@@ -490,7 +491,7 @@ static void storvsc_device_scan(struct work_struct *work)
wrk = container_of(work, struct storvsc_scan_work, work);
lun = wrk->lun;
 
-   sdev = scsi_device_lookup(wrk->host, 0, 0, lun);
+   sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, lun);
if (!sdev)
goto done;
scsi_rescan_device(>sdev_gendev);
@@ -541,7 +542,7 @@ static void storvsc_remove_lun(struct work_struct *work)
if (!scsi_host_get(wrk->host))
goto done;
 
-   sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun);
+   sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun);
 
if (sdev) {
scsi_remove_device(sdev);
@@ -941,6 +942,7 @@ static void storvsc_handle_error(struct vmscsi_request 
*vm_srb,
 
wrk->host = host;
wrk->lun = vm_srb->lun;
+   wrk->tgt_id = vm_srb->target_id;
INIT_WORK(>work, process_err_fn);
schedule_work(>work);
 }
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch] staging: rdma: shift wrapping bug in c2_get_dma_mr()

2016-01-08 Thread Dan Carpenter 
We should be using all 64 bits of page_list[i] instead of just the lower
32.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rdma/amso1100/c2_provider.c 
b/drivers/staging/rdma/amso1100/c2_provider.c
index de8d10e..ac6a6ff 100644
--- a/drivers/staging/rdma/amso1100/c2_provider.c
+++ b/drivers/staging/rdma/amso1100/c2_provider.c
@@ -361,7 +361,7 @@ static struct ib_mr *c2_get_dma_mr(struct ib_pd *pd, int 
acc)
}
 
for (i = 0; i < pbl_depth; i++)
-   page_list[i] = (i << page_shift);
+   page_list[i] = ((u64)i << page_shift);
 
mr = kmalloc(sizeof(*mr), GFP_KERNEL);
if (!mr) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] staging: rdma: shift wrapping bug in c2_get_dma_mr()

2016-01-08 Thread Christoph Hellwig 
Looks fine.

Doug: what's the status of the staged out drivers?  I thought we were
going to delete them for 4.5?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] storvsc: fix typo in MODULE_PARM_DESC

2016-01-08 Thread Matthew R. Ochs 
Reviewed-by: Matthew R. Ochs  

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: android: Fix brace coding style warning in sync_debug.c

2016-01-08 Thread Bopamo Osaisai 
This is a patch to the sync_debug.c file that rectifies a brace warning
that was found with the checkpatch.pl tool

Signed-off-by: Bopamo Osaisai 
---
 drivers/staging/android/sync_debug.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index f45d13c..02a1649 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -158,9 +158,8 @@ static void sync_print_fence(struct seq_file *s, struct 
sync_fence *fence)
seq_printf(s, "[%p] %s: %s\n", fence, fence->name,
   sync_status_str(atomic_read(>status)));
 
-   for (i = 0; i < fence->num_fences; ++i) {
+   for (i = 0; i < fence->num_fences; ++i)
sync_print_pt(s, fence->cbs[i].sync_pt, true);
-   }
 
spin_lock_irqsave(>wq.lock, flags);
list_for_each_entry(pos, >wq.task_list, task_list) {
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel