Re: [PATCH V2 2/5] X86: Hyper-V: Enable IPI enlightenments

[kbuild test robot]

Hi Srinivasan,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.17-rc3]
[also build test ERROR on next-20180504]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-linuxonhyperv-com/X86-Hyper-V-APIC-enlightenments/20180505-045627
config: x86_64-randconfig-a0-05050447 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_read':
   arch/x86/hyperv/hv_apic.c:69:10: error: implicit declaration of function 
'native_apic_mem_read'; did you mean 'hv_apic_icr_read'? 
[-Werror=implicit-function-declaration]
  return native_apic_mem_read(reg);
 ^~~~
 hv_apic_icr_read
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_write':
   arch/x86/hyperv/hv_apic.c:83:3: error: implicit declaration of function 
'native_apic_mem_write'; did you mean 'hv_apic_icr_write'? 
[-Werror=implicit-function-declaration]
  native_apic_mem_write(reg, val);
  ^
  hv_apic_icr_write
   arch/x86/hyperv/hv_apic.c: In function 'hv_send_ipi':
>> arch/x86/hyperv/hv_apic.c:153:12: error: invalid use of undefined type 
>> 'struct apic'
  orig_apic.send_IPI(cpu, vector);
   ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_send_ipi_mask':
   arch/x86/hyperv/hv_apic.c:159:12: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_mask(mask, vector);
   ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_send_ipi_mask_allbutself':
   arch/x86/hyperv/hv_apic.c:172:12: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_mask_allbutself(mask, vector);
   ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_send_ipi_all':
   arch/x86/hyperv/hv_apic.c:183:12: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_all(vector);
   ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_send_ipi_self':
   arch/x86/hyperv/hv_apic.c:189:12: error: invalid use of undefined type 
'struct apic'
  orig_apic.send_IPI_self(vector);
   ^
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_init':
>> arch/x86/hyperv/hv_apic.c:199:16: error: 'apic' undeclared (first use in 
>> this function)
  orig_apic = *apic;
   ^~~~
   arch/x86/hyperv/hv_apic.c:199:16: note: each undeclared identifier is 
reported only once for each function it appears in
>> arch/x86/hyperv/hv_apic.c:199:13: error: 'orig_apic' has an incomplete type 
>> 'struct apic'
  orig_apic = *apic;
^
   arch/x86/hyperv/hv_apic.c:211:3: error: implicit declaration of function 
'apic_set_eoi_write'; did you mean 'hv_apic_eoi_write'? 
[-Werror=implicit-function-declaration]
  apic_set_eoi_write(hv_apic_eoi_write);
  ^~
  hv_apic_eoi_write
   arch/x86/hyperv/hv_apic.c: At top level:
>> arch/x86/hyperv/hv_apic.c:35:20: error: storage size of 'orig_apic' isn't 
>> known
static struct apic orig_apic;
   ^
   cc1: some warnings being treated as errors

vim +153 arch/x86/hyperv/hv_apic.c

34  
  > 35  static struct apic orig_apic;
36  
37  static u64 hv_apic_icr_read(void)
38  {
39  u64 reg_val;
40  
41  rdmsrl(HV_X64_MSR_ICR, reg_val);
42  return reg_val;
43  }
44  
45  static void hv_apic_icr_write(u32 low, u32 id)
46  {
47  u64 reg_val;
48  
49  reg_val = SET_APIC_DEST_FIELD(id);
50  reg_val = reg_val << 32;
51  reg_val |= low;
52  
53  wrmsrl(HV_X64_MSR_ICR, reg_val);
54  }
55  
56  static u32 hv_apic_read(u32 reg)
57  {
58  u32 reg_val, hi;
59  
60  switch (reg) {
61  case APIC_EOI:
62  rdmsr(HV_X64_MSR_EOI, reg_val, hi);
63  return reg_val;
64  case APIC_TASKPRI:
65  rdmsr(HV_X64_MSR_TPR, reg_val, hi);
66  return reg_val;
67  
68  default:
69  return native_apic_mem_read(reg);
70  }
71  }
72  
73  static void hv_apic_write(u32 reg, u32 val)
74  {
75  switch (reg) {
76  case APIC_EOI:
77  wrmsr(HV_X64_MSR_EOI, val, 0);
78  break;
79  case APIC_TASKPRI:
80  wrmsr(HV_X64_MSR_TPR, val, 0);
81  break;
82  default:
  > 83  native_apic_mem_write(reg, val);
84  }
85  }
86  
87  static void hv_apic_eoi_write(u32 re

Re: [PATCH V2 1/5] X86: Hyper-V: Enlighten APIC access

[kbuild test robot]

Hi Srinivasan,

I love your patch! Yet something to improve:

[auto build test ERROR on v4.17-rc3]
[also build test ERROR on next-20180504]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-linuxonhyperv-com/X86-Hyper-V-APIC-enlightenments/20180505-045627
config: x86_64-randconfig-a0-05050447 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_read':
>> arch/x86/hyperv/hv_apic.c:66:10: error: implicit declaration of function 
>> 'native_apic_mem_read'; did you mean 'hv_apic_icr_read'? 
>> [-Werror=implicit-function-declaration]
  return native_apic_mem_read(reg);
 ^~~~
 hv_apic_icr_read
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_write':
>> arch/x86/hyperv/hv_apic.c:80:3: error: implicit declaration of function 
>> 'native_apic_mem_write'; did you mean 'hv_apic_icr_write'? 
>> [-Werror=implicit-function-declaration]
  native_apic_mem_write(reg, val);
  ^
  hv_apic_icr_write
   arch/x86/hyperv/hv_apic.c: In function 'hv_apic_init':
>> arch/x86/hyperv/hv_apic.c:93:3: error: implicit declaration of function 
>> 'apic_set_eoi_write'; did you mean 'hv_apic_eoi_write'? 
>> [-Werror=implicit-function-declaration]
  apic_set_eoi_write(hv_apic_eoi_write);
  ^~
  hv_apic_eoi_write
   arch/x86/hyperv/hv_apic.c:94:3: error: 'apic' undeclared (first use in this 
function); did you mean 'pid'?
  apic->read  = hv_apic_read;
  ^~~~
  pid
   arch/x86/hyperv/hv_apic.c:94:3: note: each undeclared identifier is reported 
only once for each function it appears in
   cc1: some warnings being treated as errors

vim +66 arch/x86/hyperv/hv_apic.c

52  
53  static u32 hv_apic_read(u32 reg)
54  {
55  u32 reg_val, hi;
56  
57  switch (reg) {
58  case APIC_EOI:
59  rdmsr(HV_X64_MSR_EOI, reg_val, hi);
60  return reg_val;
61  case APIC_TASKPRI:
62  rdmsr(HV_X64_MSR_TPR, reg_val, hi);
63  return reg_val;
64  
65  default:
  > 66  return native_apic_mem_read(reg);
67  }
68  }
69  
70  static void hv_apic_write(u32 reg, u32 val)
71  {
72  switch (reg) {
73  case APIC_EOI:
74  wrmsr(HV_X64_MSR_EOI, val, 0);
75  break;
76  case APIC_TASKPRI:
77  wrmsr(HV_X64_MSR_TPR, val, 0);
78  break;
79  default:
  > 80  native_apic_mem_write(reg, val);
81  }
82  }
83  
84  static void hv_apic_eoi_write(u32 reg, u32 val)
85  {
86  wrmsr(HV_X64_MSR_EOI, val, 0);
87  }
88  
89  void __init hv_apic_init(void)
90  {
91  if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
92  pr_info("Hyper-V: Using MSR based APIC access\n");
  > 93  apic_set_eoi_write(hv_apic_eoi_write);
94  apic->read  = hv_apic_read;
95  apic->write = hv_apic_write;
96  apic->icr_write = hv_apic_icr_write;
97  apic->icr_read  = hv_apic_icr_read;
98  }
99  }
   100  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] ANDROID: binder: remove 32-bit binder interface.

