Re: [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[Dan Carpenter]

On Fri, Feb 09, 2018 at 12:39:18PM +1100, NeilBrown wrote:
> On Tue, Aug 16 2016, James Simmons wrote:
> 
> >  
> > +static inline bool
> > +lsm_md_eq(const struct lmv_stripe_md *lsm1, const struct lmv_stripe_md 
> > *lsm2)
> > +{
> > +   int idx;
> > +
> > +   if (lsm1->lsm_md_magic != lsm2->lsm_md_magic ||
> > +   lsm1->lsm_md_stripe_count != lsm2->lsm_md_stripe_count ||
> > +   lsm1->lsm_md_master_mdt_index != lsm2->lsm_md_master_mdt_index ||
> > +   lsm1->lsm_md_hash_type != lsm2->lsm_md_hash_type ||
> > +   lsm1->lsm_md_layout_version != lsm2->lsm_md_layout_version ||
> > +   !strcmp(lsm1->lsm_md_pool_name, lsm2->lsm_md_pool_name))
> > +   return false;
> 
> Hi James and all,
>  This patch (8f18c8a48b736c2f in linux) is different from the
>  corresponding patch in lustre-release (60e07b972114df).
> 
> In that patch, the last clause in the 'if' condition is
> 
> +   strcmp(lsm1->lsm_md_pool_name,
> + lsm2->lsm_md_pool_name) != 0)
> 
> Whoever converted it to "!strcmp()" inverted the condition.  This is a
> perfect example of why I absolutely *loathe* the "!strcmp()" construct!!

People think that "if (!strcmp()) " is prefered kernel style but it's
not.

if (foo != NULL) {

The != NULL is a double negative.  I don't think it adds anything.
Some kernel developers like this style because it's explicit about the
type.  I have never seen any bugs caused by this format or solved by
this format.  Anyway checkpatch complains.

if (ret != 0) {

In this situation "ret" is not a number, it's an error code.  The != 0
is a double negative and complicated to think about.  Btw, I sort of
prefer "if (ret)" to "if (ret < 0)", not because of style but it's
easier for Smatch.  No subsystems are totally consistent so the (by
definition inconsistent) "if (ret < 0)" checks cause false positives in
Smatch.

if (len != 0)

This is OK.  "len" is a number.

if (strcmp(one, two) != 0) {

With strcmp() I really prefer == 0 and != 0 because it works like this:

strcmp(one, two) == 0  --> means one == two
strcmp(one, two) < 0   --> means one < two
strcmp(one, two) != 0  --> means one != two

Either style is accepted in the kernel but I think == 0 just makes so
much sense.  I mostly see bugs from this when people are "fixing" the
style from == 0 to !strcmp() so my sample is very biased.  Normally, if
the original author writes the code any bugs are caught in testing so
either way is going to be bug free.

But the only thing that checkpatch complains about is == NULL and
!= NULL.

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

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

[Dan Carpenter]

On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> Fix the dup_sg_table function to initialize the dma_address of the new
> sg list entries instead of the source dma_address entries.
> 
> Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")
> Signed-off-by: Liam Mark 

How did you find this bug?  What are the user visible effects of this
bug?  I'm probably going to ask you to send a v2 patch with a new
changelog depending on the answers to these questions.

regards,
dan carpenter

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

Re: [PATCH] staging: vt6656: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning

[Dan Carpenter]

On Sat, Feb 10, 2018 at 09:46:18PM +0530, Dileep Sankhla wrote:
> Signed-off-by: Dileep Sankhla 

The subject is too long and you need to have a changelog.

regards,
dan carpenter

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

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

[Michael Kelley (EOSG)]

> -Original Message-
> From: KY Srinivasan
> Sent: Sunday, February 11, 2018 5:14 PM

--- snip ---

> > if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
> > u32 pending_sz = READ_ONCE(rbi->ring_buffer-
> > >pending_send_sz);
> >
> > /*
> > +* Ensure the read of write_index in
> > hv_get_bytes_to_write()
> > +* happens after the read of pending_send_sz.
> > +*/
> > +   virt_rmb();
> We can avoid the read barrier by making the initialization of curr_write_sz 
> conditional
> on pending_send_sz being non-zero. Indeed you can make all the signaling code 
> conditional
> on pending_send_sz being non-zero.
> 
> 

I agree that we can immediately test pending_send_sz for zero, and exit
if zero.  A  zero value will be by far the most common path, and would
save executing the read barrier and hv_get_bytes_to_write().  Can also
move the calculation of "delta" to after the test for zero.

But I believe the read barrier is still needed on the path where
pending_send_sz is non-zero.  Just the testing the value of pending_send_sz
doesn't guarantee that the write_index wouldn't be speculatively read,
and potentially out-of-order.   And we have to consider the out-of-order
behaviors on ARM64 as well.

> 
> > +   curr_write_sz = hv_get_bytes_to_write(rbi);
> > +
> > +   /*
> >  * If there was space before we began iteration,
> >  * then host was not blocked. Also handles case where
> >  * pending_sz is zero then host has nothing pending
> >  * and does not need to be signaled.
> >  */
> > -   if (orig_write_sz > pending_sz)
> > +   if (curr_write_sz - delta > pending_sz)
> > return;
> >
> > /* If pending write will not fit, don't give false hope. */
> > -   if (hv_get_bytes_to_write(rbi) < pending_sz)
> > +   if (curr_write_sz <= pending_sz)
> > return;
> > +
> > +   vmbus_setevent(channel);
> > }
> >
> > -   vmbus_setevent(channel);
> >  }
> >  EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
> > --
> > 1.8.3.1

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

Re: [PATCH] staging: lustre: update the TODO list

[Joe Perches]

On Mon, 2018-02-12 at 02:06 +, James Simmons wrote:
> > On Sun, 2018-02-11 at 18:00 -0500, James Simmons wrote:
> > > As more people become involved with the progression of the lustre
> > > client it needs to more clear what needs to be done to leave
> > > staging. Update the TODO list with the various bugs and changes
> > > to accomplish this. Some are simple bugs and others are far more
> > > complex task that will change many lines of code. Some even cover
> > > updating the user land utilities to meet the kernel requirements.
> > > Several bugs have already been addressed and just need to be
> > > pushed to the staging tree.
> > 
> > Nice list.
> 
> Thanks. Its nice to have a direction :-)
> 
> > Are or should those entries that have been addressed
> > also in this new list?
> 
> Do you mean by those entries what originally was in the
> TODO list or what has been fixed over the last 2 years?

My reading of

> Several bugs have already been addressed and just need to be
> pushed to the staging tree.

is that the new list contains entries for things
that have already been fixed but have not yet
been pushed to the staging tree.

So, if there are entries in the new TODO list
that really are fixed, but not yet posted, then
marking those entries as TODO seems inappropriate.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: lustre: update the TODO list

[James Simmons]

> On Sun, 2018-02-11 at 18:00 -0500, James Simmons wrote:
> > As more people become involved with the progression of the lustre
> > client it needs to more clear what needs to be done to leave
> > staging. Update the TODO list with the various bugs and changes
> > to accomplish this. Some are simple bugs and others are far more
> > complex task that will change many lines of code. Some even cover
> > updating the user land utilities to meet the kernel requirements.
> > Several bugs have already been addressed and just need to be
> > pushed to the staging tree.
> 
> Nice list.

Thanks. Its nice to have a direction :-)

