Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
On Mon, Jun 04, 2018 at 09:32:50PM +0200, Thibaut Robert wrote:
> Le mercredi 30 mai 2018 à 14:17:25 (+0300), Dan Carpenter a écrit :
> > On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote:
> > > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > index e248702ee519..745bf5ca2622 100644
> > > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8
> > > *buff, u32 size)
> > >
> > > freq = ieee80211_channel_to_frequency(curr_channel, NL80211_BAND_2GHZ);
> > >
> > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > > + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> >
> > "buff" comes from the network, it's going to be little endian, not cpu
> > endian. The rest of the function treats it as CPU endian but I'm pretty
> > sure it's wrong...
> buff comes from the network but we are looking at single byte here.
> ieee80211_is_action expects an le16, so we I added this to extend an u8
> to an le16. Is this incorrect ?
>
> Or maybe we the buff has the second byte ? but that I can't tell.
You raise a good point that I hadn't seen. The original code is clearly
buggy. But your fix isn't correct either... The other thing to
consider is that cpu_to_le16() is basically a cast to u16 on x86 so it's
a no-op here.
Really the right thing is to not treat buff as an array of u8 but a
struct. The code assumes that frame_type is 0-255 but probably it's
supposed to go up to U16_MAX.
struct whatever {
__le16 frame_type;
...
There probably is already a struct like that, but I don't know what it
is. I don't know this code at all, I'm just guessing.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
Le mardi 05 juin 2018 à 10:36:31 (+0300), Dan Carpenter a écrit :
> On Mon, Jun 04, 2018 at 09:32:50PM +0200, Thibaut Robert wrote:
> > Le mercredi 30 mai 2018 à 14:17:25 (+0300), Dan Carpenter a écrit :
> > > On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote:
> > > > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > index e248702ee519..745bf5ca2622 100644
> > > > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8
> > > > *buff, u32 size)
> > > >
> > > > freq = ieee80211_channel_to_frequency(curr_channel,
> > > > NL80211_BAND_2GHZ);
> > > >
> > > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > > > + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> > >
> > > "buff" comes from the network, it's going to be little endian, not cpu
> > > endian. The rest of the function treats it as CPU endian but I'm pretty
> > > sure it's wrong...
> > buff comes from the network but we are looking at single byte here.
> > ieee80211_is_action expects an le16, so we I added this to extend an u8
> > to an le16. Is this incorrect ?
> >
> > Or maybe we the buff has the second byte ? but that I can't tell.
>
> You raise a good point that I hadn't seen. The original code is clearly
> buggy. But your fix isn't correct either... The other thing to
> consider is that cpu_to_le16() is basically a cast to u16 on x86 so it's
> a no-op here.
The sparse warning is clearly spotting a real issue. I tried to at least
have big endian handle correctly the 0-255 case. I am willing to drop
the change (since I agree it's not very satisfying and will mask an issue),
but may I ask you to explain how it is wrong ? How would you correctly expand
an u8 to __le16 ? I think in big endian we need to swap the bytes.
>
> Really the right thing is to not treat buff as an array of u8 but a
> struct. The code assumes that frame_type is 0-255 but probably it's
> supposed to go up to U16_MAX.
>
> struct whatever {
> __le16 frame_type;
> ...
>
> There probably is already a struct like that, but I don't know what it
> is. I don't know this code at all, I'm just guessing.
>
I was thinking the same. I don't know whether this buf contains a
standard struct or something hw-specific. I'll try to dig further and
submit a separate patch if I can. Maybe Aditya can give more information
?
> regards,
> dan carpenter
>
Regards,
Thibaut
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: wilc1000: Use common structs to parse ip packets
On Mon, Jun 04, 2018 at 09:27:02PM +0200, Thibaut Robert wrote: > Le lundi 04 juin 2018 à 10:55:49 (+0530), Ajay Singh a écrit : > > > > Thank you for submitting the patches. > > > > The modification in this patch looks okay to me. > > Please resend this by including changes as suggested by Dan. > > I can do the modification and resubmit this patch by including review > > comments, if its okay with you. > > > Sorry, I would like to address the comments, but still had no time to do it > correctly. I > am doing this as a hobby and am still learning so forgive me for the delay. > If you can wait a little bit more, I'll resend an updated version. > > Thanks for your time ! When you're a kernel dev, you sometimes do get the feeling that everyone is waiting for you. We're not. There is no rush. We read through your email and reply and then it's gone from our mind like dust in the wind. There is never a rush and you will never run out of more work to do. Plus the merge window is open so Greg won't even look at it for the next several weeks. Take all the time you need. I normally write a patch, then wait until morning so I can review it with fresh eyes before sending it. If I wait longer than a day, though, I forget what the issue is and I have to retest it from scratch. After one day in my outbox a patch gets old and boring so those are low quality. If it's a cleanup patch, I'll probably just delete it instead. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
On Tue, Jun 05, 2018 at 10:33:25AM +0200, Thibaut Robert wrote:
> Le mardi 05 juin 2018 à 10:36:31 (+0300), Dan Carpenter a écrit :
> > On Mon, Jun 04, 2018 at 09:32:50PM +0200, Thibaut Robert wrote:
> > > Le mercredi 30 mai 2018 à 14:17:25 (+0300), Dan Carpenter a écrit :
> > > > On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert wrote:
> > > > > diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > > index e248702ee519..745bf5ca2622 100644
> > > > > --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > > +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > > @@ -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device *dev, u8
> > > > > *buff, u32 size)
> > > > >
> > > > > freq = ieee80211_channel_to_frequency(curr_channel,
> > > > > NL80211_BAND_2GHZ);
> > > > >
> > > > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > > > > + if (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> > > >
> > > > "buff" comes from the network, it's going to be little endian, not cpu
> > > > endian. The rest of the function treats it as CPU endian but I'm pretty
> > > > sure it's wrong...
> > > buff comes from the network but we are looking at single byte here.
> > > ieee80211_is_action expects an le16, so we I added this to extend an u8
> > > to an le16. Is this incorrect ?
> > >
> > > Or maybe we the buff has the second byte ? but that I can't tell.
> >
> > You raise a good point that I hadn't seen. The original code is clearly
> > buggy. But your fix isn't correct either... The other thing to
> > consider is that cpu_to_le16() is basically a cast to u16 on x86 so it's
> > a no-op here.
> The sparse warning is clearly spotting a real issue. I tried to at least
> have big endian handle correctly the 0-255 case. I am willing to drop
> the change (since I agree it's not very satisfying and will mask an issue),
> but may I ask you to explain how it is wrong ? How would you correctly expand
> an u8 to __le16 ? I think in big endian we need to swap the bytes.
You're right that on big endian we would need to swap the bytes and
cpu_to_le16() does that.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [greybus-dev] [PATCH] Staging:greybus Fix comparison to NULL
On Tue, Jun 05, 2018 at 11:02:36AM +0530, Viresh Kumar wrote:
> On 03-06-18, 08:52, Janani Sankara Babu wrote:
> > This patch replaces comparison of var to NULL with !var
> >
> > Signed-off-by: Janani Sankara Babu
> > ---
> > drivers/staging/greybus/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/greybus/core.c b/drivers/staging/greybus/core.c
> > index dafa430..5d14a4e 100644
> > --- a/drivers/staging/greybus/core.c
> > +++ b/drivers/staging/greybus/core.c
> > @@ -48,7 +48,7 @@ static bool greybus_match_one_id(struct gb_bundle *bundle,
> > static const struct greybus_bundle_id *
> > greybus_match_id(struct gb_bundle *bundle, const struct greybus_bundle_id
> > *id)
> > {
> > - if (id == NULL)
> > + if (!id)
>
> It is pretty much personal preference and there is no good reason to accept
> this
> patch really.
Checkpatch complains, so it's Official Kernel Style now.
The != NULL comparison is a double negative which makes it not less
annoying than official kernel style.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: quatech_daqp_cs: fix no-op loop daqp_ao_insn_write()
There is a '>' vs '<' typo so this loop is a no-op.
Fixes: d35dcc89fc93 ("staging: comedi: quatech_daqp_cs: fix
daqp_ao_insn_write()")
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index ea194aa01a64..257b0daff01f 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -642,7 +642,7 @@ static int daqp_ao_insn_write(struct comedi_device *dev,
/* Make sure D/A update mode is direct update */
outb(0, dev->iobase + DAQP_AUX_REG);
- for (i = 0; i > insn->n; i++) {
+ for (i = 0; i < insn->n; i++) {
unsigned int val = data[i];
int ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: quatech_daqp_cs: fix no-op loop daqp_ao_insn_write()
On 05/06/18 10:36, Dan Carpenter wrote:
There is a '>' vs '<' typo so this loop is a no-op.
Fixes: d35dcc89fc93 ("staging: comedi: quatech_daqp_cs: fix
daqp_ao_insn_write()")
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index ea194aa01a64..257b0daff01f 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -642,7 +642,7 @@ static int daqp_ao_insn_write(struct comedi_device *dev,
/* Make sure D/A update mode is direct update */
outb(0, dev->iobase + DAQP_AUX_REG);
- for (i = 0; i > insn->n; i++) {
+ for (i = 0; i < insn->n; i++) {
unsigned int val = data[i];
int ret;
Thanks for catching that bug!
Reviewed-by: Ian Abbott
--
-=( Ian Abbott || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-gpio: move out of staging
On Mon, Jun 04, 2018 at 12:09:38PM +0300, Dan Carpenter wrote: > Looks like a nice driver to me now. Thanks! Thanks, Dan. Let's wait for feedback from gpio and device tree guys. > > regards, > dan carpenter > Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: fix some endianness sparse warnings
On Tue, 5 Jun 2018 10:33:25 +0200
Thibaut Robert wrote:
> Le mardi 05 juin 2018 à 10:36:31 (+0300), Dan Carpenter a écrit :
> > On Mon, Jun 04, 2018 at 09:32:50PM +0200, Thibaut Robert wrote:
> > > Le mercredi 30 mai 2018 à 14:17:25 (+0300), Dan Carpenter a
> > > écrit :
> > > > On Tue, May 29, 2018 at 09:11:43PM +0200, Thibaut Robert
> > > > wrote:
> > > > > diff --git
> > > > > a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> > > > > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index
> > > > > e248702ee519..745bf5ca2622 100644 ---
> > > > > a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++
> > > > > b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@
> > > > > -1431,7 +1431,7 @@ void wilc_wfi_p2p_rx(struct net_device
> > > > > *dev, u8 *buff, u32 size) freq =
> > > > > ieee80211_channel_to_frequency(curr_channel,
> > > > > NL80211_BAND_2GHZ);
> > > > > - if (!ieee80211_is_action(buff[FRAME_TYPE_ID])) {
> > > > > + if
> > > > > (!ieee80211_is_action(cpu_to_le16(buff[FRAME_TYPE_ID]))) {
> > > >
> > > > "buff" comes from the network, it's going to be little endian,
> > > > not cpu endian. The rest of the function treats it as CPU
> > > > endian but I'm pretty sure it's wrong...
> > > buff comes from the network but we are looking at single byte
> > > here. ieee80211_is_action expects an le16, so we I added this to
> > > extend an u8 to an le16. Is this incorrect ?
> > >
> > > Or maybe we the buff has the second byte ? but that I can't
> > > tell.
> >
> > You raise a good point that I hadn't seen. The original code is
> > clearly buggy. But your fix isn't correct either... The other
> > thing to consider is that cpu_to_le16() is basically a cast to u16
> > on x86 so it's a no-op here.
> The sparse warning is clearly spotting a real issue. I tried to at
> least have big endian handle correctly the 0-255 case. I am willing
> to drop the change (since I agree it's not very satisfying and will
> mask an issue), but may I ask you to explain how it is wrong ? How
> would you correctly expand an u8 to __le16 ? I think in big endian we
> need to swap the bytes.
>
Yes, when sending the data to ieee80211_is_action() it should pass
16bit value instead of 8bit value. It should be corrected.
But the buff received from the wifi module is already in little endian
format. As the data is already in LE endian format so in my opinion
the conversion is not required while calling ieee80211_is_action().
> >
> > Really the right thing is to not treat buff as an array of u8 but a
> > struct. The code assumes that frame_type is 0-255 but probably it's
> > supposed to go up to U16_MAX.
> >
> > struct whatever {
> > __le16 frame_type;
> > ...
> >
> > There probably is already a struct like that, but I don't know what
> > it is. I don't know this code at all, I'm just guessing.
> >
> I was thinking the same. I don't know whether this buf contains a
> standard struct or something hw-specific. I'll try to dig further and
> submit a separate patch if I can. Maybe Aditya can give more
> information ?
>
The buffer structure contains both some custom information along
with standard info. As the frame_control is the first 2 byte in the in
buff so casting it can also help to extract frame_control.
Please refer the code in mgmt_tx() which use like below
const struct ieee80211_mgmt *mgmt;
mgmt = (const struct ieee80211_mgmt *)buf;
ieee80211_is_action(mgmt->frame_control)
I think another approach can be by using proper type cast with first 2
bytes of buffer(to extract 16bit value) and pass it to
ieee80211_is_action().
Regards,
Ajay
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [greybus-dev] [PATCH] Staging:greybus Fix comparison to NULL
On 06/05/2018 04:00 AM, Dan Carpenter wrote:
> On Tue, Jun 05, 2018 at 11:02:36AM +0530, Viresh Kumar wrote:
>> On 03-06-18, 08:52, Janani Sankara Babu wrote:
>>> This patch replaces comparison of var to NULL with !var
>>>
>>> Signed-off-by: Janani Sankara Babu
Wow, such deep discussion for such a trivial patch!
I say we take it, mostly because I personally prefer being
permissive if there's nothing technically wrong with a patch,
but also because I'm swayed by the other comments.
That being said, I agree with Johan--the patch would be
improved with a little better comment about what motivated
the submission. So I'll wait for v2.
-Alex
>>> ---
>>> drivers/staging/greybus/core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/greybus/core.c b/drivers/staging/greybus/core.c
>>> index dafa430..5d14a4e 100644
>>> --- a/drivers/staging/greybus/core.c
>>> +++ b/drivers/staging/greybus/core.c
>>> @@ -48,7 +48,7 @@ static bool greybus_match_one_id(struct gb_bundle *bundle,
>>> static const struct greybus_bundle_id *
>>> greybus_match_id(struct gb_bundle *bundle, const struct greybus_bundle_id
>>> *id)
>>> {
>>> - if (id == NULL)
>>> + if (!id)
>>
>> It is pretty much personal preference and there is no good reason to accept
>> this
>> patch really.
>
> Checkpatch complains, so it's Official Kernel Style now.
>
> The != NULL comparison is a double negative which makes it not less
> annoying than official kernel style.
>
> regards,
> dan carpenter
>
> ___
> greybus-dev mailing list
> greybus-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/greybus-dev
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [RFC Patch 1/3] X86/Hyper-V: Add flush HvFlushGuestPhysicalAddressSpace hypercall support
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf
> Of Tianyu Lan
> Sent: Monday, June 4, 2018 2:08 AM
> Cc: Tianyu Lan ; KY Srinivasan
> ; Haiyang
> Zhang ; Stephen Hemminger ;
> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> pbonz...@redhat.com; rkrc...@redhat.com; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; k...@vger.kernel.org; vkuzn...@redhat.com
> Subject: [RFC Patch 1/3] X86/Hyper-V: Add flush
> HvFlushGuestPhysicalAddressSpace hypercall
> support
>
> Hyper-V provides a pv hypercall HvFlushGuestPhysicalAddressSpace to flush
> nested VM address space mapping in l1 hypervisor and it's to reduce overhead
> of flushing ept tlb among vcpus. This patch is to implement it.
>
> Signed-off-by: Lan Tianyu
> ---
> diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
> new file mode 100644
> index ..17f7c288eccc
> --- /dev/null
> +++ b/arch/x86/hyperv/nested.c
> +#include
> +#include
> +#include
> +#include
> +
> +int hyperv_flush_guest_mapping(u64 as)
> +{
> + struct hv_guest_mapping_flush **flush_pcpu;
> + struct hv_guest_mapping_flush *flush;
> + u64 status = U64_MAX;
Initializing status to U64_MAX doesn't seem necessary.
> + unsigned long flags;
> + int ret = -EFAULT;
> +
> + if (!hv_hypercall_pg)
> + goto fault;
> +
> + local_irq_save(flags);
> +
> + flush_pcpu = (struct hv_guest_mapping_flush **)
> + this_cpu_ptr(hyperv_pcpu_input_arg);
> +
> + flush = *flush_pcpu;
> +
> + if (unlikely(!flush)) {
> + local_irq_restore(flags);
> + goto fault;
> + }
> +
> + flush->address_space = as;
> + flush->flags = 0;
> +
> + status = hv_do_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE,
> + flush, NULL);
> + local_irq_restore(flags);
> +
> + if (!(status & HV_HYPERCALL_RESULT_MASK))
> + ret = 0;
> +
> +fault:
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
> diff --git a/arch/x86/include/asm/hyperv-tlfs.h
> b/arch/x86/include/asm/hyperv-tlfs.h
> index b8c89265baf0..53bbeb08faea 100644
> --- a/arch/x86/include/asm/hyperv-tlfs.h
> +++ b/arch/x86/include/asm/hyperv-tlfs.h
> @@ -309,6 +309,7 @@ struct ms_hyperv_tsc_page {
> #define HV_X64_MSR_REENLIGHTENMENT_CONTROL 0x4106
>
> /* Nested features (CPUID 0x400A) EAX */
> +#define HV_X64_NESTED_GUSET_MAPPING_FLUSHBIT(18)
The #define name is misspelled. "_GUSET_" should be "_GUEST_".
And the matching usage in patch 3/3 will need to be updated as well.
Michael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hv_netvsc: add per-cpu ethtool stats for netvsc
This patch implements following ethtool stats fields for netvsc:
cpu_rx_packets
cpu_tx_packets
cpu_rx_bytes
cpu_tx_bytes
cpu_vf_rx_packets
cpu_vf_tx_packets
cpu_vf_rx_bytes
cpu_vf_tx_bytes
---
drivers/net/hyperv/hyperv_net.h | 11 +
drivers/net/hyperv/netvsc_drv.c | 95 -
2 files changed, 104 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 960f061..f8c798b 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -710,6 +710,17 @@ struct netvsc_ethtool_stats {
unsigned long wake_queue;
};
+struct netvsc_ethtool_pcpu_stats {
+ u64 rx_packets;
+ u64 rx_bytes;
+ u64 tx_packets;
+ u64 tx_bytes;
+ u64 vf_rx_packets;
+ u64 vf_rx_bytes;
+ u64 vf_tx_packets;
+ u64 vf_tx_bytes;
+};
+
struct netvsc_vf_pcpu_stats {
u64 rx_packets;
u64 rx_bytes;
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index da07ccd..ef6ea1d 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1104,6 +1104,66 @@ static void netvsc_get_vf_stats(struct net_device *net,
}
}
+static void netvsc_get_pcpu_stats(struct net_device *net,
+ struct netvsc_ethtool_pcpu_stats __percpu
*pcpu_tot)
+{
+ struct net_device_context *ndev_ctx = netdev_priv(net);
+ struct netvsc_device *nvdev = rcu_dereference_rtnl(ndev_ctx->nvdev);
+ int i;
+
+ // fetch percpu stats of vf
+ for_each_possible_cpu(i) {
+ const struct netvsc_vf_pcpu_stats *stats
+= per_cpu_ptr(ndev_ctx->vf_stats, i);
+ struct netvsc_ethtool_pcpu_stats *this_tot
+ = per_cpu_ptr(pcpu_tot, i);
+ unsigned int start;
+
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ this_tot->vf_rx_packets = stats->rx_packets;
+ this_tot->vf_tx_packets = stats->tx_packets;
+ this_tot->vf_rx_bytes = stats->rx_bytes;
+ this_tot->vf_tx_bytes = stats->tx_bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+ this_tot->rx_packets = this_tot->vf_rx_packets;
+ this_tot->tx_packets = this_tot->vf_tx_packets;
+ this_tot->rx_bytes = this_tot->vf_rx_bytes;
+ this_tot->tx_bytes = this_tot->vf_tx_bytes;
+ }
+
+ // fetch percpu stats of netvsc
+ for (i = 0; i < nvdev->num_chn; i++) {
+ const struct netvsc_channel *nvchan = &nvdev->chan_table[i];
+ const struct netvsc_stats *stats;
+ struct netvsc_ethtool_pcpu_stats *this_tot
+ = per_cpu_ptr(pcpu_tot, nvchan->channel->target_cpu);
+ u64 packets, bytes;
+ unsigned int start;
+
+
+ stats = &nvchan->tx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->tx_bytes += bytes;
+ this_tot->tx_packets+= packets;
+
+ stats = &nvchan->rx_stats;
+ do {
+ start = u64_stats_fetch_begin_irq(&stats->syncp);
+ packets = stats->packets;
+ bytes = stats->bytes;
+ } while (u64_stats_fetch_retry_irq(&stats->syncp, start));
+
+ this_tot->rx_bytes += bytes;
+ this_tot->rx_packets+= packets;
+ }
+}
+
static void netvsc_get_stats64(struct net_device *net,
struct rtnl_link_stats64 *t)
{
@@ -1201,6 +1261,15 @@ static const struct {
{ "rx_no_memory", offsetof(struct netvsc_ethtool_stats, rx_no_memory) },
{ "stop_queue", offsetof(struct netvsc_ethtool_stats, stop_queue) },
{ "wake_queue", offsetof(struct netvsc_ethtool_stats, wake_queue) },
+}, pcpu_stats[] = {
+ { "cpu%u_rx_packets", offsetof(struct netvsc_ethtool_pcpu_stats,
rx_packets) },
+ { "cpu%u_rx_bytes", offsetof(struct netvsc_ethtool_pcpu_stats,
rx_bytes) },
+ { "cpu%u_tx_packets", offsetof(struct netvsc_ethtool_pcpu_stats,
tx_packets) },
+ { "cpu%u_tx_bytes", offsetof(struct netvsc_ethtool_pcpu_stats,
tx_bytes) },
+ { "cpu%u_vf_rx_packets", offsetof(struct netvsc_ethtool_pcpu_stats,
vf_rx_packets) },
+ { "cpu%u_vf_rx_bytes", offsetof(struct netvsc_ethtool_pcpu_stats,
vf_rx_bytes) },
+ { "cpu%u_vf_tx_packets", offsetof(struct netvsc_ethtool_pcpu_stats,
vf_tx_packets) },
+ { "cpu%u_vf_tx_bytes", offsetof(s
[PATCH 0/8] Drivers: hv: Miscellaneous fixes/improvements
From: "K. Y. Srinivasan" Some miscellaneous fixes/improvements. Arjan van de Ven (1): use the new async probing feature for the hyperv drivers Dexuan Cui (1): Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer() Michael Kelley (4): x86/hyperv: Add interrupt handler annotations Drivers: hv: vmbus: Add comments on ring buffer signaling Drivers: hv: vmbus: Remove x86 MSR refs in arch independent code Drivers: hv: vmbus: Make TLFS #define names architecture neutral Olaf Hering (1): tools: hv: update lsvmbus to be compatible with python3 Vitaly Kuznetsov (1): Tools: hv: vss: fix loop device detection arch/x86/hyperv/hv_init.c | 4 +- arch/x86/include/asm/hyperv-tlfs.h| 12 ++--- arch/x86/include/asm/mshyperv.h | 12 +++-- arch/x86/kernel/cpu/mshyperv.c| 6 +-- drivers/hid/hid-hyperv.c | 3 ++ drivers/hv/channel_mgmt.c | 4 +- drivers/hv/hv.c | 30 ++--- drivers/hv/hv_balloon.c | 3 ++ drivers/hv/hv_util.c | 3 ++ drivers/hv/ring_buffer.c | 65 ++- drivers/input/serio/hyperv-keyboard.c | 3 ++ drivers/net/hyperv/netvsc_drv.c | 3 ++ drivers/scsi/storvsc_drv.c| 3 ++ drivers/video/fbdev/hyperv_fb.c | 6 +++ include/linux/hyperv.h| 31 + tools/hv/hv_vss_daemon.c | 65 +-- tools/hv/lsvmbus | 12 ++--- 17 files changed, 201 insertions(+), 64 deletions(-) -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/8] Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer()
From: Dexuan Cui
I didn't really hit a real bug, but just happened to spot the bug:
we have decreased the counter at the beginning of vmbus_process_offer(),
so we mustn't decrease it again.
Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues")
Signed-off-by: Dexuan Cui
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Stable # 4.14 and above
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index ecc2bd275a73..f3b551a50653 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -527,10 +527,8 @@ static void vmbus_process_offer(struct vmbus_channel
*newchannel)
struct hv_device *dev
= newchannel->primary_channel->device_obj;
- if (vmbus_add_channel_kobj(dev, newchannel)) {
- atomic_dec(&vmbus_connection.offer_in_progress);
+ if (vmbus_add_channel_kobj(dev, newchannel))
goto err_free_chan;
- }
if (channel->sc_creation_callback != NULL)
channel->sc_creation_callback(newchannel);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/8] Drivers: hv: vmbus: Add comments on ring buffer signaling
From: Michael Kelley
Add comments describing intricacies of Hyper-V ring buffer
signaling code. This information is not in Hyper-V public
documents, so include here to capture the knowledge for
future coders.
There are no code changes in this commit.
Signed-off-by: Michael Kelley
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/ring_buffer.c | 65 +---
include/linux/hyperv.h | 31 ++-
2 files changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 8699bb969e7e..ce6ea6dad490 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -429,7 +429,24 @@ static u32 hv_pkt_iter_bytes_read(const struct
hv_ring_buffer_info *rbi,
}
/*
- * Update host ring buffer after iterating over packets.
+ * Update host ring buffer after iterating over packets. If the host has
+ * stopped queuing new entries because it found the ring buffer full, and
+ * sufficient space is being freed up, signal the host. But be careful to
+ * only signal the host when necessary, both for performance reasons and
+ * because Hyper-V protects itself by throttling guests that signal
+ * inappropriately.
+ *
+ * Determining when to signal is tricky. There are three key data inputs
+ * that must be handled in this order to avoid race conditions:
+ *
+ * 1. Update the read_index
+ * 2. Read the pending_send_sz
+ * 3. Read the current write_index
+ *
+ * The interrupt_mask is not used to determine when to signal. The
+ * interrupt_mask is used only on the guest->host ring buffer when
+ * sending requests to the host. The host does not use it on the host->
+ * guest ring buffer to indicate whether it should be signaled.
*/
void hv_pkt_iter_close(struct vmbus_channel *channel)
{
@@ -445,22 +462,30 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
start_read_index = rbi->ring_buffer->read_index;
rbi->ring_buffer->read_index = rbi->priv_read_index;
+ /*
+* Older versions of Hyper-V (before WS2102 and Win8) do not
+* implement pending_send_sz and simply poll if the host->guest
+* ring buffer is full. No signaling is needed or expected.
+*/
if (!rbi->ring_buffer->feature_bits.feat_pending_send_sz)
return;
/*
* Issue a full memory barrier before making the signaling decision.
-* Here is the reason for having this barrier:
-* If the reading of the pend_sz (in this function)
-* were to be reordered and read before we commit the new read
-* index (in the calling function) we could
-* have a problem. If the host were to set the pending_sz after we
-* have sampled pending_sz and go to sleep before we commit the
+* If reading pending_send_sz were to be reordered and happen
+* before we commit the new read_index, a race could occur. If the
+* host were to set the pending_send_sz after we have sampled
+* pending_send_sz, and the ring buffer blocks before we commit the
* read index, we could miss sending the interrupt. Issue a full
* memory barrier to address this.
*/
virt_mb();
+ /*
+* If the pending_send_sz is zero, then the ring buffer is not
+* blocked and there is no need to signal. This is far by the
+* most common case, so exit quickly for best performance.
+*/
pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
if (!pending_sz)
return;
@@ -474,14 +499,32 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
bytes_read = hv_pkt_iter_bytes_read(rbi, start_read_index);
/*
-* If there was space before we began iteration,
-* then host was not blocked.
+* We want to signal the host only if we're transitioning
+* from a "not enough free space" state to a "enough free
+* space" state. For example, it's possible that this function
+* could run and free up enough space to signal the host, and then
+* run again and free up additional space before the host has a
+* chance to clear the pending_send_sz. The 2nd invocation would
+* be a null transition from "enough free space" to "enough free
+* space", which doesn't warrant a signal.
+*
+* Exactly filling the ring buffer is treated as "not enough
+* space". The ring buffer always must have at least one byte
+* empty so the empty and full conditions are distinguishable.
+* hv_get_bytes_to_write() doesn't fully tell the truth in
+* this regard.
+*
+* So first check if we were in the "enough free space" state
+* before we began the iteration. If so, the host was not
+* blocked, and there's no need to signal.
*/
-
if (curr_write_sz - bytes_read > pending_sz)
return;
- /
[PATCH 7/8] tools: hv: update lsvmbus to be compatible with python3
From: Olaf Hering
Python3 changed the way how 'print' works.
Adjust the code to a syntax that is understood by python2 and python3.
Signed-off-by: Olaf Hering
Acked-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
tools/hv/lsvmbus | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/hv/lsvmbus b/tools/hv/lsvmbus
index 353e56768df8..55e7374bade0 100644
--- a/tools/hv/lsvmbus
+++ b/tools/hv/lsvmbus
@@ -17,7 +17,7 @@ if options.verbose is not None:
vmbus_sys_path = '/sys/bus/vmbus/devices'
if not os.path.isdir(vmbus_sys_path):
- print "%s doesn't exist: exiting..." % vmbus_sys_path
+ print("%s doesn't exist: exiting..." % vmbus_sys_path)
exit(-1)
vmbus_dev_dict = {
@@ -93,11 +93,11 @@ format2 = '%2s: Class_ID = %s - %s\n\tDevice_ID =
%s\n\tSysfs path: %s\n%s'
for d in vmbus_dev_list:
if verbose == 0:
- print ('VMBUS ID ' + format0) % (d.vmbus_id, d.dev_desc)
+ print(('VMBUS ID ' + format0) % (d.vmbus_id, d.dev_desc))
elif verbose == 1:
- print ('VMBUS ID ' + format1) % \
- (d.vmbus_id, d.class_id, d.dev_desc, d.chn_vp_mapping)
+ print (('VMBUS ID ' + format1) %\
+ (d.vmbus_id, d.class_id, d.dev_desc, d.chn_vp_mapping))
else:
- print ('VMBUS ID ' + format2) % \
+ print (('VMBUS ID ' + format2) % \
(d.vmbus_id, d.class_id, d.dev_desc, \
- d.device_id, d.sysfs_path, d.chn_vp_mapping)
+ d.device_id, d.sysfs_path, d.chn_vp_mapping))
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/8] Drivers: hv: vmbus: Remove x86 MSR refs in arch independent code
From: Michael Kelley
In architecture independent code for manipulating Hyper-V synthetic timers
and synthetic interrupts, pass in an ordinal number identifying the timer
or interrupt, rather than an actual MSR register address. Then in
x86/x64 specific code, map the ordinal number to the appropriate MSR.
This change facilitates the introduction of an ARM64 version of Hyper-V,
which uses the same synthetic timers and interrupts, but a different
mechanism for accessing them.
Signed-off-by: Michael Kelley
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h | 12
drivers/hv/hv.c | 20
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b90e79610cf7..caf9035a2758 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -75,8 +75,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg,
u32 old_msg_type)
}
}
-#define hv_init_timer(timer, tick) wrmsrl(timer, tick)
-#define hv_init_timer_config(config, val) wrmsrl(config, val)
+#define hv_init_timer(timer, tick) \
+ wrmsrl(HV_X64_MSR_STIMER0_COUNT + (2*timer), tick)
+#define hv_init_timer_config(timer, val) \
+ wrmsrl(HV_X64_MSR_STIMER0_CONFIG + (2*timer), val)
#define hv_get_simp(val) rdmsrl(HV_X64_MSR_SIMP, val)
#define hv_set_simp(val) wrmsrl(HV_X64_MSR_SIMP, val)
@@ -89,8 +91,10 @@ static inline void vmbus_signal_eom(struct hv_message *msg,
u32 old_msg_type)
#define hv_get_vp_index(index) rdmsrl(HV_X64_MSR_VP_INDEX, index)
-#define hv_get_synint_state(int_num, val) rdmsrl(int_num, val)
-#define hv_set_synint_state(int_num, val) wrmsrl(int_num, val)
+#define hv_get_synint_state(int_num, val) \
+ rdmsrl(HV_X64_MSR_SINT0 + int_num, val)
+#define hv_set_synint_state(int_num, val) \
+ wrmsrl(HV_X64_MSR_SINT0 + int_num, val)
void hyperv_callback_vector(void);
void hyperv_reenlightenment_vector(void);
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 9b82549cbbc8..96c403a07906 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -127,14 +127,14 @@ static int hv_ce_set_next_event(unsigned long delta,
current_tick = hyperv_cs->read(NULL);
current_tick += delta;
- hv_init_timer(HV_X64_MSR_STIMER0_COUNT, current_tick);
+ hv_init_timer(0, current_tick);
return 0;
}
static int hv_ce_shutdown(struct clock_event_device *evt)
{
- hv_init_timer(HV_X64_MSR_STIMER0_COUNT, 0);
- hv_init_timer_config(HV_X64_MSR_STIMER0_CONFIG, 0);
+ hv_init_timer(0, 0);
+ hv_init_timer_config(0, 0);
if (direct_mode_enabled)
hv_disable_stimer0_percpu_irq(stimer0_irq);
@@ -164,7 +164,7 @@ static int hv_ce_set_oneshot(struct clock_event_device *evt)
timer_cfg.direct_mode = 0;
timer_cfg.sintx = VMBUS_MESSAGE_SINT;
}
- hv_init_timer_config(HV_X64_MSR_STIMER0_CONFIG, timer_cfg.as_uint64);
+ hv_init_timer_config(0, timer_cfg.as_uint64);
return 0;
}
@@ -298,8 +298,7 @@ int hv_synic_init(unsigned int cpu)
hv_set_siefp(siefp.as_uint64);
/* Setup the shared SINT. */
- hv_get_synint_state(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT,
- shared_sint.as_uint64);
+ hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
shared_sint.vector = HYPERVISOR_CALLBACK_VECTOR;
shared_sint.masked = false;
@@ -308,8 +307,7 @@ int hv_synic_init(unsigned int cpu)
else
shared_sint.auto_eoi = true;
- hv_set_synint_state(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT,
- shared_sint.as_uint64);
+ hv_set_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
/* Enable the global synic bit */
hv_get_synic_state(sctrl.as_uint64);
@@ -405,15 +403,13 @@ int hv_synic_cleanup(unsigned int cpu)
put_cpu_ptr(hv_cpu);
}
- hv_get_synint_state(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT,
- shared_sint.as_uint64);
+ hv_get_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
shared_sint.masked = 1;
/* Need to correctly cleanup in the case of SMP!!! */
/* Disable the interrupt */
- hv_set_synint_state(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT,
- shared_sint.as_uint64);
+ hv_set_synint_state(VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
hv_get_simp(simp.as_uint64);
simp.simp_enabled = 0;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/8] use the new async probing feature for the hyperv drivers
From: Arjan van de Ven
Recent kernels support asynchronous probing; most hyperv drivers
can be probed async easily so set the required flag for this.
Signed-off-by: Arjan van de Ven
Signed-off-by: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
drivers/hid/hid-hyperv.c | 3 +++
drivers/hv/hv_balloon.c | 3 +++
drivers/hv/hv_util.c | 3 +++
drivers/input/serio/hyperv-keyboard.c | 3 +++
drivers/net/hyperv/netvsc_drv.c | 3 +++
drivers/scsi/storvsc_drv.c| 3 +++
drivers/video/fbdev/hyperv_fb.c | 6 ++
7 files changed, 24 insertions(+)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 3aa2bb9f0f81..b372854cf38d 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -598,6 +598,9 @@ static struct hv_driver mousevsc_drv = {
.id_table = id_table,
.probe = mousevsc_probe,
.remove = mousevsc_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
static int __init mousevsc_init(void)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b3e9f13f8bc3..b1b788082793 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1765,6 +1765,9 @@ static struct hv_driver balloon_drv = {
.id_table = id_table,
.probe = balloon_probe,
.remove = balloon_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
static int __init init_balloon_drv(void)
diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 14dce25c104f..423205077bf6 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -487,6 +487,9 @@ static struct hv_driver util_drv = {
.id_table = id_table,
.probe = util_probe,
.remove = util_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
static int hv_ptp_enable(struct ptp_clock_info *info,
diff --git a/drivers/input/serio/hyperv-keyboard.c
b/drivers/input/serio/hyperv-keyboard.c
index 25151d9214e0..47a0e81a2989 100644
--- a/drivers/input/serio/hyperv-keyboard.c
+++ b/drivers/input/serio/hyperv-keyboard.c
@@ -424,6 +424,9 @@ static struct hv_driver hv_kbd_drv = {
.id_table = id_table,
.probe = hv_kbd_probe,
.remove = hv_kbd_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
static int __init hv_kbd_init(void)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index ecc84954c511..3965c62e79ba 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2155,6 +2155,9 @@ static struct hv_driver netvsc_drv = {
.id_table = id_table,
.probe = netvsc_probe,
.remove = netvsc_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
/*
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8c51d628b52e..32027ac60aa4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1893,6 +1893,9 @@ static struct hv_driver storvsc_drv = {
.id_table = id_table,
.probe = storvsc_probe,
.remove = storvsc_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 2fd49b2358f8..403d8cd3e582 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -912,6 +912,9 @@ static struct hv_driver hvfb_drv = {
.id_table = id_table,
.probe = hvfb_probe,
.remove = hvfb_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
};
static int hvfb_pci_stub_probe(struct pci_dev *pdev,
@@ -929,6 +932,9 @@ static struct pci_driver hvfb_pci_stub_driver = {
.id_table = pci_stub_id_table,
.probe =hvfb_pci_stub_probe,
.remove = hvfb_pci_stub_remove,
+ .driver = {
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ }
};
static int __init hvfb_drv_init(void)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/8] Tools: hv: vss: fix loop device detection
From: Vitaly Kuznetsov
Commit ea81fdf0981d ("Tools: hv: vss: Skip freezing filesystems backed by
loop") added skip for filesystems backed by loop device. However, it seems
the detection of such cases is incomplete.
It was found that with 'devicemapper' storage driver docker creates the
following chain:
NAMEMAJ:MIN
loop0 7:0
..docker-8:4-8473394-pool 253:0
..docker-8:4-8473394-eac... 253:1
so when we're looking at the mounted device we see major '253' and not '7'.
Solve the issue by walking /sys/dev/block/*/slaves chain and checking if
there's a loop device somewhere.
Other than that, don't skip mountpoints silently when stat() fails. In case
e.g. SELinux is failing stat we don't want to skip freezing everything
without letting user know about the failure.
Fixes: ea81fdf0981d ("Tools: hv: vss: Skip freezing filesystems backed by loop")
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
tools/hv/hv_vss_daemon.c | 65 +---
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 34031a297f02..b13300172762 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -36,6 +36,8 @@
#include
#include
#include
+#include
+#include
/* Don't use syslog() in the function since that can cause write to disk */
static int vss_do_freeze(char *dir, unsigned int cmd)
@@ -68,6 +70,55 @@ static int vss_do_freeze(char *dir, unsigned int cmd)
return !!ret;
}
+static bool is_dev_loop(const char *blkname)
+{
+ char *buffer;
+ DIR *dir;
+ struct dirent *entry;
+ bool ret = false;
+
+ buffer = malloc(PATH_MAX);
+ if (!buffer) {
+ syslog(LOG_ERR, "Can't allocate memory!");
+ exit(1);
+ }
+
+ snprintf(buffer, PATH_MAX, "%s/loop", blkname);
+ if (!access(buffer, R_OK | X_OK)) {
+ ret = true;
+ goto free_buffer;
+ } else if (errno != ENOENT) {
+ syslog(LOG_ERR, "Can't access: %s; error:%d %s!",
+ buffer, errno, strerror(errno));
+ }
+
+ snprintf(buffer, PATH_MAX, "%s/slaves", blkname);
+ dir = opendir(buffer);
+ if (!dir) {
+ if (errno != ENOENT)
+ syslog(LOG_ERR, "Can't opendir: %s; error:%d %s!",
+ buffer, errno, strerror(errno));
+ goto free_buffer;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ if (strcmp(entry->d_name, ".") == 0 ||
+ strcmp(entry->d_name, "..") == 0)
+ continue;
+
+ snprintf(buffer, PATH_MAX, "%s/slaves/%s", blkname,
+entry->d_name);
+ if (is_dev_loop(buffer)) {
+ ret = true;
+ break;
+ }
+ }
+ closedir(dir);
+free_buffer:
+ free(buffer);
+ return ret;
+}
+
static int vss_operate(int operation)
{
char match[] = "/dev/";
@@ -75,6 +126,7 @@ static int vss_operate(int operation)
struct mntent *ent;
struct stat sb;
char errdir[1024] = {0};
+ char blkdir[23]; /* /sys/dev/block/XXX:XXX */
unsigned int cmd;
int error = 0, root_seen = 0, save_errno = 0;
@@ -96,10 +148,15 @@ static int vss_operate(int operation)
while ((ent = getmntent(mounts))) {
if (strncmp(ent->mnt_fsname, match, strlen(match)))
continue;
- if (stat(ent->mnt_fsname, &sb) == -1)
- continue;
- if (S_ISBLK(sb.st_mode) && major(sb.st_rdev) == LOOP_MAJOR)
- continue;
+ if (stat(ent->mnt_fsname, &sb)) {
+ syslog(LOG_ERR, "Can't stat: %s; error:%d %s!",
+ ent->mnt_fsname, errno, strerror(errno));
+ } else {
+ sprintf(blkdir, "/sys/dev/block/%d:%d",
+ major(sb.st_rdev), minor(sb.st_rdev));
+ if (is_dev_loop(blkdir))
+ continue;
+ }
if (hasmntopt(ent, MNTOPT_RO) != NULL)
continue;
if (strcmp(ent->mnt_type, "vfat") == 0)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/8] Drivers: hv: vmbus: Make TLFS #define names architecture neutral
From: Michael Kelley
The Hyper-V feature and hint flags in hyperv-tlfs.h are all defined
with the string "X64" in the name. Some of these flags are indeed
x86/x64 specific, but others are not. For the ones that are used
in architecture independent Hyper-V driver code, or will be used in
the upcoming support for Hyper-V for ARM64, this patch removes the
"X64" from the name.
This patch changes the flags that are currently known to be
used on multiple architectures. Hyper-V for ARM64 is still a
work-in-progress and the Top Level Functional Spec (TLFS) has not
been separated into x86/x64 and ARM64 areas. So additional flags
may need to be updated later.
This patch only changes symbol names. There are no functional
changes.
Signed-off-by: Michael Kelley
Signed-off-by: K. Y. Srinivasan
---
arch/x86/hyperv/hv_init.c | 4 ++--
arch/x86/include/asm/hyperv-tlfs.h | 12 ++--
arch/x86/kernel/cpu/mshyperv.c | 4 ++--
drivers/hv/hv.c| 10 +-
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index cfecc2272f2d..3db87293dce0 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -302,7 +302,7 @@ void hyperv_init(void)
* Register Hyper-V specific clocksource.
*/
#ifdef CONFIG_HYPERV_TSCPAGE
- if (ms_hyperv.features & HV_X64_MSR_REFERENCE_TSC_AVAILABLE) {
+ if (ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE) {
union hv_x64_msr_hypercall_contents tsc_msr;
tsc_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
@@ -331,7 +331,7 @@ void hyperv_init(void)
*/
hyperv_cs = &hyperv_cs_msr;
- if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
+ if (ms_hyperv.features & HV_MSR_TIME_REF_COUNT_AVAILABLE)
clocksource_register_hz(&hyperv_cs_msr, NSEC_PER_SEC/100);
return;
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index 416cb0e0c496..44657e07fd59 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -35,9 +35,9 @@
/* VP Runtime (HV_X64_MSR_VP_RUNTIME) available */
#define HV_X64_MSR_VP_RUNTIME_AVAILABLE(1 << 0)
/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
-#define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE(1 << 1)
+#define HV_MSR_TIME_REF_COUNT_AVAILABLE(1 << 1)
/* Partition reference TSC MSR is available */
-#define HV_X64_MSR_REFERENCE_TSC_AVAILABLE (1 << 9)
+#define HV_MSR_REFERENCE_TSC_AVAILABLE (1 << 9)
/* A partition's reference time stamp counter (TSC) page */
#define HV_X64_MSR_REFERENCE_TSC 0x4021
@@ -60,7 +60,7 @@
* Synthetic Timer MSRs (HV_X64_MSR_STIMER0_CONFIG through
* HV_X64_MSR_STIMER3_COUNT) available
*/
-#define HV_X64_MSR_SYNTIMER_AVAILABLE (1 << 3)
+#define HV_MSR_SYNTIMER_AVAILABLE (1 << 3)
/*
* APIC access MSRs (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR)
* are available
@@ -86,7 +86,7 @@
#define HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE (1 << 10)
/* stimer Direct Mode is available */
-#define HV_X64_STIMER_DIRECT_MODE_AVAILABLE(1 << 19)
+#define HV_STIMER_DIRECT_MODE_AVAILABLE(1 << 19)
/*
* Feature identification: EBX indicates which flags were specified at
@@ -160,9 +160,9 @@
#define HV_X64_RELAXED_TIMING_RECOMMENDED (1 << 5)
/*
- * Virtual APIC support
+ * Recommend not using Auto End-Of-Interrupt feature
*/
-#define HV_X64_DEPRECATING_AEOI_RECOMMENDED(1 << 9)
+#define HV_DEPRECATING_AEOI_RECOMMENDED(1 << 9)
/* Recommend using the newer ExProcessorMasks interface */
#define HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED (1 << 11)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 8a49b7ef7b76..ad12733f6058 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -50,7 +50,7 @@ __visible void __irq_entry hyperv_vector_handler(struct
pt_regs *regs)
if (vmbus_handler)
vmbus_handler();
- if (ms_hyperv.hints & HV_X64_DEPRECATING_AEOI_RECOMMENDED)
+ if (ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED)
ack_APIC_irq();
exiting_irq();
@@ -300,7 +300,7 @@ static void __init ms_hyperv_init_platform(void)
hyperv_reenlightenment_vector);
/* Setup the IDT for stimer0 */
- if (ms_hyperv.misc_features & HV_X64_STIMER_DIRECT_MODE_AVAILABLE)
+ if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE)
alloc_intr_gate(HYPERV_STIMER0_VECTOR,
hv_stimer0_callback_vector);
#endif
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 96c403a07906..c72e8d7bd7fc 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -64,7 +64,7 @@ int hv_init(void)
[PATCH 2/8] x86/hyperv: Add interrupt handler annotations
From: Michael Kelley
Add standard interrupt handler annotations to
hyperv_vector_handler(). This does not fix any observed
bug, but avoids potential removal of the code by link
time optimization and makes it consistent with
hv_stimer0_vector_handler in the same source file.
Suggested-by: Thomas Gleixner
Signed-off-by: Michael Kelley
Signed-off-by: K. Y. Srinivasan
---
arch/x86/kernel/cpu/mshyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 031082c96db8..8a49b7ef7b76 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -41,7 +41,7 @@ static void (*hv_stimer0_handler)(void);
static void (*hv_kexec_handler)(void);
static void (*hv_crash_handler)(struct pt_regs *regs);
-void hyperv_vector_handler(struct pt_regs *regs)
+__visible void __irq_entry hyperv_vector_handler(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 03/21] Staging: gdm724x: use match_string() helper
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Greg Kroah-Hartman
Cc: Quytelda Kahja
Cc: de...@driverdev.osuosl.org
Signed-off-by: Yisheng Xie
---
v3:
- no need to check input tty's index - per Greg
v2:
- const DRIVER_STRING instead - per Andy
drivers/staging/gdm724x/gdm_tty.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_tty.c
b/drivers/staging/gdm724x/gdm_tty.c
index 3cdebb8..29ac6b5 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -43,7 +43,7 @@
static struct gdm *gdm_table[TTY_MAX_COUNT][GDM_TTY_MINOR];
static DEFINE_MUTEX(gdm_table_lock);
-static char *DRIVER_STRING[TTY_MAX_COUNT] = {"GCTATC", "GCTDM"};
+static const char *DRIVER_STRING[TTY_MAX_COUNT] = {"GCTATC", "GCTDM"};
static char *DEVICE_STRING[TTY_MAX_COUNT] = {"GCT-ATC", "GCT-DM"};
static void gdm_port_destruct(struct tty_port *port)
@@ -65,22 +65,14 @@ static int gdm_tty_install(struct tty_driver *driver,
struct tty_struct *tty)
{
struct gdm *gdm = NULL;
int ret;
- int i;
- int j;
-
- j = GDM_TTY_MINOR;
- for (i = 0; i < TTY_MAX_COUNT; i++) {
- if (!strcmp(tty->driver->driver_name, DRIVER_STRING[i])) {
- j = tty->index;
- break;
- }
- }
- if (j == GDM_TTY_MINOR)
+ ret = match_string(DRIVER_STRING, TTY_MAX_COUNT,
+ tty->driver->driver_name);
+ if (ret < 0)
return -ENODEV;
mutex_lock(&gdm_table_lock);
- gdm = gdm_table[i][j];
+ gdm = gdm_table[ret][tty->index];
if (!gdm) {
mutex_unlock(&gdm_table_lock);
return -ENODEV;
--
1.7.12.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC Patch 1/3] X86/Hyper-V: Add flush HvFlushGuestPhysicalAddressSpace hypercall support
Hi Michael:
Thanks for your review.
On 6/6/2018 12:59 AM, Michael Kelley (EOSG) wrote:
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org
>> On Behalf
>> Of Tianyu Lan
>> Sent: Monday, June 4, 2018 2:08 AM
>> Cc: Tianyu Lan ; KY Srinivasan
>> ; Haiyang
>> Zhang ; Stephen Hemminger ;
>> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
>> pbonz...@redhat.com; rkrc...@redhat.com; de...@linuxdriverproject.org; linux-
>> ker...@vger.kernel.org; k...@vger.kernel.org; vkuzn...@redhat.com
>> Subject: [RFC Patch 1/3] X86/Hyper-V: Add flush
>> HvFlushGuestPhysicalAddressSpace hypercall
>> support
>>
>> Hyper-V provides a pv hypercall HvFlushGuestPhysicalAddressSpace to flush
>> nested VM address space mapping in l1 hypervisor and it's to reduce overhead
>> of flushing ept tlb among vcpus. This patch is to implement it.
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
>> new file mode 100644
>> index ..17f7c288eccc
>> --- /dev/null
>> +++ b/arch/x86/hyperv/nested.c
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +int hyperv_flush_guest_mapping(u64 as)
>> +{
>> +struct hv_guest_mapping_flush **flush_pcpu;
>> +struct hv_guest_mapping_flush *flush;
>> +u64 status = U64_MAX;
>
> Initializing status to U64_MAX doesn't seem necessary.
>
>> +unsigned long flags;
>> +int ret = -EFAULT;
>> +
>> +if (!hv_hypercall_pg)
>> +goto fault;
>> +
>> +local_irq_save(flags);
>> +
>> +flush_pcpu = (struct hv_guest_mapping_flush **)
>> +this_cpu_ptr(hyperv_pcpu_input_arg);
>> +
>> +flush = *flush_pcpu;
>> +
>> +if (unlikely(!flush)) {
>> +local_irq_restore(flags);
>> +goto fault;
>> +}
>> +
>> +flush->address_space = as;
>> +flush->flags = 0;
>> +
>> +status = hv_do_hypercall(HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE,
>> + flush, NULL);
>> +local_irq_restore(flags);
>> +
>> +if (!(status & HV_HYPERCALL_RESULT_MASK))
>> +ret = 0;
>> +
>> +fault:
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
>> diff --git a/arch/x86/include/asm/hyperv-tlfs.h
>> b/arch/x86/include/asm/hyperv-tlfs.h
>> index b8c89265baf0..53bbeb08faea 100644
>> --- a/arch/x86/include/asm/hyperv-tlfs.h
>> +++ b/arch/x86/include/asm/hyperv-tlfs.h
>> @@ -309,6 +309,7 @@ struct ms_hyperv_tsc_page {
>> #define HV_X64_MSR_REENLIGHTENMENT_CONTROL 0x4106
>>
>> /* Nested features (CPUID 0x400A) EAX */
>> +#define HV_X64_NESTED_GUSET_MAPPING_FLUSH BIT(18)
>
> The #define name is misspelled. "_GUSET_" should be "_GUEST_".
> And the matching usage in patch 3/3 will need to be updated as well.
>
> Michael
>
Nice catch! Will update.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