[Martijn Coenen]

New devices launching with Android P need to use the 64-bit
binder interface, even on 32-bit SoCs [0].

This change removes the Kconfig option to select the 32-bit
binder interface. We don't think this will affect existing
userspace for the following reasons:
1) The latest Android common tree is 4.14, so we don't
   believe any Android devices are on kernels >4.14.
2) Android devices launch on an LTS release and stick with
   it, so we wouldn't expect devices running on <= 4.14 now
   to upgrade to 4.17 or later. But even if they did, they'd
   rebuild the world (kernel + userspace) anyway.
3) Other userspaces like 'anbox' are already using the
   64-bit interface.

Note that this change doesn't remove the 32-bit UAPI
itself; the reason for that is that Android userspace
always uses the latest UAPI headers from upstream, and
userspace retains 32-bit support for devices that are
upgrading. This will be removed as well in 2-3 years,
at which point we can remove the code from the UAPI
as well.

[0]: https://android-review.googlesource.com/c/platform/build/+/595193

Signed-off-by: Martijn Coenen 
---
 drivers/android/Kconfig  | 13 -
 drivers/android/binder.c |  4 
 2 files changed, 17 deletions(-)

diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
index 7dce3795b887..432e9ad77070 100644
--- a/drivers/android/Kconfig
+++ b/drivers/android/Kconfig
@@ -32,19 +32,6 @@ config ANDROID_BINDER_DEVICES
  created. Each binder device has its own context manager, and is
  therefore logically separated from the other devices.
 
-config ANDROID_BINDER_IPC_32BIT
-   bool "Use old (Android 4.4 and earlier) 32-bit binder API"
-   depends on !64BIT && ANDROID_BINDER_IPC
-   default y
-   ---help---
- The Binder API has been changed to support both 32 and 64bit
- applications in a mixed environment.
-
- Enable this to support an old 32-bit Android user-space (v4.4 and
- earlier).
-
- Note that enabling this will break newer Android user-space.
-
 config ANDROID_BINDER_IPC_SELFTEST
bool "Android Binder IPC Driver Selftest"
depends on ANDROID_BINDER_IPC
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index e578eee31589..2ee9fb02dfb8 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -72,10 +72,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_ANDROID_BINDER_IPC_32BIT
-#define BINDER_IPC_32BIT 1
-#endif
-
 #include 
 #include "binder_alloc.h"
 #include "binder_trace.h"
-- 
2.17.0.441.gb46fe60e1d-goog

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

Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need

[Mauro Carvalho Chehab]

Em Sun, 22 Apr 2018 13:06:12 +0200
Hans Verkuil  escreveu:

> On 04/02/2018 04:26 PM, Robert Jarzmik wrote:
> > From: Robert Jarzmik 
> > 
> > As the pxa architecture switched towards the dmaengine slave map, the
> > old compatibility mechanism to acquire the dma requestor line number and
> > priority are not needed anymore.
> > 
> > This patch simplifies the dma resource acquisition, using the more
> > generic function dma_request_slave_channel().
> > 
> > Signed-off-by: Robert Jarzmik   
> 
> Acked-by: Hans Verkuil 

I'm assuming that you'll be applying it together with other PXA patches.
So:

Acked-by: Mauro Carvalho Chehab 

Regards,
Mauro
> 
> Regards,
> 
>   Hans
> 
> > ---
> >  drivers/media/platform/pxa_camera.c | 22 +++---
> >  1 file changed, 3 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/media/platform/pxa_camera.c 
> > b/drivers/media/platform/pxa_camera.c
> > index c71a00736541..4c82d1880753 100644
> > --- a/drivers/media/platform/pxa_camera.c
> > +++ b/drivers/media/platform/pxa_camera.c
> > @@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device 
> > *pdev)
> > .src_maxburst = 8,
> > .direction = DMA_DEV_TO_MEM,
> > };
> > -   dma_cap_mask_t mask;
> > -   struct pxad_param params;
> > char clk_name[V4L2_CLK_NAME_SIZE];
> > int irq;
> > int err = 0, i;
> > @@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device 
> > *pdev)
> > pcdev->base = base;
> >  
> > /* request dma */
> > -   dma_cap_zero(mask);
> > -   dma_cap_set(DMA_SLAVE, mask);
> > -   dma_cap_set(DMA_PRIVATE, mask);
> > -
> > -   params.prio = 0;
> > -   params.drcmr = 68;
> > -   pcdev->dma_chans[0] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_Y");
> > +   pcdev->dma_chans[0] = dma_request_slave_channel(>dev, "CI_Y");
> > if (!pcdev->dma_chans[0]) {
> > dev_err(>dev, "Can't request DMA for Y\n");
> > return -ENODEV;
> > }
> >  
> > -   params.drcmr = 69;
> > -   pcdev->dma_chans[1] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_U");
> > +   pcdev->dma_chans[1] = dma_request_slave_channel(>dev, "CI_U");
> > if (!pcdev->dma_chans[1]) {
> > dev_err(>dev, "Can't request DMA for Y\n");
> > err = -ENODEV;
> > goto exit_free_dma_y;
> > }
> >  
> > -   params.drcmr = 70;
> > -   pcdev->dma_chans[2] =
> > -   dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > -, >dev, "CI_V");
> > +   pcdev->dma_chans[2] = dma_request_slave_channel(>dev, "CI_V");
> > if (!pcdev->dma_chans[2]) {
> > dev_err(>dev, "Can't request DMA for V\n");
> > err = -ENODEV;
> >   
> 



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

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

[Martijn Coenen]

On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez  wrote:
> Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
>
> It would be good for us to hear from Android folks if their current use of
> request_firmware_into_buf() is designed in practice to *never* use the direct
> filesystem firmware loading interface, and always rely instead on the
> fallback mechanism.

It's hard to answer this question for Android in general. As far as I
can tell the reasons we use CONFIG_FW_LOADER_USER_HELPER(_FALLBACK)
are:
1) We have multiple different paths on our devices where firmware can
be located, and the direct loader only supports one custom path
2) Most of those paths are not mounted by the time the corresponding
drivers are loaded, because pretty much all Android kernels today are
built without module support, and therefore drivers are loaded well
before the firmware partition is mounted
3) I think we use _FALLBACK because doing this with uevents is just
the easiest thing to do; our init code has a firmware helper that
deals with this and searches the paths that we care about