> Are or should those entries that have been addressed
> also in this new list?

Do you mean by those entries what originally was in the
TODO list or what has been fixed over the last 2 years?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

[KY Srinivasan]

> -Original Message-
> From: Michael Kelley [mailto:mhkel...@outlook.com]
> Sent: Saturday, February 10, 2018 12:49 PM
> To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> vkuzn...@redhat.com; jasow...@redhat.com;
> leann.ogasaw...@canonical.com; marcelo.ce...@canonical.com; Stephen
> Hemminger ; KY Srinivasan
> 
> Cc: Michael Kelley (EOSG) 
> Subject: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling
> 
> Fix bugs in signaling the Hyper-V host when freeing space in the
> host->guest ring buffer:
> 
> 1. The interrupt_mask must not be used to determine whether to signal
>on the host->guest ring buffer
> 2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
>*after* pending_send_sz is read in order to avoid a race condition
> 3. Comparisons with pending_send_sz must treat the "equals" case as
>not-enough-space
> 4. Don't signal if the pending_send_sz feature is not present. Older
>versions of Hyper-V that don't implement this feature will poll.
> 
> Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
> Signed-off-by: Michael Kelley 
> ---
>  drivers/hv/ring_buffer.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 50e0714..b64be18 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -423,7 +423,11 @@ struct vmpacket_descriptor *
>  void hv_pkt_iter_close(struct vmbus_channel *channel)
>  {
>   struct hv_ring_buffer_info *rbi = >inbound;
> - u32 orig_write_sz = hv_get_bytes_to_write(rbi);
> + u32 curr_write_sz;
> + u32 delta = rbi->ring_buffer->read_index < rbi->priv_read_index ?
> + (rbi->priv_read_index - rbi->ring_buffer-
> >read_index) :
> + (rbi->ring_datasize - rbi->ring_buffer->read_index +
> + rbi->priv_read_index);
> 
>   /*
>* Make sure all reads are done before we update the read index
> since
> @@ -446,27 +450,31 @@ void hv_pkt_iter_close(struct vmbus_channel
> *channel)
>*/
>   virt_mb();
> 
> - /* If host has disabled notifications then skip */
> - if (rbi->ring_buffer->interrupt_mask)
> - return;
> -
>   if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
>   u32 pending_sz = READ_ONCE(rbi->ring_buffer-
> >pending_send_sz);
> 
>   /*
> +  * Ensure the read of write_index in
> hv_get_bytes_to_write()
> +  * happens after the read of pending_send_sz.
> +  */
> + virt_rmb();
We can avoid the read barrier by making the initialization of curr_write_sz 
conditional
on pending_send_sz being non-zero. Indeed you can make all the signaling code 
conditional
on pending_send_sz being non-zero.



> + curr_write_sz = hv_get_bytes_to_write(rbi);
> +
> + /*
>* If there was space before we began iteration,
>* then host was not blocked. Also handles case where
>* pending_sz is zero then host has nothing pending
>* and does not need to be signaled.
>*/
> - if (orig_write_sz > pending_sz)
> + if (curr_write_sz - delta > pending_sz)
>   return;
> 
>   /* If pending write will not fit, don't give false hope. */
> - if (hv_get_bytes_to_write(rbi) < pending_sz)
> + if (curr_write_sz <= pending_sz)
>   return;
> +
> + vmbus_setevent(channel);
>   }
> 
> - vmbus_setevent(channel);
>  }
>  EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
> --
> 1.8.3.1

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

Re: [lustre-devel] [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[Oleg Drokin]

> On Feb 11, 2018, at 6:44 PM, NeilBrown  wrote:
> 
> On Thu, Feb 08 2018, Oleg Drokin wrote:
>> 
>> Certain things that sound useless (like the debug subsystem in Lustre)
>> is very useful when you have a 10k nodes in a cluster and need to selectively
>> pull stuff from a run to debug a complicated cross-node interaction.
>> I asked NFS people how do they do it and they don’t have anything that scales
>> and usually involves reducing the problem to a much smaller set of nodes 
>> first.
> 
> the "rpcdebug" stuff that Linux/nfs has is sometimes useful, but some parts
> are changing to tracepoints and some parts have remained, which is a
> little confusing.
> 
> The fact that lustre tracing seems to *always* log everything so that if
> something goes wrong you can extract that last few meg(?) of logs seems
> really useful.

Not really. Lustre also has a bitmask for logs (since otherwise all those prints
are pretty cpu taxing), but what makes those logs better is:
the size is unlimited, not constrained by dmesg buffer size.
You can capture those logs from a crashdump (something I really wish
somebody would implement for tracepoint buffers, but alas, I have not
found anything for this yet - we have a crash plugin to extract lustre
debug logs from a kernel crashdump).
>>> 
>>> Even if it is horrible it would be nice to have it in staging... I guess
>>> the changes required to ext4 prohibit that... I don't suppose it can be
>>> made to work with mainline ext4 in a reduced-functionality-and-performance
>>> way??
>> 
>> We support unpatched ZFS as a server too! ;)
> 
> So that that mean you would expect lustre-server to work with unpatched
> ext4? In that case I won't give up hope of seeing the server in mainline
> in my lifetime.  Client first though.

While unpatched ext4 might in theory be possible, currently it does not export
everything we need from the transaction/fs control perspective.

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

[PATCH 03/12] hv: Synthetic typo correction

[kys]

From: Joe Perches 

Just a trivial tyop fix.

