Re: [PATCH 1/1] drivers: hv: hv_utils_transport: Fixing validation of correct pointer
Maninder Singh writes:
> cn_msg should be validated instead of msg after memory allocation.
>
Thanks,
This was already fixed by Dan:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-May/070193.html
my Reviewed-by:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-June/070599.html
but I don't see it in K. Y. recent submission to Greg. K. Y., could you
please pick it up?
> Signed-off-by: Maninder Singh
> Reviewed-by: Akhilesh Kumar
> ---
> drivers/hv/hv_utils_transport.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
> index ea7ba5e..6a9d80a 100644
> --- a/drivers/hv/hv_utils_transport.c
> +++ b/drivers/hv/hv_utils_transport.c
> @@ -186,7 +186,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt,
> void *msg, int len)
> return -EINVAL;
> } else if (hvt->mode == HVUTIL_TRANSPORT_NETLINK) {
> cn_msg = kzalloc(sizeof(*cn_msg) + len, GFP_ATOMIC);
> - if (!msg)
> + if (!cn_msg)
> return -ENOMEM;
> cn_msg->id.idx = hvt->cn_id.idx;
> cn_msg->id.val = hvt->cn_id.val;
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] defines modified to match the 80-char rule
Joe Perches writes: > -#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ## > __VA_ARGS__) > -#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ## > __VA_ARGS__) > -#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING, > format, ## __VA_ARGS__) > -#define LCONSOLE_ERROR_MSG(errnum, format, ...) CDEBUG_LIMIT(D_CONSOLE | > D_ERROR, \ > -"%x-%x: " format, errnum, LERRCHKSUM(errnum), ## > __VA_ARGS__) > -#define LCONSOLE_ERROR(format, ...) LCONSOLE_ERROR_MSG(0x00, format, ## > __VA_ARGS__) > +#define LCONSOLE(mask, fmt, ...) \ > + CDEBUG(D_CONSOLE | (mask), fmt, ##__VA_ARGS__) > +#define LCONSOLE_INFO(fmt, ...) > \ > + CDEBUG_LIMIT(D_CONSOLE, fmt, ##__VA_ARGS__) > +#define LCONSOLE_WARN(fmt, ...) > \ > + CDEBUG_LIMIT(D_CONSOLE | D_WARNING, fmt, ##__VA_ARGS__) > +#define LCONSOLE_ERROR_MSG(errnum, fmt, ...) \ > + CDEBUG_LIMIT(D_CONSOLE | D_ERROR, "%x-%x: " fmt,\ > + errnum, LERRCHKSUM(errnum), ##__VA_ARGS__) I don't find it better, actually I think it's much harder to read. Maybe that's just me. Call me extremist, but I think I could even like the following :-) #define CWARN(format, ...)CDEBUG_LIMIT(D_WARNING, format, ## __VA_ARGS__) #define CERROR(format, ...)CDEBUG_LIMIT(D_ERROR,format, ## __VA_ARGS__) #define CNETERR(format, ...)CDEBUG_LIMIT(D_NETERROR, format, ## __VA_ARGS__) #define CEMERG(format, ...)CDEBUG_LIMIT(D_EMERG,format, ## __VA_ARGS__) -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: Add support to set MTU reservation from guest side
On Thu, Jul 02, 2015 at 01:17:35PM -0700, Haiyang Zhang wrote: > When packet encapsulation is in use, the MTU needs to be reduced for > headroom reservation. > The existing code takes the updated MTU value only from the host side. > But vSwitch extensions, such as Open vSwitch, require the flexibility > to change the MTU to different values from within a guest during the > lifecycle of a vNIC, when the encapsulation protocol is changed. The > patch supports this kind of MTU changes. > > Signed-off-by: Haiyang Zhang > Reviewed-by: K. Y. Srinivasan > --- > drivers/net/hyperv/netvsc_drv.c |3 +-- > drivers/net/hyperv/rndis_filter.c |2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c > index 358475e..68e7ece 100644 > --- a/drivers/net/hyperv/netvsc_drv.c > +++ b/drivers/net/hyperv/netvsc_drv.c > @@ -743,8 +743,7 @@ static int netvsc_change_mtu(struct net_device *ndev, int > mtu) > if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2) > limit = NETVSC_MTU - ETH_HLEN; > > - /* Hyper-V hosts don't support MTU < ETH_DATA_LEN (1500) */ > - if (mtu < ETH_DATA_LEN || mtu > limit) > + if (mtu < 68 || mtu > limit) How did you calculate 68? Avoid magic numbers like this, make it a define. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INVESTMENT PROPOSAL.
Dear friend, I write to request your co-operation to assist me in the relocation and transfer of $20M which is presently available for investment.Reply me with your full names and phone number.so that i will send you the details. Sincerely,Stella Chimbet ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [lustre-devel] LIBCFS_ALLOC
On 2015/07/02, 4:25 PM, "Simmons, James A." wrote: > >>> >Yeah. You're right. Doing a vmalloc() when kmalloc() doesn't have >>>even >>> >a tiny sliver of RAM isn't going to work. It's easier to use >>> >libcfs_kvzalloc() everywhere, but it's probably the wrong thing. >>> >>> The original reason we have the vmalloc water mark wasn't so much the >>> issue of memory exhaustion but to handle the case of memory >>>fragmentation. >>> Some sites had after a extended period of time started to see failures >>>of >>> allocating even 32K using kmalloc. In our latest development branch >>>we moved >>> away from using a water mark to always try kmalloc first and if it >>>fails then we >>> try vmalloc. At ORNL we ran into severe performance issues when we >>>entered >>> vmalloc territory. It has been discussed before on what might replace >>>vmalloc >>> handling in the case of kmalloc fails but no solution has been worked >>>out. >> >>OK, but if a structure contains only 4 words, would it be better to just >>use kzalloc? Or does it not matter? It would only save trying vmalloc >>in >>a case that it is guaranteed to fail, but if a structure with 4 words >>can't be allocated, the system has other problems. Another argument is >>that kzalloc is a well known function that people and bug-finding tools >>understand, so it is better to use it whenever possible. >> >>Some of the other structures contain a lot more fields, as well as small >>arrays. They are probably acceptable for kzalloc too, but I wouldn't >>know >>the exact dividing line. > >The reason I bring this up is to discuss sorting this out. Once long ago >we had just LIBCFS_ALLOC. For some reason before my time OBD_ALLOC got > spawned off of that. Currently LIBCFS_ALLOC is used just by the >libcfs/LNet > layer. That is because there was (is?) interest from Cray and others to use LNet independently from Lustre (Zest and DVS, for example) so LNet should be self-contained and not depend on anything from Lustre. > Now OBD_ALLOC in our development branch has moved to a try kmalloc first >and >if it fails try vmalloc for any size memory allocation. LIBCFS_ALLOC >still > does the original approach. So we have two possible solutions >depending on if libcfs/LNet needs to ever do a vmalloc. > >One solution if libcfs/LNet never needs a vmalloc is remove LIBCFS_ALLOC >and replace it with kzalloc everywhere. We can then move libcfs_kzvalloc >to > the lustre layer and port the change we did in the development branch to > here of the try kmalloc then vmalloc approach. > >The other approach is if libcfs/LNet does in some case need to use vmalloc > we could then update LIBCFS_ALLOC to first try kmalloc then vmalloc. Once > this is implemented we can nuke the OBD_ALLOC system. I don't agree. I think there are a few places where vmalloc() makes sense to try (if the allocation may be large), but in most places LIBCFS_ALLOC() should only use kmalloc(). Unfortunately, there wasn't a separate LIBCFS_ALLOC_LARGE() like there was for OBD_ALLOC_LARGE() that made it clear which callsites are (potentially) large and which are small. The macro approach allowed the compile-time optimization of the small callsites, but that needs to be done by hand now. >Either way I like to see it consolidated down to one system. Given the proliferation of foo_kvmalloc() and foo_kvzalloc() helpers (ext4_, kvm_, dm_, apparmor, ceph_, __aa_), maybe it it is time to move these to common kernel code instead of introducing yet another new one? Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hv_netvsc: Add support to set MTU reservation from guest side
From: Dan Carpenter Date: Fri, 3 Jul 2015 14:28:47 +0300 > On Thu, Jul 02, 2015 at 01:17:35PM -0700, Haiyang Zhang wrote: >> When packet encapsulation is in use, the MTU needs to be reduced for >> headroom reservation. >> The existing code takes the updated MTU value only from the host side. >> But vSwitch extensions, such as Open vSwitch, require the flexibility >> to change the MTU to different values from within a guest during the >> lifecycle of a vNIC, when the encapsulation protocol is changed. The >> patch supports this kind of MTU changes. >> >> Signed-off-by: Haiyang Zhang >> Reviewed-by: K. Y. Srinivasan >> --- >> drivers/net/hyperv/netvsc_drv.c |3 +-- >> drivers/net/hyperv/rndis_filter.c |2 +- >> 2 files changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/hyperv/netvsc_drv.c >> b/drivers/net/hyperv/netvsc_drv.c >> index 358475e..68e7ece 100644 >> --- a/drivers/net/hyperv/netvsc_drv.c >> +++ b/drivers/net/hyperv/netvsc_drv.c >> @@ -743,8 +743,7 @@ static int netvsc_change_mtu(struct net_device *ndev, >> int mtu) >> if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2) >> limit = NETVSC_MTU - ETH_HLEN; >> >> -/* Hyper-V hosts don't support MTU < ETH_DATA_LEN (1500) */ >> -if (mtu < ETH_DATA_LEN || mtu > limit) >> +if (mtu < 68 || mtu > limit) > > How did you calculate 68? Avoid magic numbers like this, make it a > define. Agreed. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant
On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote: > SPC-2/3/4 specs state that "The standard INQUIRY data (see table ...) > shall contain at least 36 bytes". Hyper-V host doesn't always honor this > requirement, e.g. when there is no physical device present at a particular > LUN host sets Peripheral qualifier to 011b and Additional length to 0 > (thus making the reply 5-bytes long). Upper level SCSI stack complains > with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling > Additional length field in host's reply at the driver level. This looks like a big mess, and usage of phys_to_virt is not generally safe to start with. If HyperV really is that broken the warning seems correct, but if you really have to get rid of it we could add a blist flag to not issue the warning in the core code instead of hacking around it in the driver. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant
> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Friday, July 3, 2015 9:19 AM > To: Vitaly Kuznetsov > Cc: linux-s...@vger.kernel.org; Long Li; KY Srinivasan; Haiyang Zhang; James > E.J. Bottomley; de...@linuxdriverproject.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] scsi: storvsc: make INQUIRY response SPC-compliant > > On Wed, Jul 01, 2015 at 11:04:08AM +0200, Vitaly Kuznetsov wrote: > > SPC-2/3/4 specs state that "The standard INQUIRY data (see table ...) > > shall contain at least 36 bytes". Hyper-V host doesn't always honor this > > requirement, e.g. when there is no physical device present at a particular > > LUN host sets Peripheral qualifier to 011b and Additional length to 0 > > (thus making the reply 5-bytes long). Upper level SCSI stack complains > > with 'INQUIRY result too short (5), using 36'. Fix the issue by mangling > > Additional length field in host's reply at the driver level. > > This looks like a big mess, and usage of phys_to_virt is not generally > safe to start with. > > If HyperV really is that broken the warning seems correct, but if you > really have to get rid of it we could add a blist flag to not issue > the warning in the core code instead of hacking around it in the driver. Agreed. We have fixed this issue in win10 and I am trying to get the fix backported. Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] drivers: hv: hv_utils_transport: Fixing validation of correct pointer
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, July 3, 2015 1:10 AM
> To: Maninder Singh; KY Srinivasan
> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; panka...@samsung.com
> Subject: Re: [PATCH 1/1] drivers: hv: hv_utils_transport: Fixing validation of
> correct pointer
>
> Maninder Singh writes:
>
> > cn_msg should be validated instead of msg after memory allocation.
> >
>
> Thanks,
>
> This was already fixed by Dan:
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-
> May/070193.html
>
> my Reviewed-by:
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2015-
> June/070599.html
>
> but I don't see it in K. Y. recent submission to Greg. K. Y., could you
> please pick it up?
Yes; will do.
K. Y
>
> > Signed-off-by: Maninder Singh
> > Reviewed-by: Akhilesh Kumar
> > ---
> > drivers/hv/hv_utils_transport.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hv/hv_utils_transport.c
> b/drivers/hv/hv_utils_transport.c
> > index ea7ba5e..6a9d80a 100644
> > --- a/drivers/hv/hv_utils_transport.c
> > +++ b/drivers/hv/hv_utils_transport.c
> > @@ -186,7 +186,7 @@ int hvutil_transport_send(struct hvutil_transport
> *hvt, void *msg, int len)
> > return -EINVAL;
> > } else if (hvt->mode == HVUTIL_TRANSPORT_NETLINK) {
> > cn_msg = kzalloc(sizeof(*cn_msg) + len, GFP_ATOMIC);
> > - if (!msg)
> > + if (!cn_msg)
> > return -ENOMEM;
> > cn_msg->id.idx = hvt->cn_id.idx;
> > cn_msg->id.val = hvt->cn_id.val;
>
> --
> Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] scsi: storvsc: use shost_for_each_device() instead of open coding
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Wednesday, July 1, 2015 2:31 AM
> To: linux-s...@vger.kernel.org
> Cc: Long Li; KY Srinivasan; Haiyang Zhang; James E.J. Bottomley;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] scsi: storvsc: use shost_for_each_device() instead of open
> coding
>
> Comment in struct Scsi_Host says that drivers are not supposed to access
> __devices directly. storvsc_host_scan() doesn't happen in irq context
> so we can just use shost_for_each_device().
>
> Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
> ---
> drivers/scsi/storvsc_drv.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 3c6584f..9ea912b 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -426,7 +426,6 @@ static void storvsc_host_scan(struct work_struct
> *work)
> struct storvsc_scan_work *wrk;
> struct Scsi_Host *host;
> struct scsi_device *sdev;
> - unsigned long flags;
>
> wrk = container_of(work, struct storvsc_scan_work, work);
> host = wrk->host;
> @@ -443,14 +442,8 @@ static void storvsc_host_scan(struct work_struct
> *work)
>* may have been removed this way.
>*/
> mutex_lock(&host->scan_mutex);
> - spin_lock_irqsave(host->host_lock, flags);
> - list_for_each_entry(sdev, &host->__devices, siblings) {
> - spin_unlock_irqrestore(host->host_lock, flags);
> + shost_for_each_device(sdev, host)
> scsi_test_unit_ready(sdev, 1, 1, NULL);
> - spin_lock_irqsave(host->host_lock, flags);
> - continue;
> - }
> - spin_unlock_irqrestore(host->host_lock, flags);
> mutex_unlock(&host->scan_mutex);
> /*
>* Now scan the host to discover LUNs that may have been added.
> --
> 2.4.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] defines modified to match the 80-char rule
On Fri, 2015-07-03 at 12:58 +0200, Krzysztof Hałasa wrote: > Joe Perches writes: > > > -#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ## > > __VA_ARGS__) > > -#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ## > > __VA_ARGS__) > > -#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING, > > format, ## __VA_ARGS__) > > -#define LCONSOLE_ERROR_MSG(errnum, format, ...) CDEBUG_LIMIT(D_CONSOLE | > > D_ERROR, \ > > - "%x-%x: " format, errnum, LERRCHKSUM(errnum), ## > > __VA_ARGS__) > > -#define LCONSOLE_ERROR(format, ...) LCONSOLE_ERROR_MSG(0x00, format, ## > > __VA_ARGS__) > > +#define LCONSOLE(mask, fmt, ...) \ > > + CDEBUG(D_CONSOLE | (mask), fmt, ##__VA_ARGS__) > > +#define LCONSOLE_INFO(fmt, ...) > > \ > > + CDEBUG_LIMIT(D_CONSOLE, fmt, ##__VA_ARGS__) > > +#define LCONSOLE_WARN(fmt, ...) > > \ > > + CDEBUG_LIMIT(D_CONSOLE | D_WARNING, fmt, ##__VA_ARGS__) > > +#define LCONSOLE_ERROR_MSG(errnum, fmt, ...) > > \ > > + CDEBUG_LIMIT(D_CONSOLE | D_ERROR, "%x-%x: " fmt,\ > > +errnum, LERRCHKSUM(errnum), ##__VA_ARGS__) > > I don't find it better, actually I think it's much harder to read. > > Maybe that's just me. > > Call me extremist, but I think I could even like the following :-) > > #define CWARN(format, ...) CDEBUG_LIMIT(D_WARNING, format, ## __VA_ARGS__) > #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR,format, ## __VA_ARGS__) > #define CNETERR(format, ...) CDEBUG_LIMIT(D_NETERROR, format, ## __VA_ARGS__) > #define CEMERG(format, ...) CDEBUG_LIMIT(D_EMERG,format, ## __VA_ARGS__) Nah, you're not an extremist, you're just preferring narrowly localized readability over global consistency. That's fine and all, until you come up to LCONSOLE_ERROR_MSG type use which blows the nice old formatting up. So what I suggested is just a simple consistency thing. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] scsi: storvsc: use shost_for_each_device() instead of open coding
> -Original Message-
> From: KY Srinivasan
> Sent: Friday, July 03, 2015 11:35 AM
> To: Vitaly Kuznetsov; linux-s...@vger.kernel.org
> Cc: Long Li; Haiyang Zhang; James E.J. Bottomley;
> de...@linuxdriverproject.org;
> linux-ker...@vger.kernel.org
> Subject: RE: [PATCH] scsi: storvsc: use shost_for_each_device() instead of
> open
> coding
>
>
>
> > -Original Message-
> > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> > Sent: Wednesday, July 1, 2015 2:31 AM
> > To: linux-s...@vger.kernel.org
> > Cc: Long Li; KY Srinivasan; Haiyang Zhang; James E.J. Bottomley;
> > de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
> > Subject: [PATCH] scsi: storvsc: use shost_for_each_device() instead of
> > open coding
> >
> > Comment in struct Scsi_Host says that drivers are not supposed to
> > access __devices directly. storvsc_host_scan() doesn't happen in irq
> > context so we can just use shost_for_each_device().
> >
> > Signed-off-by: Vitaly Kuznetsov
>
> Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
> > ---
> > drivers/scsi/storvsc_drv.c | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> > index 3c6584f..9ea912b 100644
> > --- a/drivers/scsi/storvsc_drv.c
> > +++ b/drivers/scsi/storvsc_drv.c
> > @@ -426,7 +426,6 @@ static void storvsc_host_scan(struct work_struct
> > *work)
> > struct storvsc_scan_work *wrk;
> > struct Scsi_Host *host;
> > struct scsi_device *sdev;
> > - unsigned long flags;
> >
> > wrk = container_of(work, struct storvsc_scan_work, work);
> > host = wrk->host;
> > @@ -443,14 +442,8 @@ static void storvsc_host_scan(struct work_struct
> > *work)
> > * may have been removed this way.
> > */
> > mutex_lock(&host->scan_mutex);
> > - spin_lock_irqsave(host->host_lock, flags);
> > - list_for_each_entry(sdev, &host->__devices, siblings) {
> > - spin_unlock_irqrestore(host->host_lock, flags);
> > + shost_for_each_device(sdev, host)
> > scsi_test_unit_ready(sdev, 1, 1, NULL);
> > - spin_lock_irqsave(host->host_lock, flags);
> > - continue;
> > - }
> > - spin_unlock_irqrestore(host->host_lock, flags);
> > mutex_unlock(&host->scan_mutex);
> > /*
> > * Now scan the host to discover LUNs that may have been added.
> > --
> > 2.4.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/5] Drivers: hv: Some miscellaneous fixes
Some miscellaneous fixes. Dan Carpenter (1): hv: util: checking the wrong variable Denis V. Lunev (1): mshyperv: fix recognition of Hyper-V guest crash MSR's K. Y. Srinivasan (1): Drivers: hv: vmbus: Consider ND NIC in binding channels to CPUs Nik Nyby (1): Drivers: hv: vmbus: fix typo in hv_port_info struct Vitaly Kuznetsov (1): Drivers: hv: vmbus: don't send CHANNELMSG_UNLOAD on pre-Win2012R2 hosts arch/x86/include/asm/mshyperv.h |1 + arch/x86/kernel/cpu/mshyperv.c |1 + drivers/hv/channel_mgmt.c |5 + drivers/hv/hv_utils_transport.c |2 +- drivers/hv/hyperv_vmbus.h |2 +- drivers/hv/vmbus_drv.c |4 ++-- 6 files changed, 11 insertions(+), 4 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/5] Drivers: hv: vmbus: Consider ND NIC in binding channels to CPUs
We cycle through all the "high performance" channels to distribute
load across the available CPUs. Process the NetworkDirect as a
high performance device.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 00ba3f3..30613df 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -347,6 +347,7 @@ enum {
IDE = 0,
SCSI,
NIC,
+ ND_NIC,
MAX_PERF_CHN,
};
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/5] Drivers: hv: vmbus: don't send CHANNELMSG_UNLOAD on pre-Win2012R2 hosts
From: Vitaly Kuznetsov
Pre-Win2012R2 hosts don't properly handle CHANNELMSG_UNLOAD and
wait_for_completion() hangs. Avoid sending such request on old hosts.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel_mgmt.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 4506a66..00ba3f3 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -469,6 +469,10 @@ void vmbus_initiate_unload(void)
{
struct vmbus_channel_message_header hdr;
+ /* Pre-Win2012R2 hosts don't support reconnect */
+ if (vmbus_proto_version < VERSION_WIN8_1)
+ return;
+
init_completion(&vmbus_connection.unload_event);
memset(&hdr, 0, sizeof(struct vmbus_channel_message_header));
hdr.msgtype = CHANNELMSG_UNLOAD;
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/5] Drivers: hv: vmbus: fix typo in hv_port_info struct
From: Nik Nyby
This fixes a typo: base_flag_bumber to base_flag_number
Signed-off-by: Nik Nyby
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hyperv_vmbus.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index cddc0c9..6383707 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -141,7 +141,7 @@ struct hv_port_info {
struct {
u32 target_sint;
u32 target_vp;
- u16 base_flag_bumber;
+ u16 base_flag_number;
u16 flag_count;
u32 rsvdz;
} event_port_info;
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/5] mshyperv: fix recognition of Hyper-V guest crash MSR's
From: Denis V. Lunev
Hypervisor Top Level Functional Specification v3.1/4.0 notes that cpuid
(0x4003) EDX's 10th bit should be used to check that Hyper-V guest
crash MSR's functionality available.
This patch should fix this recognition. Currently the code checks EAX
register instead of EDX.
Signed-off-by: Andrey Smetanin
Signed-off-by: Denis V. Lunev
Signed-off-by: K. Y. Srinivasan
---
arch/x86/include/asm/mshyperv.h |1 +
arch/x86/kernel/cpu/mshyperv.c |1 +
drivers/hv/vmbus_drv.c |4 ++--
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index d02f9c9..aaf59b7 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -7,6 +7,7 @@
struct ms_hyperv_info {
u32 features;
+ u32 misc_features;
u32 hints;
};
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 1a6e742..9b5d7b5 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -160,6 +160,7 @@ static void __init ms_hyperv_init_platform(void)
* Extract the features and hints
*/
ms_hyperv.features = cpuid_eax(HYPERV_CPUID_FEATURES);
+ ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
ms_hyperv.hints= cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 83759c1..8c3eaee 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -868,7 +868,7 @@ static int vmbus_bus_init(int irq)
/*
* Only register if the crash MSRs are available
*/
- if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
register_die_notifier(&hyperv_die_block);
atomic_notifier_chain_register(&panic_notifier_list,
&hyperv_panic_block);
@@ -1313,7 +1313,7 @@ static void __exit vmbus_exit(void)
hv_remove_vmbus_irq();
tasklet_kill(&msg_dpc);
vmbus_free_channels();
- if (ms_hyperv.features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
+ if (ms_hyperv.misc_features & HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE) {
unregister_die_notifier(&hyperv_die_block);
atomic_notifier_chain_unregister(&panic_notifier_list,
&hyperv_panic_block);
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/5] hv: util: checking the wrong variable
From: Dan Carpenter
We don't catch this allocation failure because there is a typo and we
check the wrong variable.
Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport
abstraction')
Signed-off-by: Dan Carpenter
Reviewed-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_utils_transport.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index ea7ba5e..6a9d80a 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -186,7 +186,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt,
void *msg, int len)
return -EINVAL;
} else if (hvt->mode == HVUTIL_TRANSPORT_NETLINK) {
cn_msg = kzalloc(sizeof(*cn_msg) + len, GFP_ATOMIC);
- if (!msg)
+ if (!cn_msg)
return -ENOMEM;
cn_msg->id.idx = hvt->cn_id.idx;
cn_msg->id.val = hvt->cn_id.val;
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] x86: Hyper-V: Mark the Hyper-V clocksource as being high resolution
From: Vivek yadav
By design, alternative clock sources listed are based on the resolution of
current clock source. Once you set a high resolution clock,
only high resolution sources are returned.
Mark Hyper-V clock source as a high resolution clock source.
Signed-off-by: Vivek yadav
Signed-off-by: K. Y. Srinivasan
---
arch/x86/kernel/cpu/mshyperv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 9b5d7b5..0e507a0 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -151,7 +151,8 @@ static struct clocksource hyperv_cs = {
.rating = 400, /* use this when running on Hyperv*/
.read = read_hv_clock,
.mask = CLOCKSOURCE_MASK(64),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS |
+ CLOCK_SOURCE_VALID_FOR_HRES,
};
static void __init ms_hyperv_init_platform(void)
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