2) will change at some point, because Android is moving towards a
model where device-specific peripheral drivers will be loaded as
modules, and since those modules would likely come from the same
partition as the firmware, it's possible that the direct load would
succeed (depending on whether the custom path is configured there or
not). But I don't think we can rely on the direct loader even in those
cases, unless we could configure it with multiple custom paths.

I have no reason to believe request_firmware_into_buf() is special in
this regard; drivers that depend on it may have their corresponding
firmware in different locations, so just depending on the direct
loader would not be good enough.

>
> Is ptr below
>
> ret = request_firmware_into_buf(_fw, fw_name, dev,
> ptr, phdr->p_filesz);
>
> Also part of the DMA buffer allocated earlier via:
>
> ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
>
> Android folks?

I think the Qualcomm folks owning this (Andy, David, Bjorn, already
cc'd here) are better suited to answer that question.

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

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

[Martijn Coenen]

On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez  wrote:
> Android folks, poke below. otherwise we'll have no option but to seriously
> consider Mimi's patch to prevent these calls when IMA appraisal is enforced:

Sorry, figuring out who's the right person to answer this, will get
back to you ASAP.

Martijn

>
> http://lkml.kernel.org/r/1525182503-13849-7-git-send-email-zo...@linux.vnet.ibm.com
>
> Please read below
>
> On Wed, Apr 25, 2018 at 05:55:57PM +, Luis R. Rodriguez wrote:
>> On Wed, Apr 25, 2018 at 01:00:09AM -0400, Mimi Zohar wrote:
>> > On Tue, 2018-04-24 at 23:42 +, Luis R. Rodriguez wrote:
>> > > On Tue, Apr 24, 2018 at 12:07:01PM -0400, Mimi Zohar wrote:
>> > > > On Tue, 2018-04-24 at 17:09 +0200, Hans de Goede wrote:
>> > > If its of any help --
>> > >
>> > > drivers/soc/qcom/mdt_loader.c is the only driver currently using
>> > > request_firmware_into_buf() however I'll note qcom_mdt_load() is used in 
>> > > many
>> > > other drivers so they are wrappers around request_firmware_into_buf():
>> > >
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:   * adreno_request_fw() handles 
>> > > this, but qcom_mdt_load() does
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, fwname, GPU_PAS_ID,
>> > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c:  ret = qcom_mdt_load(dev, 
>> > > fw, newname, GPU_PAS_ID,
>> > > drivers/media/platform/qcom/venus/firmware.c:   ret = qcom_mdt_load(dev, 
>> > > mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
>> > > drivers/remoteproc/qcom_adsp_pil.c: return qcom_mdt_load(adsp->dev, 
>> > > fw, rproc->firmware, adsp->pas_id,
>> > > drivers/remoteproc/qcom_wcnss.c:return qcom_mdt_load(wcnss->dev, 
>> > > fw, rproc->firmware, WCNSS_PAS_ID,
>> > >
>> > > > > As such the current IMA code (from v4.17-rc2) actually does
>> > > > > not handle READING_FIRMWARE_PREALLOC_BUFFER at all,
>> > > >
>> > > > Right, it doesn't yet address READING_FIRMWARE_PREALLOC_BUFFER, but
>> > > > should.
>> > > >
>> > > > Depending on whether the device requesting the firmware has access to
>> > > > the DMA memory, before the signature verification,
>> > >
>> > > It would seem from the original patch review about 
>> > > READING_FIRMWARE_PREALLOC_BUFFER
>> > > that this is not a DMA buffer.
>
> To be very clear I believe Stephen implied this was not DMA buffer. Mimi
> asked for READING_FIRMWARE_DMA if it was:
>
> https://patchwork.kernel.org/patch/9074611/
>
>> > The call sequence:
>> > qcom_mdt_load() -> qcom_scm_pas_init_image() -> dma_alloc_coherent()
>> >
>> > If dma_alloc_coherent() isn't allocating a DMA buffer, then the
>> > function name is misleading/confusing.
>>
>> Hah, by *definition* the device *and* processor has immediate access
>> to data written *immediately* when dma_alloc_coherent() is used. From
>> Documentation/DMA-API.txt:
>>
>> ---
>> Part Ia - Using large DMA-coherent buffers
>> --
>>
>> ::
>>
>> void *
>> dma_alloc_coherent(struct device *dev, size_t size,
>>dma_addr_t *dma_handle, gfp_t flag)
>>
>> Consistent memory is memory for which a write by either the device or
>> the processor can immediately be read by the processor or device
>> without having to worry about caching effects.  (You may however need
>> to make sure to flush the processor's write buffers before telling
>> devices to read that memory.)
>> 
>>
>> Is ptr below
>>
>>   ret = request_firmware_into_buf(_fw, fw_name, dev,
>>   ptr, phdr->p_filesz);
>>
>> Also part of the DMA buffer allocated earlier via:
>>
>> ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
>>
>> Android folks?
>
> Android folks?
>
>> > > The device driver should have access to the buffer pointer with write 
>> > > given
>> > > that with request_firmware_into_buf() the driver is giving full write 
>> > > access to
>> > > the memory pointer so that the firmware API can stuff the firmware it 
>> > > finds
>> > > there.
>> > >
>> > > Firmware signature verification would be up to the device hardware to do 
>> > > upon
>> > > load *after* request_firmware_into_buf().
>> >
>> > We're discussing the kernel's signature verification, not the device
>> > hardware's signature verification.  Can the device driver access the
>> > buffer, before IMA-appraisal has verified the firmware's signature?
>>
>> It will depend on the above question.
>
>   Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

[Wenwen Wang]

On Fri, May 4, 2018 at 5:08 AM, Dilger, Andreas
 wrote:
> On May 3, 2018, at 22:19, Wenwen Wang  wrote:
>>
>> On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter  
>> wrote:
>>> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote:
 However, given that the user data resides in the user space, a malicious
 user-space process can race to change the data between the two copies. By
 doing so, the attacker can provide a data with an inconsistent version,
 e.g., v1 version + v3 data. This can lead to logical errors in the
 following execution in ll_dir_setstripe(), which performs different actions
 according to the version specified by the field lmm_magic.
>>>
>>> This part is misleading.  The fix is to improve readability and make
>>> static checkers happy.  You're over dramatizing it to make people think
>>> it has a security impact when it doesn't.
>>>
>>> If the user wants to specify v1 data they can just say that on the first
>>> read.  They don't need to do funny tricks and race between the two
>>> reads.  It's allowed.
>>>
>>> In other words this allows the user to do something in a very
>>> complicated way which they are already allowed to do in a very simple
>>> straight forward way.
>>>
>>> regards,
>>> dan carpenter
>>
>> Thanks for your comment, Dan! How about this:
>>
>> However, given that the user data resides in the user space, a
>> malicious user-space process can race to change the data between the
>> two copies. By doing so, the attacker can provide a data with an
>> inconsistent version, e.g., v1 version + v3 data. The current kernel
>> can handle such inconsistent data. But, it may pose a potential
>> security risk for future implementations. Also, to improve code
>> readability and make static analysis tools happy, which will warn
>> about read-verify-re-read type bugs, this issue should be fixed.
>
> There is nothing preventing the user from using struct lov_mds_md_v3 but
> filling in lmm_magic = LOV_MAGIC_V1 from the beginning, no need for a race.
>

But, if the user uses such a struct, the second fetch won't be
executed. This is a little bit different from using LOV_MAGIC_V3
firstly and then changing it to LOV_MAGIC_V1.

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

Re: [PATCH] media: staging: atomisp: fix a potential missing-check bug

[Andy Shevchenko]

On Fri, 2018-05-04 at 02:29 -0500, Wenwen Wang wrote:
> At the end of atomisp_subdev_set_selection(), the function
> atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect.
> Since
> this function may return a NULL pointer, it is firstly invoked to
> check
> the returned pointer. If the returned pointer is not NULL, then the
> function is invoked again to obtain the pointer and the memory content
> at the location of the returned pointer is copied to the memory
> location of
> r. In most cases, the pointers returned by the two invocations are
> same.
> However, given that the pointer returned by the function
> atomisp_subdev_get_rect() is not a constant, it is possible that the
> two
> invocations return two different pointers. For example, another thread
> may
> race to modify the related pointers during the two invocations. In
> that
> case, even if the first returned pointer is not null, the second
> returned
> pointer might be null, which will cause issues such as null pointer
> dereference.
> 
> This patch saves the pointer returned by the first invocation and
> removes
> the second invocation. If the returned pointer is not NULL, the memory
> content is copied according to the original code.
> 

The driver will be gone soon, don't bother with it anymore.
Thanks!

> Signed-off-by: Wenwen Wang 
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 -
> -
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git
> a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> index 49a9973..d5fa513 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
> @@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct
> v4l2_subdev *sd,
>   unsigned int i;
>   unsigned int padding_w = pad_w;
>   unsigned int padding_h = pad_h;
> + struct v4l2_rect *p;
>  
>   stream_id = atomisp_source_pad_to_stream_id(isp_sd,
> vdev_pad);
>  
> @@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct
> v4l2_subdev *sd,
>   ffmt[pad]->height = comp[pad]->height;
>   }
>  
> - if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target))
> + p = atomisp_subdev_get_rect(sd, cfg, which, pad, target);
> + if (!p)
>   return -EINVAL;
> - *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target);
> + *r = *p;
>  
>   dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n",
>   r->left, r->top, r->width, r->height);