Signed-off-by: Joe Perches 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index b6cacc4cccf2..31142b72f1b9 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -217,7 +217,7 @@ void hv_synic_free(void)
 }
 
 /*
- * hv_synic_init - Initialize the Synthethic Interrupt Controller.
+ * hv_synic_init - Initialize the Synthetic Interrupt Controller.
  *
  * If it is already initialized by another entity (ie x2v shim), we need to
  * retrieve the initialized message and event pages.  Otherwise, we create and
-- 
2.15.1

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

[PATCH 07/12] hv_vmbus: Correct the stale comments regarding cpu affinity

[kys]

From: Haiyang Zhang 

The comments doesn't match what the current code does, also have a
typo. This patch corrects them.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/channel_mgmt.c | 6 ++
 include/linux/hyperv.h| 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index c21020b69114..c6d9d19bc04e 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -596,10 +596,8 @@ static int next_numa_node_id;
 /*
  * Starting with Win8, we can statically distribute the incoming
  * channel interrupt load by binding a channel to VCPU.
- * We do this in a hierarchical fashion:
- * First distribute the primary channels across available NUMA nodes
- * and then distribute the subchannels amongst the CPUs in the NUMA
- * node assigned to the primary channel.
+ * We distribute the interrupt loads to one or more NUMA nodes based on
+ * the channel's affinity_policy.
  *
  * For pre-win8 hosts or non-performance critical channels we assign the
  * first CPU in the first NUMA node.
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 93bd6fcd6e62..2048f3c3b68a 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -844,7 +844,7 @@ struct vmbus_channel {
 
/*
 * NUMA distribution policy:
-* We support teo policies:
+* We support two policies:
 * 1) Balanced: Here all performance critical channels are
 *distributed evenly amongst all the NUMA nodes.
 *This policy will be the default policy.
-- 
2.15.1

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

[PATCH 01/12] tools/hv: Fix IP reporting by KVP daemon with SRIOV

[kys]

From: Haiyang Zhang 

On Hyper-V the VF NIC has the same MAC as the related synthetic NIC.
VF NIC can work under the synthetic NIC transparently, without its
own IP address. The existing KVP daemon only gets IP from the first
NIC matching a MAC address, and may not be able to find the IP in
this case.

This patch fixes the problem by searching the NIC matching the MAC,
and having an IP address. So, the IP address will be found and
reported to the host successfully.

Signed-off-by: Haiyang Zhang 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_kvp_daemon.c | 138 ++-
 1 file changed, 65 insertions(+), 73 deletions(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 4c99c57736ce..dbf6e8bd98ba 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -634,64 +634,6 @@ static char *kvp_if_name_to_mac(char *if_name)
return mac_addr;
 }
 
-
-/*
- * Retrieve the interface name given tha MAC address.
- */
-
-static char *kvp_mac_to_if_name(char *mac)
-{
-   DIR *dir;
-   struct dirent *entry;
-   FILE*file;
-   char*p, *x;
-   char*if_name = NULL;
-   charbuf[256];
-   char dev_id[PATH_MAX];
-   unsigned int i;
-
-   dir = opendir(KVP_NET_DIR);
-   if (dir == NULL)
-   return NULL;
-
-   while ((entry = readdir(dir)) != NULL) {
-   /*
-* Set the state for the next pass.
-*/
-   snprintf(dev_id, sizeof(dev_id), "%s%s/address", KVP_NET_DIR,
-entry->d_name);
-
-   file = fopen(dev_id, "r");
-   if (file == NULL)
-   continue;
-
-   p = fgets(buf, sizeof(buf), file);
-   if (p) {
-   x = strchr(p, '\n');
-   if (x)
-   *x = '\0';
-
-   for (i = 0; i < strlen(p); i++)
-   p[i] = toupper(p[i]);
-
-   if (!strcmp(p, mac)) {
-   /*
-* Found the MAC match; return the interface
-* name. The caller will free the memory.
-*/
-   if_name = strdup(entry->d_name);
-   fclose(file);
-   break;
-   }
-   }
-   fclose(file);
-   }
-
-   closedir(dir);
-   return if_name;
-}
-
-
 static void kvp_process_ipconfig_file(char *cmd,
char *config_buf, unsigned int len,
int element_size, int offset)
@@ -997,6 +939,70 @@ kvp_get_ip_info(int family, char *if_name, int op,
return error;
 }
 