-- 
Andy Shevchenko 
Intel Finland Oy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv

[Dilger, Andreas]

On May 3, 2018, at 22:19, Wenwen Wang  wrote:
> 
> On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter  
> wrote:
>> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote:
>>> However, given that the user data resides in the user space, a malicious
>>> user-space process can race to change the data between the two copies. By
>>> doing so, the attacker can provide a data with an inconsistent version,
>>> e.g., v1 version + v3 data. This can lead to logical errors in the
>>> following execution in ll_dir_setstripe(), which performs different actions
>>> according to the version specified by the field lmm_magic.
>> 
>> This part is misleading.  The fix is to improve readability and make
>> static checkers happy.  You're over dramatizing it to make people think
>> it has a security impact when it doesn't.
>> 
>> If the user wants to specify v1 data they can just say that on the first
>> read.  They don't need to do funny tricks and race between the two
>> reads.  It's allowed.
>> 
>> In other words this allows the user to do something in a very
>> complicated way which they are already allowed to do in a very simple
>> straight forward way.
>> 
>> regards,
>> dan carpenter
> 
> Thanks for your comment, Dan! How about this:
> 
> However, given that the user data resides in the user space, a
> malicious user-space process can race to change the data between the
> two copies. By doing so, the attacker can provide a data with an
> inconsistent version, e.g., v1 version + v3 data. The current kernel
> can handle such inconsistent data. But, it may pose a potential
> security risk for future implementations. Also, to improve code
> readability and make static analysis tools happy, which will warn
> about read-verify-re-read type bugs, this issue should be fixed.

There is nothing preventing the user from using struct lov_mds_md_v3 but
filling in lmm_magic = LOV_MAGIC_V1 from the beginning, no need for a race.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







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

[PATCH] staging: wlan-ng: fix SPDX comment style in headers

[Tim Collier]

Several of the wlan-ng header files had C++-style SPDX comments. Fixed
checkpatch warnings by replacing with C-style comments, as per the
kernel docs.

Signed-off-by: Tim Collier 
---
 drivers/staging/wlan-ng/hfa384x.h  | 2 +-
 drivers/staging/wlan-ng/p80211conv.h   | 2 +-
 drivers/staging/wlan-ng/p80211hdr.h| 2 +-
 drivers/staging/wlan-ng/p80211ioctl.h  | 2 +-
 drivers/staging/wlan-ng/p80211metadef.h| 2 +-
 drivers/staging/wlan-ng/p80211metastruct.h | 2 +-
 drivers/staging/wlan-ng/p80211mgmt.h   | 2 +-
 drivers/staging/wlan-ng/p80211msg.h| 2 +-
 drivers/staging/wlan-ng/p80211netdev.h | 2 +-
 drivers/staging/wlan-ng/p80211req.h| 2 +-
 drivers/staging/wlan-ng/p80211types.h  | 2 +-
 drivers/staging/wlan-ng/prism2mgmt.h   | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x.h 
b/drivers/staging/wlan-ng/hfa384x.h
index 85c3af00abd2..67a944c0d690 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* hfa384x.h
  *
  * Defines the constants and data structures for the hfa384x
diff --git a/drivers/staging/wlan-ng/p80211conv.h 
b/drivers/staging/wlan-ng/p80211conv.h
index 28459dcea4b1..5c1c35c6e02d 100644
--- a/drivers/staging/wlan-ng/p80211conv.h
+++ b/drivers/staging/wlan-ng/p80211conv.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211conv.h
  *
  * Ether/802.11 conversions and packet buffer routines
diff --git a/drivers/staging/wlan-ng/p80211hdr.h 
b/drivers/staging/wlan-ng/p80211hdr.h
index 133d70c08ecf..26b178721414 100644
--- a/drivers/staging/wlan-ng/p80211hdr.h
+++ b/drivers/staging/wlan-ng/p80211hdr.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211hdr.h
  *
  * Macros, types, and functions for handling 802.11 MAC headers
diff --git a/drivers/staging/wlan-ng/p80211ioctl.h 
b/drivers/staging/wlan-ng/p80211ioctl.h
index d8cde1d8870b..ed65ac57adbe 100644
--- a/drivers/staging/wlan-ng/p80211ioctl.h
+++ b/drivers/staging/wlan-ng/p80211ioctl.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211ioctl.h
  *
  * Declares constants and types for the p80211 ioctls
diff --git a/drivers/staging/wlan-ng/p80211metadef.h 
b/drivers/staging/wlan-ng/p80211metadef.h
index 4ac2f08a520a..e63b4b557d0a 100644
--- a/drivers/staging/wlan-ng/p80211metadef.h
+++ b/drivers/staging/wlan-ng/p80211metadef.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* This file is GENERATED AUTOMATICALLY.  DO NOT EDIT OR MODIFY.
  * 
  *
diff --git a/drivers/staging/wlan-ng/p80211metastruct.h 
b/drivers/staging/wlan-ng/p80211metastruct.h
index 15b7c08e210d..089e46055462 100644
--- a/drivers/staging/wlan-ng/p80211metastruct.h
+++ b/drivers/staging/wlan-ng/p80211metastruct.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* This file is GENERATED AUTOMATICALLY.  DO NOT EDIT OR MODIFY.
 * 
 *
diff --git a/drivers/staging/wlan-ng/p80211mgmt.h 
b/drivers/staging/wlan-ng/p80211mgmt.h
index 3c12929858cb..c045c08e1991 100644
--- a/drivers/staging/wlan-ng/p80211mgmt.h
+++ b/drivers/staging/wlan-ng/p80211mgmt.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211mgmt.h
  *
  * Macros, types, and functions to handle 802.11 mgmt frames
diff --git a/drivers/staging/wlan-ng/p80211msg.h 
b/drivers/staging/wlan-ng/p80211msg.h
index ae119ecd74b0..114066526df4 100644
--- a/drivers/staging/wlan-ng/p80211msg.h
+++ b/drivers/staging/wlan-ng/p80211msg.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211msg.h
  *
  * Macros, constants, types, and funcs for req and ind messages
diff --git a/drivers/staging/wlan-ng/p80211netdev.h 
b/drivers/staging/wlan-ng/p80211netdev.h
index cebbe746a52f..fbac47311f26 100644
--- a/drivers/staging/wlan-ng/p80211netdev.h
+++ b/drivers/staging/wlan-ng/p80211netdev.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1)
+/* SPDX-License-Identifier: (GPL-2.0 OR MPL-1.1) */
 /* p80211netdev.h
  *
  * WLAN net device structure and functions
diff --git a/drivers/staging/wlan-ng/p80211req.h 
b/drivers/staging/wlan-ng/p80211req.h
index 20be2c3af4c1..c04053f3b02b 100644
--- a/drivers/staging/wlan-ng/p80211req.h
+++ b/drivers/staging/wlan-ng/p80211req.h
@@ -1,4 +1,4 @@
-// 

[PATCH] media: staging: atomisp: fix a potential missing-check bug

[Wenwen Wang]

At the end of atomisp_subdev_set_selection(), the function
atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. Since
this function may return a NULL pointer, it is firstly invoked to check
the returned pointer. If the returned pointer is not NULL, then the
function is invoked again to obtain the pointer and the memory content
at the location of the returned pointer is copied to the memory location of
r. In most cases, the pointers returned by the two invocations are same.
However, given that the pointer returned by the function
atomisp_subdev_get_rect() is not a constant, it is possible that the two
invocations return two different pointers. For example, another thread may
race to modify the related pointers during the two invocations. In that
case, even if the first returned pointer is not null, the second returned
pointer might be null, which will cause issues such as null pointer
dereference.

This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.

Signed-off-by: Wenwen Wang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
index 49a9973..d5fa513 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
@@ -366,6 +366,7 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
unsigned int i;
unsigned int padding_w = pad_w;
unsigned int padding_h = pad_h;
+   struct v4l2_rect *p;
 
stream_id = atomisp_source_pad_to_stream_id(isp_sd, vdev_pad);
 
@@ -536,9 +537,10 @@ int atomisp_subdev_set_selection(struct v4l2_subdev *sd,
ffmt[pad]->height = comp[pad]->height;
}
 
-   if (!atomisp_subdev_get_rect(sd, cfg, which, pad, target))
+   p = atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   if (!p)
return -EINVAL;
-   *r = *atomisp_subdev_get_rect(sd, cfg, which, pad, target);
+   *r = *p;
 
dev_dbg(isp->dev, "sel actual: l %d t %d w %d h %d\n",
r->left, r->top, r->width, r->height);
-- 
2.7.4

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

[PATCH V2 2/5] X86: Hyper-V: Enable IPI enlightenments

[kys]

From: "K. Y. Srinivasan" 

Hyper-V supports hypercalls to implement IPI; use them.

Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/hv_apic.c  | 118 +
 arch/x86/hyperv/hv_init.c  |  27 +
 arch/x86/include/asm/hyperv-tlfs.h |  15 +
 arch/x86/include/asm/mshyperv.h|   1 +
 4 files changed, 161 insertions(+)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 41f8b71ca19e..f52d08a7a343 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -31,6 +31,9 @@
 #include 
 
 #if IS_ENABLED(CONFIG_HYPERV)
+
+static struct apic orig_apic;
+
 static u64 hv_apic_icr_read(void)
 {
u64 reg_val;
@@ -86,8 +89,123 @@ static void hv_apic_eoi_write(u32 reg, u32 val)
wrmsr(HV_X64_MSR_EOI, val, 0);
 }
 
+/*
+ * IPI implementation on Hyper-V.
+ */
+static bool __send_ipi_mask(const struct cpumask *mask, int vector)
+{
+   int cur_cpu, vcpu;
+   struct ipi_arg_non_ex **arg;
+   struct ipi_arg_non_ex *ipi_arg;
+   int ret = 1;
+   unsigned long flags;
+
+   if (cpumask_empty(mask))
+   return true;
+
+   if (!hv_hypercall_pg)
+   return false;
+
+   if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR))
+   return false;
+
+   local_irq_save(flags);
+   arg = (struct ipi_arg_non_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
+
+   ipi_arg = *arg;
+   if (unlikely(!ipi_arg))
+   goto ipi_mask_done;
+
+   ipi_arg->vector = vector;
+   ipi_arg->reserved = 0;
+   ipi_arg->cpu_mask = 0;
+
+   for_each_cpu(cur_cpu, mask) {
+   vcpu = hv_cpu_number_to_vp_number(cur_cpu);
+   /*
+* This particular version of the IPI hypercall can
+* only target upto 64 CPUs.
+*/
+   if (vcpu >= 64)
+   goto ipi_mask_done;
+
+   __set_bit(vcpu, (unsigned long *)_arg->cpu_mask);
+   }
+
+   ret = hv_do_hypercall(HVCALL_SEND_IPI, ipi_arg, NULL);
+
+ipi_mask_done:
+   local_irq_restore(flags);
+   return ((ret == 0) ? true : false);
+}
+
+static bool __send_ipi_one(int cpu, int vector)
+{
+   struct cpumask mask = CPU_MASK_NONE;
+
+   cpumask_set_cpu(cpu, );
+   return __send_ipi_mask(, vector);
+}
+
+static void hv_send_ipi(int cpu, int vector)
+{
+   if (!__send_ipi_one(cpu, vector))
+   orig_apic.send_IPI(cpu, vector);
+}
+
+static void hv_send_ipi_mask(const struct cpumask *mask, int vector)
+{
+   if (!__send_ipi_mask(mask, vector))
+   orig_apic.send_IPI_mask(mask, vector);
+}
+
+static void hv_send_ipi_mask_allbutself(const struct cpumask *mask, int vector)
+{
+   unsigned int this_cpu = smp_processor_id();
+   struct cpumask new_mask;
+   const struct cpumask *local_mask;
+
+   cpumask_copy(_mask, mask);
+   cpumask_clear_cpu(this_cpu, _mask);
+   local_mask = _mask;
+   if (!__send_ipi_mask(local_mask, vector))
+   orig_apic.send_IPI_mask_allbutself(mask, vector);
+}
+
+static void hv_send_ipi_allbutself(int vector)
+{
+   hv_send_ipi_mask_allbutself(cpu_online_mask, vector);
+}
+
+static void hv_send_ipi_all(int vector)
+{
+   if (!__send_ipi_mask(cpu_online_mask, vector))
+   orig_apic.send_IPI_all(vector);
+}
+
+static void hv_send_ipi_self(int vector)
+{
+   if (!__send_ipi_one(smp_processor_id(), vector))
+   orig_apic.send_IPI_self(vector);
+}
+
 void __init hv_apic_init(void)
 {
+   if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
+   pr_info("Hyper-V: Using IPI hypercalls\n");
+   /*
+* Set the IPI entry points.
+*/
+   orig_apic = *apic;
+
+   apic->send_IPI = hv_send_ipi;
+   apic->send_IPI_mask = hv_send_ipi_mask;
+   apic->send_IPI_mask_allbutself = hv_send_ipi_mask_allbutself;
+   apic->send_IPI_allbutself = hv_send_ipi_allbutself;
+   apic->send_IPI_all = hv_send_ipi_all;
+   apic->send_IPI_self = hv_send_ipi_self;
+   }
+
if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
pr_info("Hyper-V: Using MSR based APIC access\n");
apic_set_eoi_write(hv_apic_eoi_write);
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 71e50fc2b7ef..6bc90d68ac8b 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -91,12 +91,19 @@ EXPORT_SYMBOL_GPL(hv_vp_index);
 struct hv_vp_assist_page **hv_vp_assist_page;
 EXPORT_SYMBOL_GPL(hv_vp_assist_page);
 