+/*
+ * Retrieve the IP given the MAC address.
+ */
+static int kvp_mac_to_ip(struct hv_kvp_ipaddr_value *kvp_ip_val)
+{
+   char *mac = (char *)kvp_ip_val->adapter_id;
+   DIR *dir;
+   struct dirent *entry;
+   FILE*file;
+   char*p, *x;
+   char*if_name = NULL;
+   charbuf[256];
+   char dev_id[PATH_MAX];
+   unsigned int i;
+   int error = HV_E_FAIL;
+
+   dir = opendir(KVP_NET_DIR);
+   if (dir == NULL)
+   return HV_E_FAIL;
+
+   while ((entry = readdir(dir)) != NULL) {
+   /*
+* Set the state for the next pass.
+*/
+   snprintf(dev_id, sizeof(dev_id), "%s%s/address", KVP_NET_DIR,
+entry->d_name);
+
+   file = fopen(dev_id, "r");
+   if (file == NULL)
+   continue;
+
+   p = fgets(buf, sizeof(buf), file);
+   fclose(file);
+   if (!p)
+   continue;
+
+   x = strchr(p, '\n');
+   if (x)
+   *x = '\0';
+
+   for (i = 0; i < strlen(p); i++)
+   p[i] = toupper(p[i]);
+
+   if (strcmp(p, mac))
+   continue;
+
+   /*
+* Found the MAC match.
+* A NIC (e.g. VF) matching the MAC, but without IP, is skipped.
+*/
+   if_name = entry->d_name;
+   if (!if_name)
+   continue;
+
+   error = kvp_get_ip_info(0, if_name, KVP_OP_GET_IP_INFO,
+   kvp_ip_val, MAX_IP_ADDR_SIZE * 2);
+
+   if (!error && strlen((char *)kvp_ip_val->ip_addr))
+   break;
+   }
+
+   closedir(dir);
+   return error;
+}
 
 static int expand_ipv6(char *addr, int type)
 {
@@ -1472,26 +1478,12 @@ int main(int argc, char *argv[])
switch (op) {
case 

[PATCH 02/12] hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

[kys]

From: Jia-Ju Bai 

The kzalloc function is called with GFP_ATOMIC.
But according to driver call graph, it is not in atomic context,
namely no spinlock is held nor in an interrupt handler.

This GFP_ATOMIC is unnecessary, and replace with GFP_KERNEL.

Signed-off-by: Jia-Ju Bai 
Reviewed-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index fe96aab9e794..b6cacc4cccf2 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -147,7 +147,7 @@ int hv_synic_alloc(void)
int cpu;
 
hv_context.hv_numa_map = kzalloc(sizeof(struct cpumask) * nr_node_ids,
-GFP_ATOMIC);
+GFP_KERNEL);
if (hv_context.hv_numa_map == NULL) {
pr_err("Unable to allocate NUMA map\n");
goto err;
-- 
2.15.1

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

[PATCH 10/12] hv_balloon: simplify hv_online_page()/hv_page_online_one()

[kys]

From: Vitaly Kuznetsov 

Instead of doing pfn_to_page() and continuosly casting page to unsigned
long just cache the pfn of the page with page_to_pfn().

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c | 27 +--
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 1aece72da9ba..5b8e1ad1bcfe 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -612,28 +612,17 @@ static struct notifier_block hv_memory_nb = {
 /* Check if the particular page is backed and can be onlined and online it. */
 static void hv_page_online_one(struct hv_hotadd_state *has, struct page *pg)
 {
-   unsigned long cur_start_pgp;
-   unsigned long cur_end_pgp;
struct hv_hotadd_gap *gap;
-
-   cur_start_pgp = (unsigned long)pfn_to_page(has->covered_start_pfn);
-   cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
+   unsigned long pfn = page_to_pfn(pg);
 
/* The page is not backed. */
-   if (((unsigned long)pg < cur_start_pgp) ||
-   ((unsigned long)pg >= cur_end_pgp))
+   if ((pfn < has->covered_start_pfn) || (pfn >= has->covered_end_pfn))
return;
 
/* Check for gaps. */
list_for_each_entry(gap, >gap_list, list) {
-   cur_start_pgp = (unsigned long)
-   pfn_to_page(gap->start_pfn);
-   cur_end_pgp = (unsigned long)
-   pfn_to_page(gap->end_pfn);
-   if (((unsigned long)pg >= cur_start_pgp) &&
-   ((unsigned long)pg < cur_end_pgp)) {
+   if ((pfn >= gap->start_pfn) && (pfn < gap->end_pfn))
return;
-   }
}
 
/* This frame is currently backed; online the page. */
@@ -726,19 +715,13 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
 static void hv_online_page(struct page *pg)
 {
struct hv_hotadd_state *has;
-   unsigned long cur_start_pgp;
-   unsigned long cur_end_pgp;
unsigned long flags;
+   unsigned long pfn = page_to_pfn(pg);
 
spin_lock_irqsave(_device.ha_lock, flags);
list_for_each_entry(has, _device.ha_region_list, list) {
-   cur_start_pgp = (unsigned long)
-   pfn_to_page(has->start_pfn);
-   cur_end_pgp = (unsigned long)pfn_to_page(has->end_pfn);
-
/* The page belongs to a different HAS. */
-   if (((unsigned long)pg < cur_start_pgp) ||
-   ((unsigned long)pg >= cur_end_pgp))
+   if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
continue;
 
hv_page_online_one(has, pg);
-- 
2.15.1

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

[PATCH 05/12] tools: hv: include string.h in hv_fcopy_daemon

[kys]

From: Olaf Hering 

The usage of strchr requires inclusion of string.h.

Fixes: 0c38cda64aec ("tools: hv: remove unnecessary header files and netlink 
related code")
Signed-off-by: Olaf Hering 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index 785f4e95148c..d78aed86af09 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.15.1

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

[PATCH 08/12] Drivers: hv: vmbus: Implement Direct Mode for stimer0

[kys]

From: Michael Kelley 

The 2016 version of Hyper-V offers the option to operate the guest VM
per-vcpu stimer's in Direct Mode, which means the timer interupts on its
own vector rather than queueing a VMbus message. Direct Mode reduces
timer processing overhead in both the hypervisor and the guest, and
avoids having timer interrupts pollute the VMbus interrupt stream for
the synthetic NIC and storage.  This patch enables Direct Mode by
default on stimer0 when running on a version of Hyper-V that supports
it.

In prep for coming support of Hyper-V on ARM64, the arch independent
portion of the code contains calls to routines that will be populated
on ARM64 but are not needed and do nothing on x86.

Signed-off-by: Michael Kelley 
Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/entry/entry_32.S  |  3 ++
 arch/x86/entry/entry_64.S  |  2 ++
 arch/x86/include/asm/hardirq.h |  3 ++
 arch/x86/include/asm/irq_vectors.h |  7 -
 arch/x86/include/asm/mshyperv.h| 13 
 arch/x86/include/uapi/asm/hyperv.h |  3 ++
 arch/x86/kernel/cpu/mshyperv.c | 41 -
 arch/x86/kernel/irq.c  |  9 ++
 drivers/hv/hv.c| 61 --
 drivers/hv/hyperv_vmbus.h  |  4 ++-
 10 files changed, 141 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 2a35b1e0fb90..e36f75bdbecc 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -895,6 +895,9 @@ BUILD_INTERRUPT3(xen_hvm_callback_vector, 
HYPERVISOR_CALLBACK_VECTOR,
 BUILD_INTERRUPT3(hyperv_callback_vector, HYPERVISOR_CALLBACK_VECTOR,
 hyperv_vector_handler)
 
+BUILD_INTERRUPT3(hv_stimer0_callback_vector, HYPERV_STIMER0_VECTOR,
+hv_stimer0_vector_handler)
+
 #endif /* CONFIG_HYPERV */
 
 ENTRY(page_fault)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a83570495162..4a9bdfed8588 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1245,6 +1245,8 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
 #if IS_ENABLED(CONFIG_HYPERV)
 apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
hyperv_callback_vector hyperv_vector_handler
+apicinterrupt3 HYPERV_STIMER0_VECTOR \
+   hv_stimer0_callback_vector hv_stimer0_vector_handler
 #endif /* CONFIG_HYPERV */
 
 idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 51cc979dd364..c788343f93d9 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -38,6 +38,9 @@ typedef struct {
 #if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
unsigned int irq_hv_callback_count;
 #endif
+#if IS_ENABLED(CONFIG_HYPERV)
+   unsigned int hyperv_stimer0_count;
+#endif
 } cacheline_aligned irq_cpustat_t;
 
 DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 67421f649cfa..6accf0b6491b 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -103,7 +103,12 @@
 #endif
 
 #define MANAGED_IRQ_SHUTDOWN_VECTOR0xef
-#define LOCAL_TIMER_VECTOR 0xee
+
+#if IS_ENABLED(CONFIG_HYPERV)
+#define HYPERV_STIMER0_VECTOR  0xee
+#endif
+
+#define LOCAL_TIMER_VECTOR 0xed
 
 #define NR_VECTORS  256
 
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b52af150cbd8..2bd73b4240e9 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -172,6 +172,19 @@ void hv_remove_kexec_handler(void);
 void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
 void hv_remove_crash_handler(void);
 
+/*
+ * Routines for stimer0 Direct Mode handling.
+ * On x86/x64, there are no percpu actions to take.
+ */
+void hv_stimer0_vector_handler(struct pt_regs *regs);
+void hv_stimer0_callback_vector(void);
+int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void));
+void hv_remove_stimer0_irq(int irq);
+
+static inline void hv_enable_stimer0_percpu_irq(int irq) {}
+static inline void hv_disable_stimer0_percpu_irq(int irq) {}
+
+
 #if IS_ENABLED(CONFIG_HYPERV)
 extern struct clocksource *hyperv_cs;
 extern void *hv_hypercall_pg;
diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 1a5bfead93b4..7213cb8448cf 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -74,6 +74,9 @@
 /* Crash MSR available */
 #define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE (1 << 10)
 
+/* stimer Direct Mode is available */
+#define HV_X64_STIMER_DIRECT_MODE_AVAILABLE(1 << 19)
+
 /*
  * Feature identification: EBX indicates which flags were specified at
  * partition creation. 

[PATCH 06/12] vmbus/ring_buffer: remove some redundant helper function.

[kys]

From: "lantianyu1...@gmail.com" 

Some hv_get/set** helper functions in ring_buffer code are
only called once or not used. This patch is to clear up these codes.

Signed-off-by: Tianyu Lan 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/ring_buffer.c | 49 
 1 file changed, 4 insertions(+), 45 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 50e071444a5c..1aa17795727b 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -78,46 +78,6 @@ static void hv_signal_on_write(u32 old_write, struct 
vmbus_channel *channel)
vmbus_setevent(channel);
 }
 
-/* Get the next write location for the specified ring buffer. */
-static inline u32
-hv_get_next_write_location(struct hv_ring_buffer_info *ring_info)
-{
-   u32 next = ring_info->ring_buffer->write_index;
-
-   return next;
-}
-
-/* Set the next write location for the specified ring buffer. */
-static inline void
-hv_set_next_write_location(struct hv_ring_buffer_info *ring_info,
-u32 next_write_location)
-{
-   ring_info->ring_buffer->write_index = next_write_location;
-}
-
-/* Set the next read location for the specified ring buffer. */
-static inline void
-hv_set_next_read_location(struct hv_ring_buffer_info *ring_info,
-   u32 next_read_location)
-{
-   ring_info->ring_buffer->read_index = next_read_location;
-   ring_info->priv_read_index = next_read_location;
-}
-
-/* Get the size of the ring buffer. */
-static inline u32
-hv_get_ring_buffersize(const struct hv_ring_buffer_info *ring_info)
-{
-   return ring_info->ring_datasize;
-}
-
-/* Get the read and write indices as u64 of the specified ring buffer. */
-static inline u64
-hv_get_ring_bufferindices(struct hv_ring_buffer_info *ring_info)
-{
-   return (u64)ring_info->ring_buffer->write_index << 32;
-}
-
 /*
  * Helper routine to copy from source to ring buffer.
  * Assume there is enough room. Handles wrap-around in dest case only!!
@@ -129,7 +89,7 @@ static u32 hv_copyto_ringbuffer(
u32 srclen)
 {
void *ring_buffer = hv_get_ring_buffer(ring_info);
-   u32 ring_buffer_size = hv_get_ring_buffersize(ring_info);
+   u32 ring_buffer_size = ring_info->ring_datasize;
 
memcpy(ring_buffer + start_write_offset, src, srclen);
 
@@ -275,8 +235,7 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
}
 
/* Write to the ring buffer */
-   next_write_location = hv_get_next_write_location(outring_info);
-
+   next_write_location = outring_info->ring_buffer->write_index;
old_write = next_write_location;
 
for (i = 0; i < kv_count; i++) {
@@ -287,7 +246,7 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
}
 
/* Set previous packet start */
-   prev_indices = hv_get_ring_bufferindices(outring_info);
+   prev_indices = (u64)outring_info->ring_buffer->write_index << 32;
 
next_write_location = hv_copyto_ringbuffer(outring_info,
 next_write_location,
@@ -298,7 +257,7 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
virt_mb();
 
/* Now, update the write location */
-   hv_set_next_write_location(outring_info, next_write_location);
+   outring_info->ring_buffer->write_index = next_write_location;
 
 
spin_unlock_irqrestore(_info->ring_lock, flags);
-- 
2.15.1

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

[PATCH 09/12] hv_balloon: fix printk loglevel

[kys]

From: Vitaly Kuznetsov 

We have a mix of different ideas of which loglevel should be used. Unify
on the following:
- pr_info() for normal operation
- pr_warn() for 'strange' host behavior
- pr_err() for all errors.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv_balloon.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index db0e6652d7ef..1aece72da9ba 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -691,7 +691,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,
(HA_CHUNK << PAGE_SHIFT));
 
if (ret) {
-   pr_warn("hot_add memory failed error is %d\n", ret);
+   pr_err("hot_add memory failed error is %d\n", ret);
if (ret == -EEXIST) {
/*
 * This error indicates that the error
@@ -1014,7 +1014,7 @@ static void hot_add_req(struct work_struct *dummy)
resp.result = 0;
 
if (!do_hot_add || (resp.page_count == 0))
-   pr_info("Memory hot add failed\n");
+   pr_err("Memory hot add failed\n");
 
dm->state = DM_INITIALIZED;
resp.hdr.trans_id = atomic_inc_return(_id);
@@ -1041,7 +1041,7 @@ static void process_info(struct hv_dynmem_device *dm, 
struct dm_info_msg *msg)
 
break;
default:
-   pr_info("Received Unknown type: %d\n", info_hdr->type);
+   pr_warn("Received Unknown type: %d\n", info_hdr->type);
}
 }
 
@@ -1290,7 +1290,7 @@ static void balloon_up(struct work_struct *dummy)
/*
 * Free up the memory we allocatted.
 */
-   pr_info("Balloon response failed\n");
+   pr_err("Balloon response failed\n");
 
for (i = 0; i < bl_resp->range_count; i++)
free_balloon_pages(_device,
@@ -1421,7 +1421,7 @@ static void cap_resp(struct hv_dynmem_device *dm,
struct dm_capabilities_resp_msg *cap_resp)
 {
if (!cap_resp->is_accepted) {
-   pr_info("Capabilities not accepted by host\n");
+   pr_err("Capabilities not accepted by host\n");
dm->state = DM_INIT_ERROR;
}
complete(>host_event);
@@ -1508,7 +1508,7 @@ static void balloon_onchannelcallback(void *context)
break;
 
default:
-   pr_err("Unhandled message: type: %d\n", dm_hdr->type);
+   pr_warn("Unhandled message: type: %d\n", dm_hdr->type);
 
}
}
-- 
2.15.1

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

[PATCH 04/12] tools: hv: fix compiler warnings about major/target_fname

[kys]

From: Dexuan Cui 

This patch fixes the below warnings with new glibc and gcc:

hv_vss_daemon.c:100:13: warning: In the GNU C Library, "major" is defined
 by . For historical compatibility, it is currently
defined by  as well, but we plan to  remove this soon.
To use "major", include   directly.

hv_fcopy_daemon.c:42:2: note: 'snprintf' output between 2 and 1040
bytes into a destination of size 260

Signed-off-by: Dexuan Cui 
Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
---
 tools/hv/hv_fcopy_daemon.c | 3 ++-
 tools/hv/hv_vss_daemon.c   | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index 457a1521f32f..785f4e95148c 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -23,13 +23,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
 static int target_fd;
-static char target_fname[W_MAX_PATH];
+static char target_fname[PATH_MAX];
 static unsigned long long filesize;
 
 static int hv_start_fcopy(struct hv_start_fcopy *smsg)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index b2b4ebffab8c..34031a297f02 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.15.1

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

[PATCH 00/12] Drivers: hv: Miscellaneous fixes

[kys]

From: "K. Y. Srinivasan" 

Miscellaneous fixes.

Dexuan Cui (1):
  tools: hv: fix compiler warnings about major/target_fname

Haiyang Zhang (2):
  tools/hv: Fix IP reporting by KVP daemon with SRIOV
  hv_vmbus: Correct the stale comments regarding cpu affinity

Jia-Ju Bai (1):
  hyper-v: use GFP_KERNEL for hv_context.hv_numa_map

Joe Perches (1):
  hv: Synthetic typo correction

Michael Kelley (1):
  Drivers: hv: vmbus: Implement Direct Mode for stimer0

Olaf Hering (1):
  tools: hv: include string.h in hv_fcopy_daemon

Vitaly Kuznetsov (4):
  hv_balloon: fix printk loglevel
  hv_balloon: simplify hv_online_page()/hv_page_online_one()
  hv_balloon: fix bugs in num_pages_onlined accounting
  hv_balloon: trace post_status

lantianyu1...@gmail.com (1):
  vmbus/ring_buffer: remove some redundant helper function.

 arch/x86/entry/entry_32.S  |   3 +
 arch/x86/entry/entry_64.S  |   2 +
 arch/x86/include/asm/hardirq.h |   3 +
 arch/x86/include/asm/irq_vectors.h |   7 +-
 arch/x86/include/asm/mshyperv.h|  13 
 arch/x86/include/uapi/asm/hyperv.h |   3 +
 arch/x86/kernel/cpu/mshyperv.c |  41 ++-
 arch/x86/kernel/irq.c  |   9 +++
 drivers/hv/Makefile|   1 +
 drivers/hv/channel_mgmt.c  |   6 +-
 drivers/hv/hv.c|  65 +++--
 drivers/hv/hv_balloon.c| 121 ++--
 drivers/hv/hv_trace_balloon.h  |  48 +
 drivers/hv/hyperv_vmbus.h  |   4 +-
 drivers/hv/ring_buffer.c   |  49 ++---
 include/linux/hyperv.h |   2 +-
 tools/hv/hv_fcopy_daemon.c |   4 +-
 tools/hv/hv_kvp_daemon.c   | 138 +
 tools/hv/hv_vss_daemon.c   |   1 +
 19 files changed, 351 insertions(+), 169 deletions(-)
 create mode 100644 drivers/hv/hv_trace_balloon.h

-- 
2.15.1

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

[PATCH 12/12] hv_balloon: trace post_status

[kys]

From: Vitaly Kuznetsov 

Hyper-V balloon driver makes non-trivial calculations to convert Linux's
representation of free/used memory to what Hyper-V host expects to see. Add
a tracepoint to see what's being sent and where the data comes from.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/Makefile   |  1 +
 drivers/hv/hv_balloon.c   |  6 ++
 drivers/hv/hv_trace_balloon.h | 48 +++
 3 files changed, 55 insertions(+)
 create mode 100644 drivers/hv/hv_trace_balloon.h

diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
index 14c22786b519..a1eec7177c2d 100644
--- a/drivers/hv/Makefile
+++ b/drivers/hv/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_HYPERV_UTILS)  += hv_utils.o
 obj-$(CONFIG_HYPERV_BALLOON)   += hv_balloon.o
 
 CFLAGS_hv_trace.o = -I$(src)
+CFLAGS_hv_balloon.o = -I$(src)
 
 hv_vmbus-y := vmbus_drv.o \
 hv.o connection.o channel.o \
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 7514a32d0de4..b3e9f13f8bc3 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -34,6 +34,9 @@
 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include "hv_trace_balloon.h"
+
 /*
  * We begin with definitions supporting the Dynamic Memory protocol
  * with the host.
@@ -1159,6 +1162,9 @@ static void post_status(struct hv_dynmem_device *dm)
 dm->num_pages_added - dm->num_pages_onlined : 0) +
compute_balloon_floor();
 
+   trace_balloon_status(status.num_avail, status.num_committed,
+vm_memory_committed(), dm->num_pages_ballooned,
+dm->num_pages_added, dm->num_pages_onlined);
/*
 * If our transaction ID is no longer current, just don't
 * send the status. This can happen if we were interrupted
diff --git a/drivers/hv/hv_trace_balloon.h b/drivers/hv/hv_trace_balloon.h
new file mode 100644
index ..93082888aec3
--- /dev/null
+++ b/drivers/hv/hv_trace_balloon.h
@@ -0,0 +1,48 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM hyperv
+
+#if !defined(_HV_TRACE_BALLOON_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _HV_TRACE_BALLOON_H
+
+#include 
+
+TRACE_EVENT(balloon_status,
+   TP_PROTO(u64 available, u64 committed,
+unsigned long vm_memory_committed,
+unsigned long pages_ballooned,
+unsigned long pages_added,
+unsigned long pages_onlined),
+   TP_ARGS(available, committed, vm_memory_committed,
+   pages_ballooned, pages_added, pages_onlined),
+   TP_STRUCT__entry(
+   __field(u64, available)
+   __field(u64, committed)
+   __field(unsigned long, vm_memory_committed)
+   __field(unsigned long, pages_ballooned)
+   __field(unsigned long, pages_added)
+   __field(unsigned long, pages_onlined)
+   ),
+   TP_fast_assign(
+   __entry->available = available;
+   __entry->committed = committed;
+   __entry->vm_memory_committed = vm_memory_committed;
+   __entry->pages_ballooned = pages_ballooned;
+   __entry->pages_added = pages_added;
+   __entry->pages_onlined = pages_onlined;
+   ),
+   TP_printk("available %lld, committed %lld; vm_memory_committed %ld;"
+ " pages_ballooned %ld, pages_added %ld, pages_onlined 
%ld",
+ __entry->available, __entry->committed,
+ __entry->vm_memory_committed, __entry->pages_ballooned,
+ __entry->pages_added, __entry->pages_onlined
+   )
+   );
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE hv_trace_balloon
+#endif /* _HV_TRACE_BALLOON_H */
+
+/* This part must be outside protection */
+#include 
-- 
2.15.1

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

Re: [lustre-devel] [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[Oleg Drokin]

> On Feb 11, 2018, at 6:50 PM, NeilBrown  wrote:
> 
> Maybe - as you suggest in another email - it is due to some
> client/server incompatibility.  I guess it is unavoidable with an fs
> like lustre to have incompatible protocol changes.  Is there any
> mechanism for detecting the version of other peers in the cluster and
> refusing to run if versions are incompatible?

Yes, client and server exchange “feature bits” at connect time
and only use the subset of features that both can understand.

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

Re: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

[Stephen Hemminger]

On Sat, 10 Feb 2018 20:48:49 +
Michael Kelley  wrote:

> + u32 delta = rbi->ring_buffer->read_index < rbi->priv_read_index ?
> + (rbi->priv_read_index - rbi->ring_buffer->read_index) :
> + (rbi->ring_datasize - rbi->ring_buffer->read_index +
> + rbi->priv_read_index);
>  

Would it would make sense for this to be a wrapper function like other ring 
operations?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [lustre-devel] [PATCH 41/80] staging: lustre: lmv: separate master object with master stripe

[NeilBrown]

On Sat, Feb 10 2018, James Simmons wrote:

>> > On Feb 8, 2018, at 10:10 PM, NeilBrown  wrote:
>> > 
>> > On Thu, Feb 08 2018, Oleg Drokin wrote:
>> > 
>> >>> On Feb 8, 2018, at 8:39 PM, NeilBrown  wrote:
>> >>> 
>> >>> On Tue, Aug 16 2016, James Simmons wrote:
>> >> 
>> >> my that’s an old patch
>> >> 
>> >>> 
>> > ...
>> >>> 
>> >>> Whoever converted it to "!strcmp()" inverted the condition.  This is a
>> >>> perfect example of why I absolutely *loathe* the "!strcmp()" construct!!
>> >>> 
>> >>> This causes many tests in the 'sanity' test suite to return
>> >>> -ENOMEM (that had me puzzled for a while!!).
>> >> 
>> >> huh? I am not seeing anything of the sort and I was running sanity
>> >> all the time until a recent pause (but going to resume).
>> > 
>> > That does surprised me - I reproduce it every time.
>> > I have two VMs running a SLE12-SP2 kernel with patches from
>> > lustre-release applied.  These are servers. They have 2 3G virtual disks
>> > each.
>> > I have two over VMs running current mainline.  These are clients.
>> > 
>> > I guess your 'recent pause' included between v4.15-rc1 (8e55b6fd0660)
>> > and v4.15-rc6 (a93639090a27) - a full month when lustre wouldn't work at
>> > all :-(
>> 
>> More than that, but I am pretty sure James Simmons is running tests all the 
>> time too
>> (he has a different config, I only have tcp).
>
> Yes I have been testing and haven't encountered this problem. Let me try 
> the fix you pointed out. 

Yeah, I guess I over reacted a bit in suggesting that no-one can have
been testing - sorry about that.  It seemed really strange though as the
bug was so easy for me to hit.

Maybe - as you suggest in another email - it is due to some
client/server incompatibility.  I guess it is unavoidable with an fs
like lustre to have incompatible protocol changes.  Is there any
mechanism for detecting the version of other peers in the cluster and
refusing to run if versions are incompatible?

If you haven't hit the problem in testing, I suspect you aren't touching
that code path at all.  Maybe put a BUG() call in there to see :-)

>  
>> > Do you have a list of requested cleanups?  I would find that to be
>> > useful.
>> 
>> As Greg would tell you, “if you don’t know what needs to be done,
>> let’s just remove the whole thing from staging now”.
>> 
>> I assume you saw drivers/staging/lustre/TODO already, it’s only partially 
>> done.
>
> Actually the complete list is at :
>
> https://jira.hpdd.intel.com/browse/LU-9679
>
> I need to move that to our TODO list. Sorry I have been short on cycles.

Just adding that link to TODO would be a great start.  I might do that
when I next send some patches.

Thanks,
NeilBrown



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

Re: [PATCH] staging: lustre: update the TODO list

[Joe Perches]

On Sun, 2018-02-11 at 18:00 -0500, James Simmons wrote:
> As more people become involved with the progression of the lustre
> client it needs to more clear what needs to be done to leave
> staging. Update the TODO list with the various bugs and changes
> to accomplish this. Some are simple bugs and others are far more
> complex task that will change many lines of code. Some even cover
> updating the user land utilities to meet the kernel requirements.
> Several bugs have already been addressed and just need to be
> pushed to the staging tree.

Nice list.

Are or should those entries that have been addressed
also in this new list?

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

[PATCH] staging: lustre: update the TODO list

[James Simmons]

As more people become involved with the progression of the lustre
client it needs to more clear what needs to be done to leave
staging. Update the TODO list with the various bugs and changes
to accomplish this. Some are simple bugs and others are far more
complex task that will change many lines of code. Some even cover
updating the user land utilities to meet the kernel requirements.
Several bugs have already been addressed and just need to be
pushed to the staging tree.

Signed-off-by: James Simmons 
---
 drivers/staging/lustre/TODO | 310 ++--
 1 file changed, 300 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/TODO b/drivers/staging/lustre/TODO
index f194417..94446487 100644
--- a/drivers/staging/lustre/TODO
+++ b/drivers/staging/lustre/TODO
@@ -1,12 +1,302 @@
-* Possible remaining coding style fix.
-* Remove deadcode.
-* Separate client/server functionality. Functions only used by server can be
-  removed from client.
-* Clean up libcfs layer. Ideally we can remove include/linux/libcfs entirely.
-* Clean up CLIO layer. Lustre client readahead/writeback control needs to 
better
-  suit kernel providings.
-* Add documents in Documentation.
-* Other minor misc cleanups...
+Currently all the work directed toward the lustre upstream client is tracked
+at the following link:
+
+https://jira.hpdd.intel.com/browse/LU-9679
+
+Under this ticket you will see the following work items that need to be
+addressed:
+
+**
+* libcfs cleanup
+*
+* https://jira.hpdd.intel.com/browse/LU-9859
+*
+* Track all the cleanups and simplification of the libcfs module. Remove
+* functions the kernel provides. Possible intergrate some of the functionality
+* into the kernel proper.
+*
+**
+
+https://jira.hpdd.intel.com/browse/LU-100086
+
+LNET_MINOR conflicts with USERIO_MINOR
+
+--
+
+https://jira.hpdd.intel.com/browse/LU-8130
+
+Fix and simplify libcfs hash handling
+
+--
+
+https://jira.hpdd.intel.com/browse/LU-8703
+
+The current way we handle SMP is wrong. Platforms like ARM and KNL can have
+core and NUMA setups with things like NUMA nodes with no cores. We need to
+handle such cases. This work also greatly simplified the lustre SMP code.
+
+--
+
+https://jira.hpdd.intel.com/browse/LU-9019
+
+Replace libcfs time API with standard kernel APIs. Also migrate away from
+jiffies. We found jiffies can vary on nodes which can lead to corner cases
+that can break the file system due to nodes having inconsistent behavior.
+So move to time64_t and ktime_t as much as possible.
+
+**
+* Proper IB support for ko2iblnd
+**
+https://jira.hpdd.intel.com/browse/LU-9179
+
+Poor performance for the ko2iblnd driver. This is related to many of the
+patches below that are missing from the linux client.
+--
+
+https://jira.hpdd.intel.com/browse/LU-9886
+
+Crash in upstream kiblnd_handle_early_rxs()
+--
+
+https://jira.hpdd.intel.com/browse/LU-10394 / LU-10526 / LU-10089
+
+Default to default to using MEM_REG
+--
+
+https://jira.hpdd.intel.com/browse/LU-10459
+
+throttle tx based on queue depth
+--
+
+https://jira.hpdd.intel.com/browse/LU-9943
+
+correct WR fast reg accounting
+--
+
+https://jira.hpdd.intel.com/browse/LU-10291
+
+remove concurrent_sends tunable
+--
+
+https://jira.hpdd.intel.com/browse/LU-10213
+
+calculate qp max_send_wrs properly
+--
+
+https://jira.hpdd.intel.com/browse/LU-9810
+
+use less CQ entries for each connection
+--
+
+https://jira.hpdd.intel.com/browse/LU-10129 / LU-9180
+
+rework map_on_demand behavior
+--
+
+https://jira.hpdd.intel.com/browse/LU-10129
+
+query device capabilities
+--
+
+https://jira.hpdd.intel.com/browse/LU-10015
+
+fix race at kiblnd_connect_peer

Re: [PATCH] staging: lustre: lnet: return of an error code should be negative

[James Simmons]

> Return value of error codes should typically be negative.
> Issue reported by checkpatch.pl
>

Reviewed-by: James Simmons 
 
> Signed-off-by: Sumit Pundir 
> ---
>  drivers/staging/lustre/lnet/selftest/framework.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/lnet/selftest/framework.c 
> b/drivers/staging/lustre/lnet/selftest/framework.c
> index c7697f6..0ca1e3a 100644
> --- a/drivers/staging/lustre/lnet/selftest/framework.c
> +++ b/drivers/staging/lustre/lnet/selftest/framework.c
> @@ -187,7 +187,7 @@ sfw_del_session_timer(void)
>   return 0;
>   }
>  
> - return EBUSY; /* racing with sfw_session_expired() */
> + return -EBUSY; /* racing with sfw_session_expired() */
>  }
>  
>  static void
> -- 
> 2.7.4
> 
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: lustre: llite: replace variable length array

[James Simmons]

> On 01/30/2018 03:04 AM, Dilger, Andreas wrote:
> > On Jan 27, 2018, at 14:42, Sven Dziadek  wrote:
> >>
> >> The functionality of the removed variable length array is already
> >> implemented by the function xattr_full_name in fs/xattr.c
> >>
> >> This fixes the sparse warning:
> >> warning: Variable length array is used.
> >>
> >> Signed-off-by: Sven Dziadek 
> >> ---
> >> drivers/staging/lustre/lustre/llite/xattr.c | 12 
> >> 1 file changed, 4 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/staging/lustre/lustre/llite/xattr.c 
> >> b/drivers/staging/lustre/lustre/llite/xattr.c
> >> index 532384c91447..4fd28213c6a1 100644
> >> --- a/drivers/staging/lustre/lustre/llite/xattr.c
> >> +++ b/drivers/staging/lustre/lustre/llite/xattr.c
> >> @@ -87,7 +87,6 @@ ll_xattr_set_common(const struct xattr_handler *handler,
> >>const char *name, const void *value, size_t size,
> >>int flags)
> >> {
> >> -  char fullname[strlen(handler->prefix) + strlen(name) + 1];
> >>struct ll_sb_info *sbi = ll_i2sbi(inode);
> >>struct ptlrpc_request *req = NULL;
> >>const char *pv = value;
> >> @@ -141,9 +140,8 @@ ll_xattr_set_common(const struct xattr_handler 
> >> *handler,
> >>return -EPERM;
> >>}
> >>
> >> -  sprintf(fullname, "%s%s\n", handler->prefix, name);
> >> -  rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode),
> >> -   valid, fullname, pv, size, 0, flags,
> >> +  rc = md_setxattr(sbi->ll_md_exp, ll_inode2fid(inode), valid,
> >> +   xattr_full_name(handler, name), pv, size, 0, flags,
> >> ll_i2suppgid(inode), );
> > 
> > Hi Sven,
> > thanks for the patch.
> > 
> > Looking at the details of "xattr_full_name()", this seems quite risky.  This
> > is essentially returning the pointer _before_ "name" on the assumption that
> > it contains the full "prefix.name" string.  IMHO, that is not necessarily a
> > safe assumption to make several layers down in the code.
> Thanks for your reply. And yeah, it feels strange, right.
> 
> But it really looks like this is how the name and the prefix is handled
> in the xattr code.
> It seems this helper function has been introduced with commit
> e409de992e3ea (which also removes some fullname pointer) and indeed,
> fs/xattr.c splits the prefix and the name in xattr_resolve_name.
> 
> So I still think the patch should be correct..?
> 
> > James, I thought you had a patch for this to use kasprintf() instead of the
> > on-stack "fullname" declaration?
> Sorry for replying that late, I though James would maybe know if the
> above assumption is correct..

Yes I do have a patch for this. I pushed them several months ago but they
got missed. It happens. I will the patches again very soon.
 
> >>if (rc) {
> >>if (rc == -EOPNOTSUPP && handler->flags == XATTR_USER_T) {
> >> @@ -364,7 +362,6 @@ static int ll_xattr_get_common(const struct 
> >> xattr_handler *handler,
> >>   struct dentry *dentry, struct inode *inode,
> >>   const char *name, void *buffer, size_t size)
> >> {
> >> -  char fullname[strlen(handler->prefix) + strlen(name) + 1];
> >>struct ll_sb_info *sbi = ll_i2sbi(inode);
> >> #ifdef CONFIG_FS_POSIX_ACL
> >>struct ll_inode_info *lli = ll_i2info(inode);
> >> @@ -411,9 +408,8 @@ static int ll_xattr_get_common(const struct 
> >> xattr_handler *handler,
> >>if (handler->flags == XATTR_ACL_DEFAULT_T && !S_ISDIR(inode->i_mode))
> >>return -ENODATA;
> >> #endif
> >> -  sprintf(fullname, "%s%s\n", handler->prefix, name);
> >> -  return ll_xattr_list(inode, fullname, handler->flags, buffer, size,
> >> -   OBD_MD_FLXATTR);
> >> +  return ll_xattr_list(inode, xattr_full_name(handler, name),
> >> +   handler->flags, buffer, size, OBD_MD_FLXATTR);
> >> }
> >>
> >> static ssize_t ll_getxattr_lov(struct inode *inode, void *buf, size_t 
> >> buf_size)
> >> -- 
> >> 2.11.0
> >>
> 
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: sm750fb: Remove typedefs from enums

[Christian Luetke-Stetzkamp]

Fixes checkpatch.pl warning: do not add new typedefs.

Signed-off-by: Christian Luetke-Stetzkamp 
---
 drivers/staging/sm750fb/ddk750_chip.c |  4 ++--
 drivers/staging/sm750fb/ddk750_chip.h | 14 ++
 drivers/staging/sm750fb/ddk750_mode.c |  2 +-
 drivers/staging/sm750fb/ddk750_mode.h |  2 +-
 drivers/staging/sm750fb/sm750_hw.c|  2 +-
 5 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 313b99104398..4c1f00f551da 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -8,9 +8,9 @@
 
 #define MHz(x) ((x) * 100)
 
-static logical_chip_type_t chip;
+static enum logical_chip_type chip;
 
-logical_chip_type_t sm750_get_chip_type(void)
+enum logical_chip_type sm750_get_chip_type(void)
 {
return chip;
 }
diff --git a/drivers/staging/sm750fb/ddk750_chip.h 
b/drivers/staging/sm750fb/ddk750_chip.h
index aee82fcaf669..c72aac21b675 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -24,25 +24,23 @@ static inline void poke32(u32 addr, u32 data)
 }
 
 /* This is all the chips recognized by this library */
-typedef enum _logical_chip_type_t {
+enum logical_chip_type {
SM_UNKNOWN,
SM718,
SM750,
SM750LE,
-}
-logical_chip_type_t;
+};
 
-typedef enum _clock_type_t {
+enum clock_type {
MXCLK_PLL,
PRIMARY_PLL,
SECONDARY_PLL,
VGA0_PLL,
VGA1_PLL,
-}
-clock_type_t;
+};
 
 struct pll_value {
-   clock_type_t clockType;
+   enum clock_type clockType;
unsigned long inputFreq; /* Input clock frequency to the PLL */
 
/* Use this when clockType = PANEL_PLL */
@@ -94,7 +92,7 @@ struct initchip_param {
/* More initialization parameter can be added if needed */
 };
 
-logical_chip_type_t sm750_get_chip_type(void);
+enum logical_chip_type sm750_get_chip_type(void);
 void sm750_set_chip_type(unsigned short devId, u8 revId);
 unsigned int sm750_calc_pll_value(unsigned int request, struct  pll_value 
*pll);
 unsigned int sm750_format_pll_reg(struct pll_value *pPLL);
diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index 2cdd87b78e58..7e22d093b091 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -206,7 +206,7 @@ static int programModeRegisters(struct mode_parameter 
*pModeParam,
return ret;
 }
 
-int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock)
+int ddk750_setModeTiming(struct mode_parameter *parm, enum clock_type clock)
 {
struct pll_value pll;
unsigned int uiActualPixelClk;
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 259a9d6a4eb2..2df78a0937b2 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -33,5 +33,5 @@ struct mode_parameter {
enum spolarity clock_phase_polarity;
 };
 
-int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
+int ddk750_setModeTiming(struct mode_parameter *parm, enum clock_type clock);
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index a8c79864ee4b..f996f8460641 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -254,7 +254,7 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc,
int ret, fmt;
u32 reg;
struct mode_parameter modparm;
-   clock_type_t clock;
+   enum clock_type clock;
struct sm750_dev *sm750_dev;
struct lynxfb_par *par;
 
-- 
2.13.6

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