+void  __percpu **hyperv_pcpu_input_arg;
+EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
+
 u32 hv_max_vp_index;
 
 static int hv_cpu_init(unsigned int cpu)
 {
u64 msr_vp_index;
struct hv_vp_assist_page **hvp = 

[PATCH V2 5/5] X86: Hyper-V: Consolidate the allocation of the hypercall input page

[kys]

From: "K. Y. Srinivasan" 

Consolidate the allocation of the hypercall input page.

Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/hv_init.c   |  2 --
 arch/x86/hyperv/mmu.c   | 30 ++
 arch/x86/include/asm/mshyperv.h |  1 -
 3 files changed, 6 insertions(+), 27 deletions(-)

diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 6bc90d68ac8b..4c431e1c1eff 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -324,8 +324,6 @@ void __init hyperv_init(void)
hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 
-   hyper_alloc_mmu();
-
hv_apic_init();
 
/*
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index c9cd28f0bae4..5f053d7d1bd9 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -32,9 +32,6 @@ struct hv_flush_pcpu_ex {
 /* Each gva in gva_list encodes up to 4096 pages to flush */
 #define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
 
-static struct hv_flush_pcpu __percpu **pcpu_flush;
-
-static struct hv_flush_pcpu_ex __percpu **pcpu_flush_ex;
 
 /*
  * Fills in gva_list starting from offset. Returns the number of items added.
@@ -77,7 +74,7 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
 
trace_hyperv_mmu_flush_tlb_others(cpus, info);
 
-   if (!pcpu_flush || !hv_hypercall_pg)
+   if (!hv_hypercall_pg)
goto do_native;
 
if (cpumask_empty(cpus))
@@ -85,10 +82,8 @@ static void hyperv_flush_tlb_others(const struct cpumask 
*cpus,
 
local_irq_save(flags);
 
-   flush_pcpu = this_cpu_ptr(pcpu_flush);
-
-   if (unlikely(!*flush_pcpu))
-   *flush_pcpu = page_address(alloc_page(GFP_ATOMIC));
+   flush_pcpu = (struct hv_flush_pcpu **)
+this_cpu_ptr(hyperv_pcpu_input_arg);
 
flush = *flush_pcpu;
 
@@ -164,7 +159,7 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask 
*cpus,
 
trace_hyperv_mmu_flush_tlb_others(cpus, info);
 
-   if (!pcpu_flush_ex || !hv_hypercall_pg)
+   if (!hv_hypercall_pg)
goto do_native;
 
if (cpumask_empty(cpus))
@@ -172,10 +167,8 @@ static void hyperv_flush_tlb_others_ex(const struct 
cpumask *cpus,
 
local_irq_save(flags);
 
-   flush_pcpu = this_cpu_ptr(pcpu_flush_ex);
-
-   if (unlikely(!*flush_pcpu))
-   *flush_pcpu = page_address(alloc_page(GFP_ATOMIC));
+   flush_pcpu = (struct hv_flush_pcpu_ex **)
+this_cpu_ptr(hyperv_pcpu_input_arg);
 
flush = *flush_pcpu;
 
@@ -257,14 +250,3 @@ void hyperv_setup_mmu_ops(void)
pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others_ex;
}
 }
-
-void hyper_alloc_mmu(void)
-{
-   if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED))
-   return;
-
-   if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
-   pcpu_flush = alloc_percpu(struct hv_flush_pcpu *);
-   else
-   pcpu_flush_ex = alloc_percpu(struct hv_flush_pcpu_ex *);
-}
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 0ee82519957b..9aaa493f5756 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -294,7 +294,6 @@ static inline int cpumask_to_vpset(struct hv_vpset *vpset,
 
 void __init hyperv_init(void);
 void hyperv_setup_mmu_ops(void);
-void hyper_alloc_mmu(void);
 void hyperv_report_panic(struct pt_regs *regs, long err);
 bool hv_is_hyperv_initialized(void);
 void hyperv_cleanup(void);
-- 
2.15.1

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

[PATCH V2 4/5] X86: Hyper-V: Consolidate code for converting cpumask to vpset

[kys]

From: "K. Y. Srinivasan" 

Consolidate code for converting cpumask to vpset.

Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/mmu.c | 43 ++-
 1 file changed, 2 insertions(+), 41 deletions(-)

diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index adee39a7a3f2..c9cd28f0bae4 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -25,11 +25,7 @@ struct hv_flush_pcpu {
 struct hv_flush_pcpu_ex {
u64 address_space;
u64 flags;
-   struct {
-   u64 format;
-   u64 valid_bank_mask;
-   u64 bank_contents[];
-   } hv_vp_set;
+   struct hv_vpset hv_vp_set;
u64 gva_list[];
 };
 
@@ -70,41 +66,6 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
return gva_n - offset;
 }
 
-/* Return the number of banks in the resulting vp_set */
-static inline int cpumask_to_vp_set(struct hv_flush_pcpu_ex *flush,
-   const struct cpumask *cpus)
-{
-   int cpu, vcpu, vcpu_bank, vcpu_offset, nr_bank = 1;
-
-   /* valid_bank_mask can represent up to 64 banks */
-   if (hv_max_vp_index / 64 >= 64)
-   return 0;
-
-   /*
-* Clear all banks up to the maximum possible bank as hv_flush_pcpu_ex
-* structs are not cleared between calls, we risk flushing unneeded
-* vCPUs otherwise.
-*/
-   for (vcpu_bank = 0; vcpu_bank <= hv_max_vp_index / 64; vcpu_bank++)
-   flush->hv_vp_set.bank_contents[vcpu_bank] = 0;
-
-   /*
-* Some banks may end up being empty but this is acceptable.
-*/
-   for_each_cpu(cpu, cpus) {
-   vcpu = hv_cpu_number_to_vp_number(cpu);
-   vcpu_bank = vcpu / 64;
-   vcpu_offset = vcpu % 64;
-   __set_bit(vcpu_offset, (unsigned long *)
- >hv_vp_set.bank_contents[vcpu_bank]);
-   if (vcpu_bank >= nr_bank)
-   nr_bank = vcpu_bank + 1;
-   }
-   flush->hv_vp_set.valid_bank_mask = GENMASK_ULL(nr_bank - 1, 0);
-
-   return nr_bank;
-}
-
 static void hyperv_flush_tlb_others(const struct cpumask *cpus,
const struct flush_tlb_info *info)
 {
@@ -240,7 +201,7 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask 
*cpus,
 
if (!cpumask_equal(cpus, cpu_present_mask)) {
flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
-   nr_bank = cpumask_to_vp_set(flush, cpus);
+   nr_bank = cpumask_to_vpset(&(flush->hv_vp_set), cpus);
}
 
if (!nr_bank) {
-- 
2.15.1

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

[PATCH V2 1/5] X86: Hyper-V: Enlighten APIC access

[kys]

From: "K. Y. Srinivasan" 

Hyper-V supports MSR based APIC access; implement
the enlightenment.

Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/Makefile|   2 +-
 arch/x86/hyperv/hv_apic.c   | 101 
 arch/x86/hyperv/hv_init.c   |   5 +-
 arch/x86/include/asm/mshyperv.h |   4 +-
 4 files changed, 109 insertions(+), 3 deletions(-)
 create mode 100644 arch/x86/hyperv/hv_apic.c

diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index 367a8203cfcf..00ce4df01a09 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1 +1 @@
-obj-y  := hv_init.o mmu.o
+obj-y  := hv_init.o mmu.o hv_apic.o
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
new file mode 100644
index ..41f8b71ca19e
--- /dev/null
+++ b/arch/x86/hyperv/hv_apic.c
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Hyper-V specific APIC code.
+ *
+ * Copyright (C) 2018, Microsoft, Inc.
+ *
+ * Author : K. Y. Srinivasan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if IS_ENABLED(CONFIG_HYPERV)
+static u64 hv_apic_icr_read(void)
+{
+   u64 reg_val;
+
+   rdmsrl(HV_X64_MSR_ICR, reg_val);
+   return reg_val;
+}
+
+static void hv_apic_icr_write(u32 low, u32 id)
+{
+   u64 reg_val;
+
+   reg_val = SET_APIC_DEST_FIELD(id);
+   reg_val = reg_val << 32;
+   reg_val |= low;
+
+   wrmsrl(HV_X64_MSR_ICR, reg_val);
+}
+
+static u32 hv_apic_read(u32 reg)
+{
+   u32 reg_val, hi;
+
+   switch (reg) {
+   case APIC_EOI:
+   rdmsr(HV_X64_MSR_EOI, reg_val, hi);
+   return reg_val;
+   case APIC_TASKPRI:
+   rdmsr(HV_X64_MSR_TPR, reg_val, hi);
+   return reg_val;
+
+   default:
+   return native_apic_mem_read(reg);
+   }
+}
+
+static void hv_apic_write(u32 reg, u32 val)
+{
+   switch (reg) {
+   case APIC_EOI:
+   wrmsr(HV_X64_MSR_EOI, val, 0);
+   break;
+   case APIC_TASKPRI:
+   wrmsr(HV_X64_MSR_TPR, val, 0);
+   break;
+   default:
+   native_apic_mem_write(reg, val);
+   }
+}
+
+static void hv_apic_eoi_write(u32 reg, u32 val)
+{
+   wrmsr(HV_X64_MSR_EOI, val, 0);
+}
+
+void __init hv_apic_init(void)
+{
+   if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
+   pr_info("Hyper-V: Using MSR based APIC access\n");
+   apic_set_eoi_write(hv_apic_eoi_write);
+   apic->read  = hv_apic_read;
+   apic->write = hv_apic_write;
+   apic->icr_write = hv_apic_icr_write;
+   apic->icr_read  = hv_apic_icr_read;
+   }
+}
+
+#endif /*CONFIG_HYPERV */
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index cfecc2272f2d..71e50fc2b7ef 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -242,8 +242,9 @@ static int hv_cpu_die(unsigned int cpu)
  *
  * 1. Setup the hypercall page.
  * 2. Register Hyper-V specific clocksource.
+ * 3. Setup Hyper-V specific APIC entry points.
  */
-void hyperv_init(void)
+void __init hyperv_init(void)
 {
u64 guest_id, required_msrs;
union hv_x64_msr_hypercall_contents hypercall_msr;
@@ -298,6 +299,8 @@ void hyperv_init(void)
 
hyper_alloc_mmu();
 
+   hv_apic_init();
+
/*
 * Register Hyper-V specific clocksource.
 */
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index b90e79610cf7..162977b82e2e 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -258,7 +258,7 @@ static inline int hv_cpu_number_to_vp_number(int cpu_number)
return hv_vp_index[cpu_number];
 }
 
-void hyperv_init(void);
+void __init hyperv_init(void);
 void hyperv_setup_mmu_ops(void);
 void hyper_alloc_mmu(void);
 void hyperv_report_panic(struct pt_regs *regs, long err);
@@ -269,6 +269,7 @@ void hyperv_reenlightenment_intr(struct pt_regs *regs);
 void set_hv_tscchange_cb(void (*cb)(void));
 void clear_hv_tscchange_cb(void);
 void hyperv_stop_tsc_emulation(void);
+void hv_apic_init(void);
 #else /* CONFIG_HYPERV */
 static inline void hyperv_init(void) {}
 static inline bool hv_is_hyperv_initialized(void) { return false; }
@@ -277,6 +278,7 @@ static inline void hyperv_setup_mmu_ops(void) 

[PATCH V2 3/5] X86: Hyper-V: Enhanced IPI enlightenment

[kys]

From: "K. Y. Srinivasan" 

Support enhanced IPI enlightenments (to target more than 64 CPUs).

Signed-off-by: K. Y. Srinivasan 
---
 arch/x86/hyperv/hv_apic.c  | 42 +-
 arch/x86/hyperv/mmu.c  |  2 +-
 arch/x86/include/asm/hyperv-tlfs.h | 15 +-
 arch/x86/include/asm/mshyperv.h| 33 ++
 4 files changed, 89 insertions(+), 3 deletions(-)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index f52d08a7a343..1e269a318c27 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -92,6 +92,40 @@ static void hv_apic_eoi_write(u32 reg, u32 val)
 /*
  * IPI implementation on Hyper-V.
  */
+static bool __send_ipi_mask_ex(const struct cpumask *mask, int vector)
+{
+   struct ipi_arg_ex **arg;
+   struct ipi_arg_ex *ipi_arg;
+   unsigned long flags;
+   int nr_bank = 0;
+   int ret = 1;
+
+   local_irq_save(flags);
+   arg = (struct ipi_arg_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
+
+   ipi_arg = *arg;
+   if (unlikely(!ipi_arg))
+   goto ipi_mask_ex_done;
+
+   ipi_arg->vector = vector;
+   ipi_arg->reserved = 0;
+   ipi_arg->vp_set.valid_bank_mask = 0;
+
+   if (!cpumask_equal(mask, cpu_present_mask)) {
+   ipi_arg->vp_set.format = HV_GENERIC_SET_SPARSE_4K;
+   nr_bank = cpumask_to_vpset(&(ipi_arg->vp_set), mask);
+   }
+   if (!nr_bank)
+   ipi_arg->vp_set.format = HV_GENERIC_SET_ALL;
+
+   ret = hv_do_rep_hypercall(HVCALL_SEND_IPI_EX, 0, nr_bank,
+ ipi_arg, NULL);
+
+ipi_mask_ex_done:
+   local_irq_restore(flags);
+   return ((ret == 0) ? true : false);
+}
+
 static bool __send_ipi_mask(const struct cpumask *mask, int vector)
 {
int cur_cpu, vcpu;
@@ -109,6 +143,9 @@ static bool __send_ipi_mask(const struct cpumask *mask, int 
vector)
if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR))
return false;
 
+   if ((ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
+   return __send_ipi_mask_ex(mask, vector);
+
local_irq_save(flags);
arg = (struct ipi_arg_non_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
 
@@ -192,7 +229,10 @@ static void hv_send_ipi_self(int vector)
 void __init hv_apic_init(void)
 {
if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
-   pr_info("Hyper-V: Using IPI hypercalls\n");
+   if ((ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
+   pr_info("Hyper-V: Using ext hypercalls for IPI\n");
+   else
+   pr_info("Hyper-V: Using IPI hypercalls\n");
/*
 * Set the IPI entry points.
 */
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 56c9ebac946f..adee39a7a3f2 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -239,7 +239,7 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask 
*cpus,
flush->hv_vp_set.valid_bank_mask = 0;
 
if (!cpumask_equal(cpus, cpu_present_mask)) {
-   flush->hv_vp_set.format = HV_GENERIC_SET_SPARCE_4K;
+   flush->hv_vp_set.format = HV_GENERIC_SET_SPARSE_4K;
nr_bank = cpumask_to_vp_set(flush, cpus);
}
 
diff --git a/arch/x86/include/asm/hyperv-tlfs.h 
b/arch/x86/include/asm/hyperv-tlfs.h
index 332e786d4deb..3bfa92c2793c 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -344,6 +344,7 @@ struct hv_tsc_emulation_status {
 #define HVCALL_SEND_IPI0x000b
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX  0x0013
 #define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX   0x0014
+#define HVCALL_SEND_IPI_EX 0x0015
 #define HVCALL_POST_MESSAGE0x005c
 #define HVCALL_SIGNAL_EVENT0x005d
 
@@ -369,7 +370,7 @@ struct hv_tsc_emulation_status {
 #define HV_FLUSH_USE_EXTENDED_RANGE_FORMAT BIT(3)
 
 enum HV_GENERIC_SET_FORMAT {
-   HV_GENERIC_SET_SPARCE_4K,
+   HV_GENERIC_SET_SPARSE_4K,
HV_GENERIC_SET_ALL,
 };
 
@@ -721,4 +722,16 @@ struct ipi_arg_non_ex {
u64 cpu_mask;
 };
 
+struct hv_vpset {
+   u64 format;
+   u64 valid_bank_mask;
+   u64 bank_contents[];
+};
+
+struct ipi_arg_ex {
+   u32 vector;
+   u32 reserved;
+   struct hv_vpset vp_set;
+};
+
 #endif
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 1eff91599c2b..0ee82519957b 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -259,6 +259,39 @@ static inline int hv_cpu_number_to_vp_number(int 
cpu_number)
return hv_vp_index[cpu_number];
 }
 
+static inline int cpumask_to_vpset(struct hv_vpset *vpset,
+   const struct cpumask 

[PATCH V2 0/5] X86: Hyper-V: APIC enlightenments

[kys]

From: "K. Y. Srinivasan" 

Implement APIC related enlightenments.

V2: Addressed comments from Thomas Gleixner 
and Michael Kelley (EOSG) .

K. Y. Srinivasan (5):
  X86: Hyper-V: Enlighten APIC access
  X86: Hyper-V: Enable IPI enlightenments
  X86: Hyper-V: Enhanced IPI enlightenment
  X86: Hyper-V: Consolidate code for converting cpumask to vpset
  X86: Hyper-V: Consolidate the allocation of the hypercall input page

 arch/x86/hyperv/Makefile   |   2 +-
 arch/x86/hyperv/hv_apic.c  | 259 +
 arch/x86/hyperv/hv_init.c  |  32 -
 arch/x86/hyperv/mmu.c  |  75 ++-
 arch/x86/include/asm/hyperv-tlfs.h |  30 -
 arch/x86/include/asm/mshyperv.h|  39 +-
 6 files changed, 365 insertions(+), 72 deletions(-)
 create mode 100644 arch/x86/hyperv/hv_apic.c

-- 
2.15.1

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