Re: [PATCH v1] staging: ccree: fix all whitespace errors

2017-05-13 Thread Gilad Ben-Yossef
Hi Dhiru,

Thank you for patch.

On Sat, May 13, 2017 at 5:52 PM, Dhiru Kholia  wrote:
> These whitespace issues were found by the checkpatch.pl script. This
> patch helps in making the staging tree a bit cleaner.
>
> Signed-off-by: Dhiru Kholia 
> ---
>  drivers/staging/ccree/TODO|   2 +-
>  drivers/staging/ccree/cc_bitops.h |   6 +-
>  drivers/staging/ccree/cc_crypto_ctx.h |   8 +--
>  drivers/staging/ccree/cc_hal.h|   6 +-
>  drivers/staging/ccree/cc_hw_queue_defs.h  | 116 
> +++---
>  drivers/staging/ccree/cc_lli_defs.h   |   6 +-
>  drivers/staging/ccree/cc_pal_log.h|  12 ++--
>  drivers/staging/ccree/cc_pal_log_plat.h   |   6 +-
>  drivers/staging/ccree/cc_pal_types.h  |  42 +--
>  drivers/staging/ccree/cc_pal_types_plat.h |   8 +--
>  drivers/staging/ccree/cc_regs.h   |  10 +--
>  11 files changed, 111 insertions(+), 111 deletions(-)

I'm sorry, but your patch doesn't apply after the recent patch set that
removed some of those files.

It is indeed hard to follow up ...

Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru


Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

2017-05-13 Thread Ryder Lee

Hi Arnd,

Sorry to bother you again.

On Thu, 2017-05-11 at 20:11 +0800, Ryder Lee wrote:
> > interrupt-map-mask = <0xff800 0 0 0>;
> > interrupt-map = <0x 0 0 0  GIC_SPI 193 IRQ_TYPE_NONE>,
> >  <0x0800 0 0 0  GIC_SPI 194 IRQ_TYPE_NONE>,
> >  <0x1000 0 0 0  GIC_SPI 195 IRQ_TYPE_NONE>,
> > 
> >  /* workaround here*/
> >  <0x1 0 0 0  GIC_SPI 193 IRQ_TYPE_NONE>,
> >  <0x2 0 0 0  GIC_SPI 194 IRQ_TYPE_NONE>,
> >  <0x3 0 0 0  GIC_SPI 195 IRQ_TYPE_NONE>;
> > 
> > It works well. But how could we handle the situation if root port0
> > status = "disabled" ? I think we cannot assign child bus number
> > dynamically from binding.
> 
> That is to say, we route it statically if port0 (or port1) is
> unavailable. The PCI child bus enumeration should look something like
> this:
> 
>  pci :00:01.0: fixup irq: got 224
>  pci :00:01.0: assigning IRQ 224
>  pci :00:02.0: fixup irq: got 225
>  pci :00:02.0: assigning IRQ 225
>  
>  Go wrong here! IRQ 223/224 should be assigned to the devices behind
> port0 and port1.
>  pci :01:00.0: fixup irq: got 223
>  pci :01:00.0: assigning IRQ 223
>  pci :02:00.0: fixup irq: got 224
>  pci :02:00.0: assigning IRQ 224

What I thought was wrong. I have misunderstood something in previous
discussion. Actually it could work for the situation that I mentioned
before. However, I'm not sure whether this is a proper representation
you want to see.

> > > >> On a related note, I see that you still list
> > > >>
> > > >> > +- interrupts: Three interrupt outputs of the controller. Must 
> > > >> > contain an
> > > >> > +  entry for each entry in the interrupt-names property.
> > > >> > +- interrupt-names: Must include the following names
> > > >> > +  - "pcie-int0"
> > > >> > +  - "pcie-int1"
> > > >> > +  - "pcie-int2"
> > > >>
> > > >> This seems to be an artifact from the older version and should be
> > > >> removed as the driver correctly ignores the properties now.
> > > >
> > > > Actually, everything works fine without these properties however when it
> > > > loads we see a few weird error message:
> > > >
> > > > pcieport :00:01.0: Signaling PME with IRQ 232
> > > > pcieport :00:02.0: enabling device (0140 -> 0142)
> > > > pcieport :00:02.0: enabling bus mastering
> > > > irq 232: nobody cared (try booting with the "irqpoll" option)
> > > > ...
> > > > [] (pcie_pme_probe) from [] (pcie_port_probe_service
> > > > +0x44/0x6c)
> > > > (pcie_port_probe_service) from [] (driver_probe_device
> > > > +0x280/0x470)
> > > > ...
> > > > (pcie_port_device_register) from [] (pcie_portdrv_probe
> > > > +0x3c/0xb4)
> > > > (pcie_portdrv_probe) from [] (pci_device_probe+0x98/0xfc)
> > > > (pci_device_probe) from [] (driver_probe_device+0x280/0x470)
> > > > handlers:
> > > > [] pcie_pme_irq
> > > > Disabling IRQ #233
> > > >
> > > > I haven't dig it out yet, but just keep them here to solve that.
> > > 
> > > Something is going very wrong if adding the properties helps. I can't
> > > think of what that is, but we have to find out before the binding can
> > > be merged.
> > 
> > Not really understand PME service. But I will find the reason here.
> 
> I have do some test here. PME needs port IRQs, which interrupt type was
> set correctly(IRQ_TYPE_LEVEL_LOW). But we cannot set it from
> interrupt-map, according to gic_set_type() /* SPIs have restrictions on
> the supported types */ .
> 
> So we need to add additional interrupt properties.

I could use iPerf to test my WLAN card normally. But just ignore this
exception message. I would definitely appreciate if someone could give
me some hint on how to properly solve it. 

Thanks a lot.



Re: [PATCH v2 02/18] arm64: dts: amlogic: Sort Makefile

2017-05-13 Thread Chris Moore

Le 13/05/2017 à 16:33, Andreas Färber a écrit :

Sort the .dtb files alphabetically to make clear where to add new ones.

Signed-off-by: Andreas Färber 
---
  v1 -> v2:
  * Rebased (new boards added)
  * Extended commit message
  
  arch/arm64/boot/dts/amlogic/Makefile | 6 +++---

  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index b9ad2db7398b..14fa27ccd589 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -7,15 +7,15 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-meta.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-telos.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-hub.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-play2.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-hwacom-amazetv.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-khadas-vim.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-nexbox-a95x.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb


s905d should be before s905x if you are imposing alphabetical order.


-dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-hwacom-amazetv.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-nexbox-a95x.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
  dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
  
  always		:= $(dtb-y)

  subdir-y  := $(dts-dirs)





Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

2017-05-13 Thread Bjorn Andersson
On Thu 11 May 03:33 PDT 2017, Varadarajan Narayanan wrote:

> 
> 
> On 5/11/2017 4:13 AM, Bjorn Andersson wrote:
> > On Thu 04 May 04:53 PDT 2017, Varadarajan Narayanan wrote:
> > 
[..]
> > > +enum ipq8074_functions {
> > 
> > Please keep these sorted alphabetically.
> 
> Ok
> 
> > > + msm_mux_gpio,
> > > + msm_mux_qpic_pad,
> > > + msm_mux_blsp5_i2c,
> > > + msm_mux_blsp5_spi,
> > > + msm_mux_wci20,
> > 
> > What does "20" mean here?
> 
> This is for Wireless Coex Interface. The same functionality can be muxed on
> to different GPIOs. WCI2, is the 2nd edition of the WCI standard and 0, 1
> are for the muxing to different GPIOs (alternate muxes).
> 

In other Qualcomm platforms the alternative muxes are denoted by letters
(a,b,c...). Would you mind picking up this naming scheme, or do you see
any problems with that? (E.g. wci2a in this case)


Btw, do you need any additional configuration for selecting alternative
muxing or is that automagical these days?

> > > + msm_mux_blsp3_spi3,
> > > + msm_mux_burn0,
> > > + msm_mux_pcm_zsi0,
> > > + msm_mux_blsp5_uart,
> > > + msm_mux_mac12,
> > 
> > What does "12" mean here?
> 
> The SoC has three MAC cores. Each core has two pins for the smart antenna
> feature. macXY indicates the function select for MAC no. X and smart antenna
> no. Y.
> 

Ok

> > > + msm_mux_blsp3_spi0,
> > > + msm_mux_burn1,
> > > + msm_mux_mac01,
> > > + msm_mux_qdss_cti_trig_out_b0,
> > > + msm_mux_qdss_cti_trig_in_b0,
> > > + msm_mux_qpic_pad4,
> > 
> > What are qpic_pad and qpic_pad0 through qpic_pad8? Different functions,
> > alternative muxings...?
> 
> This is for the NAND and LCD display. The pins listed are the 9 data pins.
> 

Then you can describe them all as "qpic_pad" (or simply "qpic"?). (It's
possible to reference a partial group in the DTS, if that's necessary)

> > > + msm_mux_blsp4_uart0,
> > > + msm_mux_blsp4_i2c0,
> > > + msm_mux_blsp4_spi0,
> > > + msm_mux_mac21,
> > > + msm_mux_qdss_cti_trig_out_b1,
> > > + msm_mux_qpic_pad5,
> > > + msm_mux_qdss_cti_trig_in_b1,
> > > + msm_mux_qpic_pad6,
> > > + msm_mux_qpic_pad7,
> > > + msm_mux_cxc0,
> > > + msm_mux_mac13,
> > > + msm_mux_qdss_cti_trig_in_a1,
> > > + msm_mux_qdss_cti_trig_out_a1,
> > > + msm_mux_wci22,
> > > + msm_mux_qdss_cti_trig_in_a0,
> > > + msm_mux_qpic_pad1,
> > > + msm_mux_qdss_cti_trig_out_a0,
> > > + msm_mux_qpic_pad2,
> > > + msm_mux_qpic_pad3,
> > > + msm_mux_qdss_traceclk_b,
> > > + msm_mux_qpic_pad0,
> > > + msm_mux_qdss_tracectl_b,
> > > + msm_mux_qpic_pad8,
> > > + msm_mux_pcm_zsi1,
> > > + msm_mux_qdss_tracedata_b,
> > > + msm_mux_led0,
> > > + msm_mux_pwm04,
> > 
> > What does "04" mean here?
> 
> There are 4 Pulse Width Modulation channels, pwmXY is pwm channel X and pin
> Y.

So Y is alternative mux? Can we use letters for this as well?

> > 
> > > + msm_mux_led1,
> > > + msm_mux_pwm14,
> > > + msm_mux_led2,
> > > + msm_mux_pwm24,
> > > + msm_mux_pwm00,
> > > + msm_mux_blsp4_uart1,
> > 
> > Are uart0 vs uart1 alternative muxes?
> 
> These are two different uarts available at two independent pins.
> 

Ok, then I'm happy with the naming of this :)

Thanks,
Bjorn


Re: [PATCH 1/1] remoteproc: fix elf_loader da_to_va translation and writing beyond segment

2017-05-13 Thread Bjorn Andersson
On Thu 11 May 09:12 PDT 2017, Henri Roosen wrote:

> On 05/11/2017 02:05 AM, Bjorn Andersson wrote:
> > On Wed 03 May 05:12 PDT 2017, Henri Roosen wrote:
> > 
> > > Consider a system with 2 memory regions:
> > > 0x1fff8000 - 0x1fff: iram
> > 
> > So I presume there's a hole here.
> > 
> > > 0x2100 - 0x21007fff: dram
> > > 
> > > The .elf file for this system contains the following Program Headers:
> > > Program Headers:
> > >   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> > >   LOAD   0x94 0x1fff8000 0x1fff8000 0x00240 0x00240 R   0x4
> > >   LOAD   0x0002e0 0x1fff8240 0x1fff8240 0x03d1c 0x03d1c RWE 0x10
> > >   LOAD   0x003ffc 0x2100 0x1fffbf5c 0x001cc 0x048a0 RW  0x4
> > > 
> > 
> > Your ELF header states that there is a segment of 0x48a0 bytes starting
> > at 0x1fffbf5c, but your iram ends after 0x40a3 bytes. I assume your
> > MemSiz comes from some linker script, which would mean that your
> > firmware expects to be able to use all 0x48a0 bytes, which should be
> > invalid.
> 
> I had a closer look at the linker script. The .data section uses the
> "AT"-keyword to place the initialized .data right after the .text section
> (0x1fffbf5c/PhysAddr).
> 
> Some run-time startup-code is responsible for copying the initialized data
> to its runtime address (0x2100/VirtAddr). The run-time startup-code is
> also responsible for zero-ing the .bss section.
> 
> The size of the initialized data is 0x1cc (FileSiz). The size of the whole
> 3rd segment at run-time is 0x048a0 (MemSiz), starting from 0x2100
> (VirtAddr), which also includes the .bss .heap and .stack sections.
> 

[1] specifies that p_memsz is the size of the memory segment and
that the difference between p_filesz and p_memsz are defined to hold the
value 0.

So I believe that your segment list states that the physical range
0x1fffbf5c through 0x27fc is valid and should be populated.

[1] https://refspecs.linuxfoundation.org/elf/elf.pdf

Regards,
Bjorn


Re: [PATCH V2] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

2017-05-13 Thread Anshuman Khandual
On 05/13/2017 03:05 AM, Andrew Morton wrote:
> On Wed, 26 Apr 2017 09:27:31 +0530 Anshuman Khandual 
>  wrote:
> 
>> Though migrating gigantic HugeTLB pages does not sound much like real
>> world use case, they can be affected by memory errors. Hence migration
>> at the PGD level HugeTLB pages should be supported just to enable soft
>> and hard offline use cases.
>>
>> While allocating the new gigantic HugeTLB page, it should not matter
>> whether new page comes from the same node or not. There would be very
>> few gigantic pages on the system afterall, we should not be bothered
>> about node locality when trying to save a big page from crashing.
>>
>> This introduces a new HugeTLB allocator called alloc_huge_page_nonid()
>> which will scan over all online nodes on the system and allocate a
>> single HugeTLB page.
>>
>> ...
>>
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1669,6 +1669,23 @@ struct page *__alloc_buddy_huge_page_with_mpol(struct 
>> hstate *h,
>>  return __alloc_buddy_huge_page(h, vma, addr, NUMA_NO_NODE);
>>  }
>>  
>> +struct page *alloc_huge_page_nonid(struct hstate *h)
>> +{
>> +struct page *page = NULL;
>> +int nid = 0;
>> +
>> +spin_lock(_lock);
>> +if (h->free_huge_pages - h->resv_huge_pages > 0) {
>> +for_each_online_node(nid) {
>> +page = dequeue_huge_page_node(h, nid);
>> +if (page)
>> +break;
>> +}
>> +}
>> +spin_unlock(_lock);
>> +return page;
>> +}
>> +
>>  /*
>>   * This allocation function is useful in the context where vma is 
>> irrelevant.
>>   * E.g. soft-offlining uses this function because it only cares physical
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index fe64d7729a8e..d4f5710cf3f7 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1481,11 +1481,15 @@ EXPORT_SYMBOL(unpoison_memory);
>>  static struct page *new_page(struct page *p, unsigned long private, int **x)
>>  {
>>  int nid = page_to_nid(p);
>> -if (PageHuge(p))
>> +if (PageHuge(p)) {
>> +if (hstate_is_gigantic(page_hstate(compound_head(p
>> +return 
>> alloc_huge_page_nonid(page_hstate(compound_head(p)));
>> +
>>  return alloc_huge_page_node(page_hstate(compound_head(p)),
>> nid);
>> -else
>> +} else {
>>  return __alloc_pages_node(nid, GFP_HIGHUSER_MOVABLE, 0);
>> +}
>>  }
> 
> Rather than adding alloc_huge_page_nonid(), would it be neater to teach
> alloc_huge_page_node() (actually dequeue_huge_page_node()) to understand
> nid==NUMA_NO_NODE?

Sure, will change dequeue_huge_page_node() to accommodate NUMA_NO_NODE and
let soft offline call with NUMA_NO_NODE in case of gigantic huge pages.



[GIT PULL] watchdog updates for v4.12

2017-05-13 Thread Guenter Roeck
Hi Linus,

As requested by Wim:

Please pull watchdog updates for Linux v4.12 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
watchdog-for-linus-v4.12

Note: I had to drop one of the patches affecting drivers/watchdog/iTCO_wdt.c
because it and some other patches affecting the same file came in from
another tree, causing severe and unnecessary conflicts. Other than that,
the tree is about two weeks old, even though it looks like some of the
patches are brand new.

Thanks,
Guenter
--

The following changes since commit 39da7c509acff13fc8cb12ec1bb20337c988ed36:

  Linux 4.11-rc6 (2017-04-09 09:49:44 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/watchdog-for-linus-v4.12

for you to fetch changes up to edf44420d704503d349025f22ab1973350427cca:

  watchdog: bcm281xx: Fix use of uninitialized spinlock. (2017-05-13 20:26:30 
-0700)


Watchdog patches for v4.12

New drivers for STM32 and Renesas RZA watchdogs
Added support for F71868 to f71808e_wdt
Bug fixes and minor improvements in several drivers


Alexandre Belloni (4):
  watchdog: sama5d4: fix WDDIS handling
  watchdog: sama5d4: fix race condition
  watchdog: sama5d4: simplify probe
  watchdog: sama5d4: Add comment explaining what happens on resume

Andy Shevchenko (1):
  watchdog: intel-mid_wdt: Keep watchdog running

Arnd Bergmann (1):
  watchdog: orion: fix compile-test dependencies

Chris Brandt (2):
  watchdog: add rza_wdt driver
  watchdog: renesas-wdt: add support for rza

Eric Anholt (1):
  watchdog: bcm281xx: Fix use of uninitialized spinlock.

Guenter Roeck (1):
  watchdog: gpio: Convert to use infrastructure triggered keepalives

Johan Hovold (1):
  watchdog: pcwd_usb: fix NULL-deref at probe

Krzysztof Kozlowski (3):
  watchdog: s3c2410: Constify local structures
  watchdog: s3c2410: Simplify getting driver data
  watchdog: s3c2410: Minor code cleanup

Maciej S. Szmigiero (1):
  watchdog: f71808e_wdt: Add F71868 support

Paolo Bonzini (1):
  iTCO_wdt: all versions count down twice

Shile Zhang (1):
  watchdog: wdt_pci: fix build error if SOFTWARE_REBOOT is defined

Steve Twiss (1):
  Documentation: devicetree: watchdog: da9062/61 watchdog timer binding

Tomas Melin (1):
  watchdog: cadence_wdt: fix timeout setting

Uwe Kleine-König (1):
  watchdog: orion: make license info match the file header

Wei Yongjun (1):
  watchdog: zx2967: remove redundant dev_err call in zx2967_wdt_probe()

Yannick Fertre (2):
  dt-bindings: watchdog: Document STM32 IWDG bindings
  drivers: watchdog: Add STM32 IWDG driver

 .../devicetree/bindings/watchdog/da9062-wdt.txt|  23 ++
 .../devicetree/bindings/watchdog/renesas-wdt.txt   |   4 +-
 .../devicetree/bindings/watchdog/st,stm32-iwdg.txt |  19 ++
 Documentation/watchdog/watchdog-parameters.txt |   2 +-
 drivers/watchdog/Kconfig   |  29 ++-
 drivers/watchdog/Makefile  |   2 +
 drivers/watchdog/bcm_kona_wdt.c|   3 +-
 drivers/watchdog/cadence_wdt.c |   2 +-
 drivers/watchdog/f71808e_wdt.c |  27 ++-
 drivers/watchdog/gpio_wdt.c|  73 ++
 drivers/watchdog/iTCO_wdt.c|  22 +-
 drivers/watchdog/intel-mid_wdt.c   |  17 +-
 drivers/watchdog/orion_wdt.c   |   2 +-
 drivers/watchdog/pcwd_usb.c|   3 +
 drivers/watchdog/rza_wdt.c | 199 
 drivers/watchdog/s3c2410_wdt.c |  58 +++--
 drivers/watchdog/sama5d4_wdt.c |  96 +---
 drivers/watchdog/stm32_iwdg.c  | 253 +
 drivers/watchdog/wdt_pci.c |   2 +-
 drivers/watchdog/zx2967_wdt.c  |   4 +-
 20 files changed, 686 insertions(+), 154 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
 create mode 100644 drivers/watchdog/rza_wdt.c
 create mode 100644 drivers/watchdog/stm32_iwdg.c


Re: [PATCH 1/2] ARM: dts: qcom-apq8064: Collapse usb support into one node

2017-05-13 Thread Bjorn Andersson
On Fri 12 May 14:18 PDT 2017, John Stultz wrote:

> From: Stephen Boyd 
> 
> We currently have three device nodes for the same USB hardware
> block, as evident by the reuse of the same reg address multiple
> times. Now that the chipidea driver fully supports OTG with the
> MSM wrapper we can collapse the three nodes into one USB device
> node, reflecting the true nature of the hardware.
> 
> Since we're here, we also mark the irq trigger flags correctly,
> as IRQ_TYPE_LEVEL_HIGH instead of IRQ_TYPE_NONE.
> 
> Cc: Bjorn Andersson 

Acked-by: Bjorn Andersson 

Regards,
Bjorn


Re: [PATCH] mm/madvise: Dont poison entire HugeTLB page for single page errors

2017-05-13 Thread Anshuman Khandual
On 05/12/2017 01:40 PM, Naoya Horiguchi wrote:
> On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote:
>> Currently soft_offline_page() migrates the entire HugeTLB page, then
>> dequeues it from the active list by making it a dangling HugeTLB page
>> which ofcourse can not be used further and marks the entire HugeTLB
>> page as poisoned. This might be a costly waste of memory if the error
>> involved affects only small section of the entire page.
>>
>> This changes the behaviour so that only the affected page is marked
>> poisoned and then the HugeTLB page is released back to buddy system.
> Hi Anshuman,
> 
> This is a good catch, and we can solve this issue now because freeing
> hwpoisoned page (previously forbidden) is available now.
> 
> And I'm thinking that the same issue for hard/soft-offline on free
> hugepages can be solved, so I'll submit a patchset which includes
> updated version of your patch.

Sure, thanks Naoya.



[PATCH v3 1/5] dt-bindings: Add vendor prefix for Zidoo

2017-05-13 Thread Andreas Färber
Zidoo is a Chinese manufacturer of TV boxes.

Acked-by: Arnd Bergmann 
Acked-by: Rob Herring 
Acked-by: Roc He 
Signed-off-by: Andreas Färber 
---
 v2 -> v3: unchanged
 
 v1 -> v2:
 * Changed subject
 * Extended commit message
 
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d20140366..f032fa69f9d1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -356,6 +356,7 @@ xlnxXilinx
 xunlongShenzhen Xunlong Software CO.,Limited
 zarlinkZarlink Semiconductor
 zeitec ZEITEC Semiconductor Co., LTD.
+zidoo  Shenzhen Zidoo Technology Co., Ltd.
 ziiZodiac Inflight Innovations
 zteZTE Corp.
 zyxel  ZyXEL Communications Corp.
-- 
2.12.0



[PATCH v3 2/5] dt-bindings: arm: Add Realtek RTD1295 bindings

2017-05-13 Thread Andreas Färber
The Zidoo X9S and a few other recent TV boxes feature the Realtek RTD1295,
a quad-core ARM Cortex-A53 SoC.

Acked-by: Arnd Bergmann 
Acked-by: Roc He 
Acked-by: Rob Herring 
Signed-off-by: Andreas Färber 
---
 v2 -> v3: unchanged
 
 v1 -> v2:
 * Changed subject
 * Extended commit message
 * Clarified wording
 
 Documentation/devicetree/bindings/arm/realtek.txt | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/realtek.txt

diff --git a/Documentation/devicetree/bindings/arm/realtek.txt 
b/Documentation/devicetree/bindings/arm/realtek.txt
new file mode 100644
index ..13d755787b4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/realtek.txt
@@ -0,0 +1,20 @@
+Realtek platforms device tree bindings
+--
+
+
+RTD1295 SoC
+===
+
+Required root node properties:
+
+ - compatible :  must contain "realtek,rtd1295"
+
+
+Root node property compatible must contain, depending on board:
+
+ - Zidoo X9S: "zidoo,x9s"
+
+
+Example:
+
+compatible = "zidoo,x9s", "realtek,rtd1295";
-- 
2.12.0



[PATCH v3 4/5] ARM64: dts: Add Realtek RTD1295 and Zidoo X9S

2017-05-13 Thread Andreas Färber
Add initial device trees for the RTD1295 SoC and the Zidoo X9S TV box.

The CPUs lack the enable-method property because the vendor device tree
uses a custom "rtk-spin-table" method and "psci" did not appear to work.

The UARTs lack the interrupts properties because the vendor device tree
connects them to a custom interrupt controller. earlycon works without.

A list of memory reservations is adopted from v1.2.11 vendor device tree:
0x0220 can be used for an initrd, 0x01b0 is audio-related;
ion-related 0x0260, 0x02c0 and 0x1100 are left out;
0x1000 is used for sharing the U-Boot environment; others remain
to be investigated.

Acked-by: Arnd Bergmann 
Signed-off-by: Andreas Färber 
---
 v2 -> v3:
 * Adopted SPDX-License-Identifier (Rob)
 * Added ranges for /soc node (Rob)
 * Changed #address-cells and #size-cells to 1 (Rob)
 
 v1 -> v2:
 * Dropped 0x1000 /memreserve/
 
 arch/arm64/boot/dts/Makefile  |   1 +
 arch/arm64/boot/dts/realtek/Makefile  |   5 +
 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts |  42 +++
 arch/arm64/boot/dts/realtek/rtd1295.dtsi  | 131 ++
 4 files changed, 179 insertions(+)
 create mode 100644 arch/arm64/boot/dts/realtek/Makefile
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 080232b0270e..78f7991a5906 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -14,6 +14,7 @@ dts-dirs += marvell
 dts-dirs += mediatek
 dts-dirs += nvidia
 dts-dirs += qcom
+dts-dirs += realtek
 dts-dirs += renesas
 dts-dirs += rockchip
 dts-dirs += socionext
diff --git a/arch/arm64/boot/dts/realtek/Makefile 
b/arch/arm64/boot/dts/realtek/Makefile
new file mode 100644
index ..8521e921e59a
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts 
b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
new file mode 100644
index ..6efa8091bb30
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+/memreserve/   0x 0x0003;
+/memreserve/   0x0001f000 0x1000;
+/memreserve/   0x0003 0x000d;
+/memreserve/   0x01b0 0x004be000;
+/memreserve/   0x01ffe000 0x4000;
+
+#include "rtd1295.dtsi"
+
+/ {
+   compatible = "zidoo,x9s", "realtek,rtd1295";
+   model = "Zidoo X9S";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x8000>;
+   };
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi 
b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
new file mode 100644
index ..d8f84666c8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Realtek RTD1295 SoC
+ *
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include 
+
+/ {
+   compatible = "realtek,rtd1295";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   next-level-cache = <>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   next-level-cache = <>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   next-level-cache = <>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   next-level-cache = <>;
+   };
+
+   l2: l2-cache {
+   compatible = "cache";
+   };
+   };
+

[PATCH v3 5/5] MAINTAINERS: Add Realtek section

2017-05-13 Thread Andreas Färber
Add myself as maintainer.

Signed-off-by: Andreas Färber 
---
 v2 -> v3:
 * Changed status to Maintained
 
 v2: new
 
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ae4f7975b19..92c65bbc4ef3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1678,6 +1678,13 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/REALTEK ARCHITECTURE
+M: Andreas Färber 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm64/boot/dts/realtek/
+F: Documentation/devicetree/bindings/arm/realtek.txt
+
 ARM/RENESAS ARM64 ARCHITECTURE
 M: Simon Horman 
 M: Magnus Damm 
-- 
2.12.0



[PATCH v3 0/5] arm64: Initial Realtek RTD1295 enablement

2017-05-13 Thread Andreas Färber
Hello,

This mini-series adds initial support for the Realtek RTD1295 SoC and
the Zidoo X9S TV box.

v3 changes #address-cells, #size-cells and ranges.

With these patches CPU0 can be booted with earlycon.

PSCI doesn't work despite present in the vendor device tree; as enable-method
it instead used a custom "rtk-spin-table" that I sadly have no source code of.

The UARTs use a custom interrupt controller that I again lack source code of;
with interrupts =  it can boot into an initrd.

The boot process is slightly twisted: The files need to be loaded from a
32-bit U-Boot, then boot into 64-bit U-Boot where the kernel can be booted.
Similar to my previous Amlogic S905 work, the TEXT_OFFSET poses a problem, so
a uImage needs to be used (or the kernel patched) for load address 0x0028.
I haven't succeeded loading an initrd via bootm/booti; but as quick workaround
initrd=$rootfs_loadaddr,0x$filesize can manually be specified in $bootargs.

Cf. https://en.opensuse.org/HCL:Zidoo_X9S

More experimental patches at:
https://github.com/afaerber/linux/commits/rtd1295-next

Have a lot of fun!

Cheers,
Andreas

v2 -> v3:
* DT cleanups (Rob)
* Drop a...@kernel.org again (Olof)

v1 -> v2:
* Add Acked-bys
* Tweak DT subjects
* Reword DT bindings
* Drop one memreserve
* Add MAINTAINERS patch

Cc: Arnd Bergmann 
Cc: Olof Johansson 
Cc: Roc He 
Cc: devicet...@vger.kernel.org

Andreas Färber (5):
  dt-bindings: Add vendor prefix for Zidoo
  dt-bindings: arm: Add Realtek RTD1295 bindings
  ARM64: Prepare Realtek RTD1295
  ARM64: dts: Add Realtek RTD1295 and Zidoo X9S
  MAINTAINERS: Add Realtek section

 Documentation/devicetree/bindings/arm/realtek.txt  |  20 
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   7 ++
 arch/arm64/Kconfig.platforms   |   6 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/realtek/Makefile   |   5 +
 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts  |  42 +++
 arch/arm64/boot/dts/realtek/rtd1295.dtsi   | 131 +
 8 files changed, 213 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/realtek.txt
 create mode 100644 arch/arm64/boot/dts/realtek/Makefile
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dts
 create mode 100644 arch/arm64/boot/dts/realtek/rtd1295.dtsi

-- 
2.12.0



[PATCH v3 3/5] ARM64: Prepare Realtek RTD1295

2017-05-13 Thread Andreas Färber
Add a Kconfig option ARCH_REALTEK.

Acked-by: Arnd Bergmann 
Signed-off-by: Andreas Färber 
---
 v1 -> v2 -> v3: unchanged
 
 arch/arm64/Kconfig.platforms | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 73272f43ca01..b4e919ac73f6 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -126,6 +126,12 @@ config ARCH_QCOM
help
  This enables support for the ARMv8 based Qualcomm chipsets.
 
+config ARCH_REALTEK
+   bool "Realtek Platforms"
+   help
+ This enables support for the ARMv8 based Realtek chipsets,
+ like the RTD1295.
+
 config ARCH_ROCKCHIP
bool "Rockchip Platforms"
select ARCH_HAS_RESET_CONTROLLER
-- 
2.12.0



Re: [PATCH v2] Coccinelle: api: Add offset_in_page.cocci

2017-05-13 Thread Julia Lawall


On Fri, 5 May 2017, Vaishali Thakkar wrote:

> Use of offset_in_page is preferable instead of open coding.
> This patch adds coccinelle script for suggesting the use of
> macro offset_in_page.
>
> Signed-off-by: Vaishali Thakkar 
> ---
> Changes since v1:
>   - Add parenthesis around rule for patch mode to avoid
> extra parenthesis in end result
> ---
>  scripts/coccinelle/api/offset_in_page.cocci | 77 
> +
>  1 file changed, 77 insertions(+)
>  create mode 100644 scripts/coccinelle/api/offset_in_page.cocci
>
> diff --git a/scripts/coccinelle/api/offset_in_page.cocci 
> b/scripts/coccinelle/api/offset_in_page.cocci
> new file mode 100644
> index 000..4034864
> --- /dev/null
> +++ b/scripts/coccinelle/api/offset_in_page.cocci
> @@ -0,0 +1,77 @@
> +/// Use offset_in_page instead of duplicating its implementation
> +///
> +// Confidence: High
> +// Copyright: (C) 2017 Vaishali Thakkar, Oracle. GPLv2.
> +// Options: --no-includes --include-headers
> +// Keywords: offset_in_page
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +@r_patch depends on patch@
> +expression e;
> +identifier i;
> +@@
> +- unsigned long i = (unsigned long)e & ~PAGE_MASK;
> +...
> +- i
> ++ offset_in_page(e)

This doesn't take into account the possibility that i occurs more than
once.  It should be:

- unsigned long i = (unsigned long)e & ~PAGE_MASK;
<+...
- i
+ offset_in_page(e)
...+>

> +
> +@r1_patch depends on patch@
> +expression e1;
> +@@
> +
> +(
> +- ((unsigned long)e1 & ~PAGE_MASK)
> ++ offset_in_page(e1)
> +|
> +- ((unsigned long)e1 % PAGE_SIZE)
> ++ offset_in_page(e1)
> +)

& ~ and % are equivalent?  I did find both definitions in the kernel, but
I didn't think about whether they do the same thing.

julia

> +
> +@r_context depends on !patch@
> +expression e;
> +identifier i;
> +position p;
> +@@
> +
> +* unsigned long i = (unsigned long)e@p & ~PAGE_MASK;
> +...
> +* i
> +
> +@r1_context depends on !patch@
> +expression e1;
> +position p1;
> +@@
> +
> +(
> +* (unsigned long)e1@p1 & ~PAGE_MASK
> +|
> +* (unsigned long)e1@p1 % PAGE_SIZE
> +)
> +
> +@script:python depends on org@
> +p << r_context.p;
> +@@
> +
> +coccilib.org.print_todo(p[0], "WARNING opportunity for offset_in_page")
> +
> +@script:python depends on org@
> +p << r1_context.p1;
> +@@
> +
> +coccilib.org.print_todo(p[0], "WARNING opportunity for offset_in_page")
> +
> +@script:python depends on report@
> +p << r_context.p;
> +@@
> +
> +coccilib.report.print_report(p[0], "WARNING opportunity for offset_in_page")
> +
> +@script:python depends on report@
> +p << r1_context.p1;
> +@@
> +
> +coccilib.report.print_report(p[0], "WARNING opportunity for offset_in_page")
> --
> 2.7.4
>
>


[PATCH] dax: fix false CONFIG_BLOCK dependency

2017-05-13 Thread Dan Williams
In the BLOCK=n case the dax core does not need to / must not emit the
block-device-dax helpers. Otherwise it leads to compile errors.

Cc: Arnd Bergmann 
Reported-by: Fabian Frederick 
Fixes: ef51042472f5 ("block, dax: move 'select DAX' from BLOCK to FS_DAX")
Signed-off-by: Dan Williams 
---
 drivers/dax/super.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index ebf43f531ada..6ed32aac8bbe 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -44,6 +44,7 @@ void dax_read_unlock(int id)
 }
 EXPORT_SYMBOL_GPL(dax_read_unlock);
 
+#ifdef CONFIG_BLOCK
 int bdev_dax_pgoff(struct block_device *bdev, sector_t sector, size_t size,
pgoff_t *pgoff)
 {
@@ -112,6 +113,7 @@ int __bdev_dax_supported(struct super_block *sb, int 
blocksize)
return 0;
 }
 EXPORT_SYMBOL_GPL(__bdev_dax_supported);
+#endif
 
 /**
  * struct dax_device - anchor object for dax services



[PATCH] dax, xfs, ext4: compile out iomap-dax paths in the FS_DAX=n case

2017-05-13 Thread Dan Williams
Tetsuo reports:

  fs/built-in.o: In function `xfs_file_iomap_end':
  xfs_iomap.c:(.text+0xe0ef9): undefined reference to `put_dax'
  fs/built-in.o: In function `xfs_file_iomap_begin':
  xfs_iomap.c:(.text+0xe1a7f): undefined reference to `dax_get_by_host'
  make: *** [vmlinux] Error 1
  $ grep DAX .config
  CONFIG_DAX=m
  # CONFIG_DEV_DAX is not set
  # CONFIG_FS_DAX is not set

When FS_DAX=n we can/must throw away the dax code in filesystems.
Implement 'fs_' versions of dax_get_by_host() and put_dax() that are
nops in the FS_DAX=n case.

Cc: 
Cc: 
Cc: Jan Kara 
Cc: "Theodore Ts'o" 
Cc: "Darrick J. Wong" 
Cc: Ross Zwisler 
Fixes: ef51042472f5 ("block, dax: move 'select DAX' from BLOCK to FS_DAX")
Reported-by: Tetsuo Handa 
Signed-off-by: Dan Williams 
---
 fs/ext2/inode.c |4 ++--
 fs/ext4/inode.c |4 ++--
 fs/xfs/xfs_iomap.c  |4 ++--
 include/linux/dax.h |   34 +++---
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 26d77f9f8c12..2dcbd5698884 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -817,7 +817,7 @@ static int ext2_iomap_begin(struct inode *inode, loff_t 
offset, loff_t length,
iomap->bdev = bdev;
iomap->offset = (u64)first_block << blkbits;
if (blk_queue_dax(bdev->bd_queue))
-   iomap->dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
+   iomap->dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
else
iomap->dax_dev = NULL;
 
@@ -841,7 +841,7 @@ static int
 ext2_iomap_end(struct inode *inode, loff_t offset, loff_t length,
ssize_t written, unsigned flags, struct iomap *iomap)
 {
-   put_dax(iomap->dax_dev);
+   fs_put_dax(iomap->dax_dev);
if (iomap->type == IOMAP_MAPPED &&
written < length &&
(flags & IOMAP_WRITE))
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5834c4d76be8..1bd0bfa547f6 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3412,7 +3412,7 @@ static int ext4_iomap_begin(struct inode *inode, loff_t 
offset, loff_t length,
bdev = inode->i_sb->s_bdev;
iomap->bdev = bdev;
if (blk_queue_dax(bdev->bd_queue))
-   iomap->dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
+   iomap->dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
else
iomap->dax_dev = NULL;
iomap->offset = first_block << blkbits;
@@ -3447,7 +3447,7 @@ static int ext4_iomap_end(struct inode *inode, loff_t 
offset, loff_t length,
int blkbits = inode->i_blkbits;
bool truncate = false;
 
-   put_dax(iomap->dax_dev);
+   fs_put_dax(iomap->dax_dev);
if (!(flags & IOMAP_WRITE) || (flags & IOMAP_FAULT))
return 0;
 
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index a63f61c256bd..94e5bdf7304c 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1068,7 +1068,7 @@ xfs_file_iomap_begin(
/* optionally associate a dax device with the iomap bdev */
bdev = iomap->bdev;
if (blk_queue_dax(bdev->bd_queue))
-   iomap->dax_dev = dax_get_by_host(bdev->bd_disk->disk_name);
+   iomap->dax_dev = fs_dax_get_by_host(bdev->bd_disk->disk_name);
else
iomap->dax_dev = NULL;
 
@@ -1149,7 +1149,7 @@ xfs_file_iomap_end(
unsignedflags,
struct iomap*iomap)
 {
-   put_dax(iomap->dax_dev);
+   fs_put_dax(iomap->dax_dev);
if ((flags & IOMAP_WRITE) && iomap->type == IOMAP_DELALLOC)
return xfs_file_iomap_end_delalloc(XFS_I(inode), offset,
length, written, iomap);
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 00ebac854bb7..5ec1f6c47716 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -18,6 +18,20 @@ struct dax_operations {
void **, pfn_t *);
 };
 
+#if IS_ENABLED(CONFIG_DAX)
+struct dax_device *dax_get_by_host(const char *host);
+void put_dax(struct dax_device *dax_dev);
+#else
+static inline struct dax_device *dax_get_by_host(const char *host)
+{
+   return NULL;
+}
+
+static inline void put_dax(struct dax_device *dax_dev)
+{
+}
+#endif
+
 int bdev_dax_pgoff(struct block_device *, sector_t, size_t, pgoff_t *pgoff);
 #if IS_ENABLED(CONFIG_FS_DAX)
 int __bdev_dax_supported(struct super_block *sb, int blocksize);
@@ -25,23 +39,29 @@ static inline int bdev_dax_supported(struct super_block 
*sb, int blocksize)
 {
return __bdev_dax_supported(sb, blocksize);
 }
+
+static inline struct dax_device *fs_dax_get_by_host(const char *host)
+{
+   return dax_get_by_host(host);
+}
+
+static inline void fs_put_dax(struct dax_device *dax_dev)

Re: Makefile:541: arch/avr32/Makefile: No such file or directory

2017-05-13 Thread Randy Dunlap
Hi robby,

Too much automation maybe??

See the commit message:
avr32: remove support for AVR32
and then the error message...


On 05/13/17 17:05, kbuild test robot wrote:
> Hi Hans-Christian,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   2ea659a9ef488125eb46da6eb571de5eae5c43f6
> commit: 26202873bb51fafdaa51be3e8de7aab9beb49f70 avr32: remove support for 
> AVR32 architecture
> date:   13 days ago
> config: avr32-atngw100_defconfig
> compiler: avr-gcc (GCC) 4.9.2
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 26202873bb51fafdaa51be3e8de7aab9beb49f70
> make.cross ARCH=avr32  atngw100_defconfig
> make.cross ARCH=avr32 
> 
> All errors (new ones prefixed by >>):
> 
>>> Makefile:541: arch/avr32/Makefile: No such file or directory
>>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
>make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
>make[2]: *** [atngw100_defconfig] Error 1
>make[1]: *** [atngw100_defconfig] Error 2
>make: *** [sub-make] Error 2
> --
>Makefile:630: arch/avr32/Makefile: No such file or directory
>>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
>make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
>make: *** [sub-make] Error 2
> --
>>> Makefile:541: arch/avr32/Makefile: No such file or directory
>>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
>make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
>make[2]: *** [oldconfig] Error 1
>make[1]: *** [oldconfig] Error 2
>make: *** [sub-make] Error 2
> --
>>> Makefile:541: arch/avr32/Makefile: No such file or directory
>>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
>make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
>make[2]: *** [olddefconfig] Error 1
>make[2]: Target 'oldnoconfig' not remade because of errors.
>make[1]: *** [oldnoconfig] Error 2
>make: *** [sub-make] Error 2
> 
> vim +541 Makefile
> 
> 9319f4539 Masahiro Yamada 2014-04-09  525  
> 9319f4539 Masahiro Yamada 2014-04-09  526  __build_one_by_one:
> 9319f4539 Masahiro Yamada 2014-04-09  527 $(Q)set -e; \
> 9319f4539 Masahiro Yamada 2014-04-09  528 for i in $(MAKECMDGOALS); do \
> 9319f4539 Masahiro Yamada 2014-04-09  529 $(MAKE) -f 
> $(srctree)/Makefile $$i; \
> 9319f4539 Masahiro Yamada 2014-04-09  530 done
> ^1da177e4 Linus Torvalds  2005-04-16  531  
> ^1da177e4 Linus Torvalds  2005-04-16  532  else
> ^1da177e4 Linus Torvalds  2005-04-16  533  ifeq ($(config-targets),1)
> ^1da177e4 Linus Torvalds  2005-04-16  534  # 
> ===
> ^1da177e4 Linus Torvalds  2005-04-16  535  # *config targets only - make sure 
> prerequisites are updated, and descend
> ^1da177e4 Linus Torvalds  2005-04-16  536  # in scripts/kconfig to make the 
> *config target
> ^1da177e4 Linus Torvalds  2005-04-16  537  
> ^1da177e4 Linus Torvalds  2005-04-16  538  # Read arch specific Makefile to 
> set KBUILD_DEFCONFIG as needed.
> ^1da177e4 Linus Torvalds  2005-04-16  539  # KBUILD_DEFCONFIG may point out 
> an alternative default configuration
> ^1da177e4 Linus Torvalds  2005-04-16  540  # used for 'make defconfig'
> a436bb7b8 Masahiro Yamada 2015-03-27 @541  include arch/$(SRCARCH)/Makefile
> 61bee2044 Al Viro 2008-08-25  542  export KBUILD_DEFCONFIG 
> KBUILD_KCONFIG
> ^1da177e4 Linus Torvalds  2005-04-16  543  
> 31110ebbe Sam Ravnborg2008-12-13  544  config: scripts_basic 
> outputmakefile FORCE
> 31110ebbe Sam Ravnborg2008-12-13  545 $(Q)$(MAKE) 
> $(build)=scripts/kconfig $@
> 31110ebbe Sam Ravnborg2008-12-13  546  
> 31110ebbe Sam Ravnborg2008-12-13  547  %config: scripts_basic 
> outputmakefile FORCE
> ^1da177e4 Linus Torvalds  2005-04-16  548 $(Q)$(MAKE) 
> $(build)=scripts/kconfig $@
> ^1da177e4 Linus Torvalds  2005-04-16  549  
> 
> :: The code at line 541 was first introduced by commit
> :: a436bb7b806383ae0593cab53d17fc9676270cd3 kbuild: use relative path 
> more to include Makefile
> 
> :: TO: Masahiro Yamada 
> :: CC: Michal Marek 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


-- 
~Randy


Makefile:541: arch/avr32/Makefile: No such file or directory

2017-05-13 Thread kbuild test robot
Hi Hans-Christian,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2ea659a9ef488125eb46da6eb571de5eae5c43f6
commit: 26202873bb51fafdaa51be3e8de7aab9beb49f70 avr32: remove support for 
AVR32 architecture
date:   13 days ago
config: avr32-atngw100_defconfig
compiler: avr-gcc (GCC) 4.9.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 26202873bb51fafdaa51be3e8de7aab9beb49f70
make.cross ARCH=avr32  atngw100_defconfig
make.cross ARCH=avr32 

All errors (new ones prefixed by >>):

>> Makefile:541: arch/avr32/Makefile: No such file or directory
>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [atngw100_defconfig] Error 1
   make[1]: *** [atngw100_defconfig] Error 2
   make: *** [sub-make] Error 2
--
   Makefile:630: arch/avr32/Makefile: No such file or directory
>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make: *** [sub-make] Error 2
--
>> Makefile:541: arch/avr32/Makefile: No such file or directory
>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [oldconfig] Error 1
   make[1]: *** [oldconfig] Error 2
   make: *** [sub-make] Error 2
--
>> Makefile:541: arch/avr32/Makefile: No such file or directory
>> make[1]: *** No rule to make target 'arch/avr32/Makefile'.
   make[1]: Failed to remake makefile 'arch/avr32/Makefile'.
   make[2]: *** [olddefconfig] Error 1
   make[2]: Target 'oldnoconfig' not remade because of errors.
   make[1]: *** [oldnoconfig] Error 2
   make: *** [sub-make] Error 2

vim +541 Makefile

9319f4539 Masahiro Yamada 2014-04-09  525  
9319f4539 Masahiro Yamada 2014-04-09  526  __build_one_by_one:
9319f4539 Masahiro Yamada 2014-04-09  527   $(Q)set -e; \
9319f4539 Masahiro Yamada 2014-04-09  528   for i in $(MAKECMDGOALS); do \
9319f4539 Masahiro Yamada 2014-04-09  529   $(MAKE) -f 
$(srctree)/Makefile $$i; \
9319f4539 Masahiro Yamada 2014-04-09  530   done
^1da177e4 Linus Torvalds  2005-04-16  531  
^1da177e4 Linus Torvalds  2005-04-16  532  else
^1da177e4 Linus Torvalds  2005-04-16  533  ifeq ($(config-targets),1)
^1da177e4 Linus Torvalds  2005-04-16  534  # 
===
^1da177e4 Linus Torvalds  2005-04-16  535  # *config targets only - make sure 
prerequisites are updated, and descend
^1da177e4 Linus Torvalds  2005-04-16  536  # in scripts/kconfig to make the 
*config target
^1da177e4 Linus Torvalds  2005-04-16  537  
^1da177e4 Linus Torvalds  2005-04-16  538  # Read arch specific Makefile to set 
KBUILD_DEFCONFIG as needed.
^1da177e4 Linus Torvalds  2005-04-16  539  # KBUILD_DEFCONFIG may point out an 
alternative default configuration
^1da177e4 Linus Torvalds  2005-04-16  540  # used for 'make defconfig'
a436bb7b8 Masahiro Yamada 2015-03-27 @541  include arch/$(SRCARCH)/Makefile
61bee2044 Al Viro 2008-08-25  542  export KBUILD_DEFCONFIG 
KBUILD_KCONFIG
^1da177e4 Linus Torvalds  2005-04-16  543  
31110ebbe Sam Ravnborg2008-12-13  544  config: scripts_basic outputmakefile 
FORCE
31110ebbe Sam Ravnborg2008-12-13  545   $(Q)$(MAKE) 
$(build)=scripts/kconfig $@
31110ebbe Sam Ravnborg2008-12-13  546  
31110ebbe Sam Ravnborg2008-12-13  547  %config: scripts_basic 
outputmakefile FORCE
^1da177e4 Linus Torvalds  2005-04-16  548   $(Q)$(MAKE) 
$(build)=scripts/kconfig $@
^1da177e4 Linus Torvalds  2005-04-16  549  

:: The code at line 541 was first introduced by commit
:: a436bb7b806383ae0593cab53d17fc9676270cd3 kbuild: use relative path more 
to include Makefile

:: TO: Masahiro Yamada 
:: CC: Michal Marek 

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


[PATCH 0/3] PM / wakeup / ACPI: Suspend-to-idle wakeup fixes and optimization

2017-05-13 Thread Rafael J. Wysocki
Hi,

Two recent commits related to suspend-to-idle introduced a couple of issues
that need to be fixed.

In addition to that, there turns out to be a way to avoid carrying out the
"noirq" phase of device resume in order to check if wakeup triggered by an
ACPI SCI is a real one, which patch [3/3] is about.

Refer to patch changelogs for details.

Thanks,
Rafael



[PATCH 3/3] ACPI / sleep: Simplify suspend-to-idle event processing loop

2017-05-13 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle) modified the core suspend-to-idle code to filter
out spurious SCI interrupts received while suspended, but it
implemented that by resuming the system partially every time an
SCI triggers wakeup, so that the SCI handler can run (and possibly
further event handlers invoked by it can run too), which requires the
"noirq" phase of device resume to be carried out.  One drawback of
that implementation is that PCI devices are put into the full-power
state (D0) during the "noirq" resume phase and they need to be put
into low-power states again in case the wakeup event turns out to be
spurious, which may cause some unpleasant power fluctuations in the
system to happen among other things.

However, that can be avoided by using the observation that it is
generally possible to call the SCI handler directly from the ACPI
suspend-to-idle ->wake callback and the processing initiated by it
can be carried out before the "noirq" phase of device resume starts,
so if the SCI interrupt turns out to be non-wakeup, the system can
go back to sleep immediately.

Implement that idea, drop the suspend-to-idle ->sync callback added
by commit eed4d47efe95 as it is not necessary any more and simplify
the suspend-to-idle event processing loop in the core code.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/internal.h |2 ++
 drivers/acpi/osl.c  |9 +
 drivers/acpi/sleep.c|   17 -
 include/linux/suspend.h |1 -
 kernel/power/suspend.c  |   12 +---
 5 files changed, 24 insertions(+), 17 deletions(-)

Index: linux-pm/drivers/acpi/internal.h
===
--- linux-pm.orig/drivers/acpi/internal.h
+++ linux-pm/drivers/acpi/internal.h
@@ -197,6 +197,8 @@ void acpi_ec_remove_query_handler(struct
 /*--
   Suspend/Resume
   -- */
+void acpi_irq_run(void);
+
 #ifdef CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT
 extern int acpi_sleep_init(void);
 #else
Index: linux-pm/drivers/acpi/osl.c
===
--- linux-pm.orig/drivers/acpi/osl.c
+++ linux-pm/drivers/acpi/osl.c
@@ -589,6 +589,15 @@ acpi_status acpi_os_remove_interrupt_han
return AE_OK;
 }
 
+void acpi_irq_run(void)
+{
+   unsigned long flags;
+
+   local_irq_save(flags);
+   acpi_irq(acpi_gbl_FADT.sci_interrupt, NULL);
+   local_irq_restore(flags);
+}
+
 /*
  * Running in interpreter thread context, safe to sleep
  */
Index: linux-pm/drivers/acpi/sleep.c
===
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
@@ -669,18 +669,18 @@ static int acpi_freeze_prepare(void)
 
 static void acpi_freeze_wake(void)
 {
+   if (!acpi_sci_irq_valid() ||
+   irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq)))
+   return;
+
/*
 * If IRQD_WAKEUP_ARMED is not set for the SCI at this point, it means
 * that the SCI has triggered while suspended, so cancel the wakeup in
-* case it has not been a wakeup event (the GPEs will be checked later).
+* case it has not been a wakeup event and call the SCI handler directly
+* to allow it to check the event sources.
 */
-   if (acpi_sci_irq_valid() &&
-   !irqd_is_wakeup_armed(irq_get_irq_data(acpi_sci_irq)))
-   pm_system_cancel_wakeup();
-}
-
-static void acpi_freeze_sync(void)
-{
+   pm_system_cancel_wakeup();
+   acpi_irq_run();
/*
 * Process all pending events in case there are any wakeup ones.
 *
@@ -709,7 +709,6 @@ static const struct platform_freeze_ops
.begin = acpi_freeze_begin,
.prepare = acpi_freeze_prepare,
.wake = acpi_freeze_wake,
-   .sync = acpi_freeze_sync,
.restore = acpi_freeze_restore,
.end = acpi_freeze_end,
 };
Index: linux-pm/include/linux/suspend.h
===
--- linux-pm.orig/include/linux/suspend.h
+++ linux-pm/include/linux/suspend.h
@@ -190,7 +190,6 @@ struct platform_freeze_ops {
int (*begin)(void);
int (*prepare)(void);
void (*wake)(void);
-   void (*sync)(void);
void (*restore)(void);
void (*end)(void);
 };
Index: linux-pm/kernel/power/suspend.c
===
--- linux-pm.orig/kernel/power/suspend.c
+++ linux-pm/kernel/power/suspend.c
@@ -106,21 +106,17 @@ static void freeze_enter(void)
 
 static void s2idle_loop(void)
 {
-   do {
+   for (;;) {
freeze_enter();
 
if 

[PATCH 1/3] PM / wakeup: Fix up wakeup_source_report_event()

2017-05-13 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Commit 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort
transitions in progress) modified wakeup_source_report_event()
and wakeup_source_activate() to make it possible to call
pm_system_wakeup() from the latter if so indicated by the
caller of the former (via a new function argument added by that
commit), but it overlooked the fact that in some situations
wakeup_source_report_event() is called to signal a "hard" event
(ie. such that should abort a system suspend in progress) after
pm_stay_awake() has been called for the same wakeup source object,
in which case the pm_system_wakeup() will not trigger.

To work around this issue, modify wakeup_source_activate() and
wakeup_source_report_event() again so that pm_system_wakeup() is
called by the latter directly (if its last argument is true), in
which case the additional argument does not need to be passed
to wakeup_source_activate() any more, so drop it from there.

Fixes: 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort transitions in 
progress)
Reported-by: David E. Box 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/wakeup.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: linux-pm/drivers/base/power/wakeup.c
===
--- linux-pm.orig/drivers/base/power/wakeup.c
+++ linux-pm/drivers/base/power/wakeup.c
@@ -512,13 +512,12 @@ static bool wakeup_source_not_registered
 /**
  * wakup_source_activate - Mark given wakeup source as active.
  * @ws: Wakeup source to handle.
- * @hard: If set, abort suspends in progress and wake up from suspend-to-idle.
  *
  * Update the @ws' statistics and, if @ws has just been activated, notify the 
PM
  * core of the event by incrementing the counter of of wakeup events being
  * processed.
  */
-static void wakeup_source_activate(struct wakeup_source *ws, bool hard)
+static void wakeup_source_activate(struct wakeup_source *ws)
 {
unsigned int cec;
 
@@ -526,9 +525,6 @@ static void wakeup_source_activate(struc
"unregistered wakeup source\n"))
return;
 
-   if (hard)
-   pm_system_wakeup();
-
ws->active = true;
ws->active_count++;
ws->last_time = ktime_get();
@@ -554,7 +550,10 @@ static void wakeup_source_report_event(s
ws->wakeup_count++;
 
if (!ws->active)
-   wakeup_source_activate(ws, hard);
+   wakeup_source_activate(ws);
+
+   if (hard)
+   pm_system_wakeup();
 }
 
 /**



[PATCH 2/3] RTC: rtc-cmos: Fix wakeup from suspend-to-idle

2017-05-13 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle) modified the core suspend-to-idle code to filter
out spurious SCI interrupts received while suspended, which requires
ACPI event source handlers to report wakeup events in a way that
will trigger a wakeup from suspend to idle (or abort system suspends
in progress, which is equivalent).

That needs to be done in the rtc-cmos driver too, which was overlooked
by the above commit, so do that now.

Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from 
suspend-to-idle)
Reported-by: David E. Box 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/rtc/rtc-cmos.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/drivers/rtc/rtc-cmos.c
===
--- linux-pm.orig/drivers/rtc/rtc-cmos.c
+++ linux-pm/drivers/rtc/rtc-cmos.c
@@ -1085,7 +1085,7 @@ static u32 rtc_handler(void *context)
}
spin_unlock_irqrestore(_lock, flags);
 
-   pm_wakeup_event(dev, 0);
+   pm_wakeup_hard_event(dev);
acpi_clear_event(ACPI_EVENT_RTC);
acpi_disable_event(ACPI_EVENT_RTC, 0);
return ACPI_INTERRUPT_HANDLED;



xfs_iomap.c:undefined reference to `put_dax'

2017-05-13 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   cd636458904a04de2349c728323c5d2af1203bdf
commit: ef51042472f55b325fd7f2b26a2e29fd89757234 block, dax: move "select DAX" 
from BLOCK to FS_DAX
date:   5 days ago
config: ia64-bigsur_defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ef51042472f55b325fd7f2b26a2e29fd89757234
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   fs/built-in.o: In function `xfs_file_iomap_end':
>> xfs_iomap.c:(.text+0x2e3022): undefined reference to `put_dax'
   fs/built-in.o: In function `xfs_file_iomap_begin':
>> xfs_iomap.c:(.text+0x2e4502): undefined reference to `dax_get_by_host'

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


.config.gz
Description: application/gzip


Re: [PATCH linux-next] device-dax: fix BLOCK dependency

2017-05-13 Thread Dan Williams
On Sat, May 13, 2017 at 11:59 AM, Fabian Frederick  wrote:
> commit ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")
> uses get_start_sect() which requires CONFIG_BLOCK
>
> make allnoconfig + dax gives the following:
>
> drivers/dax/super.c: In function 'bdev_dax_pgoff':
> drivers/dax/super.c:50:26: error: implicit declaration of function
> 'get_start_sect' [-Werror=implicit-function-declaration]
>

Ah, sorry for this breakage, I guess this is a config that kbuild does
not attempt. I'll fix this up by not compiling the block-related
helpers in the BLOCK=n case.


Re: [PATCH 08/10] efi/x86: Move EFI BGRT init code to early init code

2017-05-13 Thread Sabrina Dubroca
2017-01-31, 13:21:40 +, Ard Biesheuvel wrote:
> From: Dave Young 
> 
> Before invoking the arch specific handler, efi_mem_reserve() reserves
> the given memory region through memblock.
> 
> efi_bgrt_init() will call efi_mem_reserve() after mm_init(), at which
> time memblock is dead and should not be used anymore.
> 
> The EFI BGRT code depends on ACPI initialization to get the BGRT ACPI
> table, so move parsing of the BGRT table to ACPI early boot code to
> ensure that efi_mem_reserve() in EFI BGRT code still use memblock safely.
> 
> Signed-off-by: Dave Young 
> Cc: Matt Fleming 
> Cc: "Rafael J. Wysocki" 
> Cc: Len Brown 
> Cc: linux-a...@vger.kernel.org
> Tested-by: Bhupesh Sharma 
> Signed-off-by: Ard Biesheuvel 

I have a box that panics in early boot after this patch. The kernel
config is based on a Fedora 25 kernel + localmodconfig.

BUG: unable to handle kernel paging request at ff240001
IP: efi_bgrt_init+0xdc/0x134
PGD 1ac0c067
PUD 1ac0e067
PMD 1aee9067
PTE 938070180163

Oops: 0009 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc5-00116-g7b0a911 #19
Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.02 
05/03/2012
task: 9fc10500 task.stack: 9fc0
RIP: 0010:efi_bgrt_init+0xdc/0x134
RSP: :9fc03d58 EFLAGS: 00010082
RAX: ff240001 RBX:  RCX: 138070180006
RDX: 8163 RSI: 938070180163 RDI: 05be
RBP: 9fc03d70 R08: 138070181000 R09: 0002
R10: 0002d000 R11: 98a3dedd2fc6 R12: 9f9f22b6
R13: 9ff49480 R14: 0010 R15: 
FS:  () GS:9fd2() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: ff240001 CR3: 1ac09000 CR4: 000406b0
Call Trace:
 ? acpi_parse_ioapic+0x98/0x98
 acpi_parse_bgrt+0x9/0xd
 acpi_table_parse+0x7a/0xa9
 acpi_boot_init+0x3c7/0x4f9
 ? acpi_parse_x2apic+0x74/0x74
 ? acpi_parse_x2apic_nmi+0x46/0x46
 setup_arch+0xb4b/0xc6f
 ? printk+0x52/0x6e
 start_kernel+0xb2/0x47b
 ? early_idt_handler_array+0x120/0x120
 x86_64_start_reservations+0x24/0x26
 x86_64_start_kernel+0xf7/0x11a
 start_cpu+0x14/0x14
Code: 48 c7 c7 10 16 a0 9f e8 4e 94 40 ff eb 62 be 06 00 00 00 e8 f9 ff 00 00 
48 85 c0 75 0e 48 c7 c7 40 16 a0 9f e8 31 94 40 ff eb 45 <66> 44 8b 20 be 06 00 
00 00 48 89 c7 8b 58 02 e8 87 00 01 00 66
RIP: efi_bgrt_init+0xdc/0x134 RSP: 9fc03d58
CR2: ff240001
---[ end trace f68728a0d3053b52 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!


That code is:


All code

   0:   48 c7 c7 10 16 a0 9fmov$0x9fa01610,%rdi
   7:   e8 4e 94 40 ff  callq  0xff40945a
   c:   eb 62   jmp0x70
   e:   be 06 00 00 00  mov$0x6,%esi
  13:   e8 f9 ff 00 00  callq  0x10011
  18:   48 85 c0test   %rax,%rax
  1b:   75 0e   jne0x2b
  1d:   48 c7 c7 40 16 a0 9fmov$0x9fa01640,%rdi
  24:   e8 31 94 40 ff  callq  0xff40945a
  29:   eb 45   jmp0x70
  2b:*  66 44 8b 20 mov(%rax),%r12w <-- trapping 
instruction
  2f:   be 06 00 00 00  mov$0x6,%esi
  34:   48 89 c7mov%rax,%rdi
  37:   8b 58 02mov0x2(%rax),%ebx
  3a:   e8 87 00 01 00  callq  0x100c6
  3f:   66  data16

Code starting with the faulting instruction
===
   0:   66 44 8b 20 mov(%rax),%r12w
   4:   be 06 00 00 00  mov$0x6,%esi
   9:   48 89 c7mov%rax,%rdi
   c:   8b 58 02mov0x2(%rax),%ebx
   f:   e8 87 00 01 00  callq  0x1009b
  14:   66  data16


which is just after the early_memremap() call.

I enabled early_ioremap_debug and the last warning had:

__early_ioremap(138070181000, 1000) [1] => 0001 + ff24



Rest of the log, in case there's anything useful in there:


Linux version 4.10.0-rc5-00116-g7b0a911 (root@netdev4) (gcc version 6.3.1 
20161221 (Red Hat 6.3.1-1) (GCC) ) #19 SMP Sat May 13 23:16:09 CEST 2017
Command line: BOOT_IMAGE=/vmlinuz-4.10.0-rc5-00116-g7b0a911 
root=UUID=3b849e12-46bd-4406-a2ec-f44238a55d56 ro console=ttyS0,115200 
earlyprintk=serial,0x03F8,115200
x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev
On 5/13/17 3:15 PM, Valentin Vidic wrote:
> Try booting without 'hpet=force,verbose clocksource=hpet' and it should
> select xen by default:

Nope. Well, not quite ...

With both 

'hpet=force,verbose clocksource=hpet'

removed, I end up with

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

But with 

clocksource=xen

*explicitly* added

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc xen
cat /sys/devices/system/clocksource/clocksource0/current_clocksourcexen
xen

and in *console*, NOT dmesg, output,

grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB  1072009 
AMI.5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed0
(XEN) [VT-D] MSI HPET: :f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
[0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 00
[0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
[0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 00
[0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
[8.515245] hpet_acpi_add: no address or irqs in _CRS
[8.515245] hpet_acpi_add: no address or irqs in _CRS
(XEN) [2017-05-13 23:04:27] HVM1 save: HPET



and

dmesg | grep -i clocksource | grep -v line:
[0.00] clocksource: refined-jiffies: mask: 0x 
max_cycles: 0x, max_idle_ns: 7645519600211568 ns
[0.004000] clocksource: xen: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.375709] clocksource: jiffies: mask: 0x 
max_cycles: 0x, max_idle_ns: 764504178510 ns
[4.656634] clocksource: Switched to clocksource xen
[8.912897] clocksource: tsc: mask: 0x 
max_cycles: 0x2c94dffea94, max_idle_ns: 440795361700 ns

jiffies, now? hm. no idea where that came from. and why the 'tsc' ?

So I'm still unclear -- is this^ now, correctly "all" using MSI/HPET?


[PATCH 2/9] staging: sm750fb: unifying macro definitions

2017-05-13 Thread Matej Dujava
This patch adds tabs into macro definitions so all rhs are on same column.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_display.h | 74 
 drivers/staging/sm750fb/ddk750_hwi2c.c   |  4 +-
 drivers/staging/sm750fb/sm750.h  |  6 +--
 3 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index 609bf74..6f639d7 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -6,8 +6,8 @@
  * 8[29:28]
  */
 
-#define PNL_2_OFFSET 0
-#define PNL_2_MASK (3 << PNL_2_OFFSET)
+#define PNL_2_OFFSET   0
+#define PNL_2_MASK (3 << PNL_2_OFFSET)
 #define PNL_2_USAGE(PNL_2_MASK << 16)
 #define PNL_2_PRI  ((0 << PNL_2_OFFSET) | PNL_2_USAGE)
 #define PNL_2_SEC  ((2 << PNL_2_OFFSET) | PNL_2_USAGE)
@@ -17,72 +17,72 @@
  * 1: 8[8] & 8[2] on
  * 0: both off
  */
-#define PRI_TP_OFFSET 4
-#define PRI_TP_MASK BIT(PRI_TP_OFFSET)
-#define PRI_TP_USAGE (PRI_TP_MASK << 16)
-#define PRI_TP_ON ((0x1 << PRI_TP_OFFSET) | PRI_TP_USAGE)
-#define PRI_TP_OFF ((0x0 << PRI_TP_OFFSET) | PRI_TP_USAGE)
+#define PRI_TP_OFFSET  4
+#define PRI_TP_MASKBIT(PRI_TP_OFFSET)
+#define PRI_TP_USAGE   (PRI_TP_MASK << 16)
+#define PRI_TP_ON  ((0x1 << PRI_TP_OFFSET) | PRI_TP_USAGE)
+#define PRI_TP_OFF ((0x0 << PRI_TP_OFFSET) | PRI_TP_USAGE)
 
 /*
  * panel sequency status
  * 8[27:24]
  */
-#define PNL_SEQ_OFFSET 6
-#define PNL_SEQ_MASK BIT(PNL_SEQ_OFFSET)
-#define PNL_SEQ_USAGE (PNL_SEQ_MASK << 16)
-#define PNL_SEQ_ON (BIT(PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
-#define PNL_SEQ_OFF ((0 << PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
+#define PNL_SEQ_OFFSET 6
+#define PNL_SEQ_MASK   BIT(PNL_SEQ_OFFSET)
+#define PNL_SEQ_USAGE  (PNL_SEQ_MASK << 16)
+#define PNL_SEQ_ON (BIT(PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
+#define PNL_SEQ_OFF((0 << PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
 
 /*
  * dual digital output
  * 8[19]
  */
-#define DUAL_TFT_OFFSET 8
-#define DUAL_TFT_MASK BIT(DUAL_TFT_OFFSET)
-#define DUAL_TFT_USAGE (DUAL_TFT_MASK << 16)
-#define DUAL_TFT_ON (BIT(DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
-#define DUAL_TFT_OFF ((0 << DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
+#define DUAL_TFT_OFFSET8
+#define DUAL_TFT_MASK  BIT(DUAL_TFT_OFFSET)
+#define DUAL_TFT_USAGE (DUAL_TFT_MASK << 16)
+#define DUAL_TFT_ON(BIT(DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
+#define DUAL_TFT_OFF   ((0 << DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
 
 /*
  * secondary timing & plane enable bit
  * 1:80200[8] & 80200[2] on
  * 0: both off
  */
-#define SEC_TP_OFFSET 5
-#define SEC_TP_MASK BIT(SEC_TP_OFFSET)
-#define SEC_TP_USAGE (SEC_TP_MASK << 16)
-#define SEC_TP_ON  ((0x1 << SEC_TP_OFFSET) | SEC_TP_USAGE)
-#define SEC_TP_OFF ((0x0 << SEC_TP_OFFSET) | SEC_TP_USAGE)
+#define SEC_TP_OFFSET  5
+#define SEC_TP_MASKBIT(SEC_TP_OFFSET)
+#define SEC_TP_USAGE   (SEC_TP_MASK << 16)
+#define SEC_TP_ON  ((0x1 << SEC_TP_OFFSET) | SEC_TP_USAGE)
+#define SEC_TP_OFF ((0x0 << SEC_TP_OFFSET) | SEC_TP_USAGE)
 
 /*
  * crt path select
  * 80200[19:18]
  */
-#define CRT_2_OFFSET 2
-#define CRT_2_MASK (3 << CRT_2_OFFSET)
-#define CRT_2_USAGE (CRT_2_MASK << 16)
-#define CRT_2_PRI ((0x0 << CRT_2_OFFSET) | CRT_2_USAGE)
-#define CRT_2_SEC ((0x2 << CRT_2_OFFSET) | CRT_2_USAGE)
+#define CRT_2_OFFSET   2
+#define CRT_2_MASK (3 << CRT_2_OFFSET)
+#define CRT_2_USAGE(CRT_2_MASK << 16)
+#define CRT_2_PRI  ((0x0 << CRT_2_OFFSET) | CRT_2_USAGE)
+#define CRT_2_SEC  ((0x2 << CRT_2_OFFSET) | CRT_2_USAGE)
 
 /*
  * DAC affect both DVI and DSUB
  * 4[20]
  */
-#define DAC_OFFSET 7
-#define DAC_MASK BIT(DAC_OFFSET)
-#define DAC_USAGE (DAC_MASK << 16)
-#define DAC_ON ((0x0 << DAC_OFFSET) | DAC_USAGE)
-#define DAC_OFF ((0x1 << DAC_OFFSET) | DAC_USAGE)
+#define DAC_OFFSET 7
+#define DAC_MASK   BIT(DAC_OFFSET)
+#define DAC_USAGE  (DAC_MASK << 16)
+#define DAC_ON ((0x0 << DAC_OFFSET) | DAC_USAGE)
+#define DAC_OFF((0x1 << DAC_OFFSET) | DAC_USAGE)
 
 /*
  * DPMS only affect D-SUB head
  * 0[31:30]
  */
-#define DPMS_OFFSET 9
-#define DPMS_MASK (3 << DPMS_OFFSET)
-#define DPMS_USAGE (DPMS_MASK << 16)
-#define DPMS_OFF ((3 << DPMS_OFFSET) | DPMS_USAGE)
-#define DPMS_ON ((0 << DPMS_OFFSET) | DPMS_USAGE)
+#define DPMS_OFFSET9
+#define DPMS_MASK  (3 << DPMS_OFFSET)
+#define DPMS_USAGE (DPMS_MASK << 16)
+#define DPMS_OFF   ((3 << DPMS_OFFSET) | DPMS_USAGE)
+#define DPMS_ON((0 << DPMS_OFFSET) | DPMS_USAGE)
 
 /*
  * LCD1 means panel path TFT1  & panel path DVI (so enable DAC)
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.c 
b/drivers/staging/sm750fb/ddk750_hwi2c.c
index ec556a9..ccf49ef 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.c
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.c
@@ -5,8 +5,8 @@
 #include "ddk750_hwi2c.h"
 #include "ddk750_power.h"
 
-#define MAX_HWI2C_FIFO   

[PATCH 3/9] staging: sm750fb: reordering of macro definitions

2017-05-13 Thread Matej Dujava
This patch reorder definition of macros so all macros are in same order.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_display.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index 6f639d7..cef7f46 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -81,8 +81,8 @@
 #define DPMS_OFFSET9
 #define DPMS_MASK  (3 << DPMS_OFFSET)
 #define DPMS_USAGE (DPMS_MASK << 16)
-#define DPMS_OFF   ((3 << DPMS_OFFSET) | DPMS_USAGE)
 #define DPMS_ON((0 << DPMS_OFFSET) | DPMS_USAGE)
+#define DPMS_OFF   ((3 << DPMS_OFFSET) | DPMS_USAGE)
 
 /*
  * LCD1 means panel path TFT1  & panel path DVI (so enable DAC)
-- 
1.8.3.1



[PATCH 1/9] staging: sm750fb: fix length of lines

2017-05-13 Thread Matej Dujava
This patch breaks lines that are longer than 80 characters and joins
together those, that are too short and can be placed at one.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_chip.c   |  7 +++--
 drivers/staging/sm750fb/ddk750_dvi.c| 35 +--
 drivers/staging/sm750fb/ddk750_dvi.h| 43 ++---
 drivers/staging/sm750fb/ddk750_hwi2c.c  | 33 --
 drivers/staging/sm750fb/ddk750_sii164.c | 49 ++---
 drivers/staging/sm750fb/ddk750_sii164.h | 22 +++
 drivers/staging/sm750fb/ddk750_swi2c.c  | 21 --
 drivers/staging/sm750fb/ddk750_swi2c.h  | 18 
 drivers/staging/sm750fb/sm750.c | 26 -
 drivers/staging/sm750fb/sm750_accel.c   | 15 +-
 drivers/staging/sm750fb/sm750_cursor.c  | 17 +---
 11 files changed, 125 insertions(+), 161 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 5e4bfb6..944dd25 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -175,7 +175,7 @@ static void set_master_clock(unsigned int frequency)
}
 
sm750_set_current_gate(reg);
-   }
+   }
 }
 
 unsigned int ddk750_get_vm_size(void)
@@ -224,7 +224,7 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
sm750_set_current_gate(reg);
 
if (sm750_get_chip_type() != SM750LE) {
-   /*  set panel pll and graphic mode via mmio_88 */
+   /* set panel pll and graphic mode via mmio_88 */
reg = peek32(VGA_CONFIGURATION);
reg |= (VGA_CONFIGURATION_PLL | VGA_CONFIGURATION_MODE);
poke32(VGA_CONFIGURATION, reg);
@@ -309,7 +309,8 @@ int ddk750_init_hw(struct initchip_param *pInitParam)
  * M = {1,...,255}
  * N = {2,...,15}
  */
-unsigned int sm750_calc_pll_value(unsigned int request_orig, struct pll_value 
*pll)
+unsigned int sm750_calc_pll_value(unsigned int request_orig,
+ struct pll_value *pll)
 {
/*
 * as sm750 register definition,
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c 
b/drivers/staging/sm750fb/ddk750_dvi.c
index 171ae06..87a199d 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -29,26 +29,31 @@
 #endif
 };
 
-int dviInit(
-   unsigned char edgeSelect,
-   unsigned char busSelect,
-   unsigned char dualEdgeClkSelect,
-   unsigned char hsyncEnable,
-   unsigned char vsyncEnable,
-   unsigned char deskewEnable,
-   unsigned char deskewSetting,
-   unsigned char continuousSyncEnable,
-   unsigned char pllFilterEnable,
-   unsigned char pllFilterValue
-   )
+int dviInit(unsigned char edgeSelect,
+   unsigned char busSelect,
+   unsigned char dualEdgeClkSelect,
+   unsigned char hsyncEnable,
+   unsigned char vsyncEnable,
+   unsigned char deskewEnable,
+   unsigned char deskewSetting,
+   unsigned char continuousSyncEnable,
+   unsigned char pllFilterEnable,
+   unsigned char pllFilterValue)
 {
dvi_ctrl_device_t *pCurrentDviCtrl;
 
pCurrentDviCtrl = g_dcftSupportedDviController;
if (pCurrentDviCtrl->pfnInit) {
-   return pCurrentDviCtrl->pfnInit(edgeSelect, busSelect, 
dualEdgeClkSelect, hsyncEnable,
-   vsyncEnable, deskewEnable, 
deskewSetting, continuousSyncEnable,
-   pllFilterEnable, 
pllFilterValue);
+   return pCurrentDviCtrl->pfnInit(edgeSelect,
+   busSelect,
+   dualEdgeClkSelect,
+   hsyncEnable,
+   vsyncEnable,
+   deskewEnable,
+   deskewSetting,
+   continuousSyncEnable,
+   pllFilterEnable,
+   pllFilterValue);
}
return -1; /* error */
 }
diff --git a/drivers/staging/sm750fb/ddk750_dvi.h 
b/drivers/staging/sm750fb/ddk750_dvi.h
index 677939c..4a83945 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.h
+++ b/drivers/staging/sm750fb/ddk750_dvi.h
@@ -3,17 +3,16 @@
 
 /* dvi chip stuffs structros */
 
-typedef long (*PFN_DVICTRL_INIT)(
-   unsigned char edgeSelect,
-   unsigned char busSelect,
-   unsigned char dualEdgeClkSelect,
-   unsigned char hsyncEnable,
-   unsigned char vsyncEnable,
-   unsigned char deskewEnable,
-   unsigned char deskewSetting,
-   unsigned char continuousSyncEnable,
-  

[PATCH 6/9] staging: sm750fb: Remove typedef from "typedef enum _clock_type_t"

2017-05-13 Thread Matej Dujava
This patch removes typedefs from enum and renames it from "typedef enum
_clock_type_t" to "enum clock_type" as per kernel coding standards.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_chip.h | 8 
 drivers/staging/sm750fb/ddk750_mode.c | 2 +-
 drivers/staging/sm750fb/ddk750_mode.h | 2 +-
 drivers/staging/sm750fb/sm750_hw.c| 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.h 
b/drivers/staging/sm750fb/ddk750_chip.h
index f2eee2b..e5cb436 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -31,17 +31,17 @@ enum logical_chip_type {
 };
 
 
-typedef enum _clock_type_t {
+enum clock_type {
MXCLK_PLL,
PRIMARY_PLL,
SECONDARY_PLL,
VGA0_PLL,
VGA1_PLL,
-}
-clock_type_t;
+};
+
 
 struct pll_value {
-   clock_type_t clockType;
+   enum clock_type clockType;
unsigned long inputFreq; /* Input clock frequency to the PLL */
 
/* Use this when clockType = PANEL_PLL */
diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index bb673e1..24d3447 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -205,7 +205,7 @@ static int programModeRegisters(struct mode_parameter 
*pModeParam,
return ret;
 }
 
-int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock)
+int ddk750_setModeTiming(struct mode_parameter *parm, enum clock_type clock)
 {
struct pll_value pll;
unsigned int uiActualPixelClk;
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index d5eae36..704dbfd 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -32,5 +32,5 @@ struct mode_parameter {
enum spolarity clock_phase_polarity;
 };
 
-int ddk750_setModeTiming(struct mode_parameter *parm, clock_type_t clock);
+int ddk750_setModeTiming(struct mode_parameter *parm, enum clock_type clock);
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index baf1bbd..3cdc4ae 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -253,7 +253,7 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc *crtc,
int ret, fmt;
u32 reg;
struct mode_parameter modparm;
-   clock_type_t clock;
+   enum clock_type clock;
struct sm750_dev *sm750_dev;
struct lynxfb_par *par;
 
-- 
1.8.3.1



[PATCH 0/9] staging: sm750fb: cleaning code

2017-05-13 Thread Matej Dujava
Folowing patches are cleaning some warnings and checkups from checkpatch.pl

Matej Dujava (9):
  staging: sm750fb: fix length of lines
  staging: sm750fb: unifying macro definitions
  staging: sm750fb: reordering of macro definitions
  staging: sm750fb: removing unnecessary binary operations
  staging: sm750fb: Remove typedef from "typedef enum
_logical_chip_type_t"
  staging: sm750fb: Remove typedef from "typedef enum _clock_type_t"
  staging: sm750fb: Remove typedef from "typedef enum _disp_output_t"
  staging: sm750fb: Remove typedef from "typedef enum _DPMS_t"
  staging: sm750fb: Remove typedef from "typedef enum
_sii164_hot_plug_mode_t"

 drivers/staging/sm750fb/ddk750_chip.c| 11 ++--
 drivers/staging/sm750fb/ddk750_chip.h| 16 +++---
 drivers/staging/sm750fb/ddk750_display.c |  2 +-
 drivers/staging/sm750fb/ddk750_display.h | 86 
 drivers/staging/sm750fb/ddk750_dvi.c | 35 +++--
 drivers/staging/sm750fb/ddk750_dvi.h | 43 
 drivers/staging/sm750fb/ddk750_hwi2c.c   | 37 +-
 drivers/staging/sm750fb/ddk750_mode.c|  2 +-
 drivers/staging/sm750fb/ddk750_mode.h|  2 +-
 drivers/staging/sm750fb/ddk750_power.c   |  2 +-
 drivers/staging/sm750fb/ddk750_power.h   |  7 ++-
 drivers/staging/sm750fb/ddk750_sii164.c  | 49 --
 drivers/staging/sm750fb/ddk750_sii164.h  | 26 +-
 drivers/staging/sm750fb/ddk750_swi2c.c   | 21 +++-
 drivers/staging/sm750fb/ddk750_swi2c.h   | 18 ++-
 drivers/staging/sm750fb/sm750.c  | 26 +-
 drivers/staging/sm750fb/sm750.h  |  6 +--
 drivers/staging/sm750fb/sm750_accel.c| 15 +++---
 drivers/staging/sm750fb/sm750_cursor.c   | 17 +++
 drivers/staging/sm750fb/sm750_hw.c   |  4 +-
 20 files changed, 194 insertions(+), 231 deletions(-)

-- 
1.8.3.1



[PATCH 4/9] staging: sm750fb: removing unnecessary binary operations

2017-05-13 Thread Matej Dujava
This patch remove unnecessary operation (eg. ``X | (0x0 << Y)`` to ``X``).

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_display.h | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index cef7f46..f9e1614 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -9,8 +9,8 @@
 #define PNL_2_OFFSET   0
 #define PNL_2_MASK (3 << PNL_2_OFFSET)
 #define PNL_2_USAGE(PNL_2_MASK << 16)
-#define PNL_2_PRI  ((0 << PNL_2_OFFSET) | PNL_2_USAGE)
-#define PNL_2_SEC  ((2 << PNL_2_OFFSET) | PNL_2_USAGE)
+#define PNL_2_PRI  (PNL_2_USAGE)
+#define PNL_2_SEC  (PNL_2_USAGE | (2 << PNL_2_OFFSET))
 
 /*
  * primary timing & plane enable bit
@@ -20,8 +20,8 @@
 #define PRI_TP_OFFSET  4
 #define PRI_TP_MASKBIT(PRI_TP_OFFSET)
 #define PRI_TP_USAGE   (PRI_TP_MASK << 16)
-#define PRI_TP_ON  ((0x1 << PRI_TP_OFFSET) | PRI_TP_USAGE)
-#define PRI_TP_OFF ((0x0 << PRI_TP_OFFSET) | PRI_TP_USAGE)
+#define PRI_TP_ON  (PRI_TP_USAGE | BIT(PRI_TP_OFFSET))
+#define PRI_TP_OFF (PRI_TP_USAGE)
 
 /*
  * panel sequency status
@@ -30,8 +30,8 @@
 #define PNL_SEQ_OFFSET 6
 #define PNL_SEQ_MASK   BIT(PNL_SEQ_OFFSET)
 #define PNL_SEQ_USAGE  (PNL_SEQ_MASK << 16)
-#define PNL_SEQ_ON (BIT(PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
-#define PNL_SEQ_OFF((0 << PNL_SEQ_OFFSET) | PNL_SEQ_USAGE)
+#define PNL_SEQ_ON (PNL_SEQ_USAGE | BIT(PNL_SEQ_OFFSET))
+#define PNL_SEQ_OFF(PNL_SEQ_USAGE)
 
 /*
  * dual digital output
@@ -40,8 +40,8 @@
 #define DUAL_TFT_OFFSET8
 #define DUAL_TFT_MASK  BIT(DUAL_TFT_OFFSET)
 #define DUAL_TFT_USAGE (DUAL_TFT_MASK << 16)
-#define DUAL_TFT_ON(BIT(DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
-#define DUAL_TFT_OFF   ((0 << DUAL_TFT_OFFSET) | DUAL_TFT_USAGE)
+#define DUAL_TFT_ON(DUAL_TFT_USAGE | BIT(DUAL_TFT_OFFSET))
+#define DUAL_TFT_OFF   (DUAL_TFT_USAGE)
 
 /*
  * secondary timing & plane enable bit
@@ -51,8 +51,8 @@
 #define SEC_TP_OFFSET  5
 #define SEC_TP_MASKBIT(SEC_TP_OFFSET)
 #define SEC_TP_USAGE   (SEC_TP_MASK << 16)
-#define SEC_TP_ON  ((0x1 << SEC_TP_OFFSET) | SEC_TP_USAGE)
-#define SEC_TP_OFF ((0x0 << SEC_TP_OFFSET) | SEC_TP_USAGE)
+#define SEC_TP_ON  (SEC_TP_USAGE | BIT(SEC_TP_OFFSET))
+#define SEC_TP_OFF (SEC_TP_USAGE)
 
 /*
  * crt path select
@@ -61,8 +61,8 @@
 #define CRT_2_OFFSET   2
 #define CRT_2_MASK (3 << CRT_2_OFFSET)
 #define CRT_2_USAGE(CRT_2_MASK << 16)
-#define CRT_2_PRI  ((0x0 << CRT_2_OFFSET) | CRT_2_USAGE)
-#define CRT_2_SEC  ((0x2 << CRT_2_OFFSET) | CRT_2_USAGE)
+#define CRT_2_PRI  (CRT_2_USAGE)
+#define CRT_2_SEC  (CRT_2_USAGE | (0x2 << CRT_2_OFFSET))
 
 /*
  * DAC affect both DVI and DSUB
@@ -71,8 +71,8 @@
 #define DAC_OFFSET 7
 #define DAC_MASK   BIT(DAC_OFFSET)
 #define DAC_USAGE  (DAC_MASK << 16)
-#define DAC_ON ((0x0 << DAC_OFFSET) | DAC_USAGE)
-#define DAC_OFF((0x1 << DAC_OFFSET) | DAC_USAGE)
+#define DAC_ON (DAC_USAGE)
+#define DAC_OFF(DAC_USAGE | BIT(DAC_OFFSET))
 
 /*
  * DPMS only affect D-SUB head
@@ -81,8 +81,8 @@
 #define DPMS_OFFSET9
 #define DPMS_MASK  (3 << DPMS_OFFSET)
 #define DPMS_USAGE (DPMS_MASK << 16)
-#define DPMS_ON((0 << DPMS_OFFSET) | DPMS_USAGE)
-#define DPMS_OFF   ((3 << DPMS_OFFSET) | DPMS_USAGE)
+#define DPMS_ON(DPMS_USAGE)
+#define DPMS_OFF   (DPMS_USAGE | (0x3 << DPMS_OFFSET))
 
 /*
  * LCD1 means panel path TFT1  & panel path DVI (so enable DAC)
-- 
1.8.3.1



[PATCH 7/9] staging: sm750fb: Remove typedef from "typedef enum _disp_output_t"

2017-05-13 Thread Matej Dujava
This patch removes typedefs from enum and renames it from "typedef enum
_disp_output_t" to "enum disp_output" as per kernel coding standards.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_display.c | 2 +-
 drivers/staging/sm750fb/ddk750_display.h | 8 
 drivers/staging/sm750fb/sm750_hw.c   | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.c 
b/drivers/staging/sm750fb/ddk750_display.c
index 9b116ed6..13b91c3 100644
--- a/drivers/staging/sm750fb/ddk750_display.c
+++ b/drivers/staging/sm750fb/ddk750_display.c
@@ -110,7 +110,7 @@ static void swPanelPowerSequence(int disp, int delay)
primary_wait_vertical_sync(delay);
 }
 
-void ddk750_setLogicalDispOut(disp_output_t output)
+void ddk750_setLogicalDispOut(enum disp_output output)
 {
unsigned int reg;
 
diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index f9e1614..8b0830f 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -88,7 +88,7 @@
  * LCD1 means panel path TFT1  & panel path DVI (so enable DAC)
  * CRT means crt path DSUB
  */
-typedef enum _disp_output_t {
+enum disp_output {
do_LCD1_PRI = PNL_2_PRI | PRI_TP_ON | PNL_SEQ_ON | DAC_ON,
do_LCD1_SEC = PNL_2_SEC | SEC_TP_ON | PNL_SEQ_ON | DAC_ON,
do_LCD2_PRI = CRT_2_PRI | PRI_TP_ON | DUAL_TFT_ON,
@@ -99,9 +99,9 @@
 */
do_CRT_PRI = CRT_2_PRI | PRI_TP_ON | DPMS_ON | DAC_ON,
do_CRT_SEC = CRT_2_SEC | SEC_TP_ON | DPMS_ON | DAC_ON,
-}
-disp_output_t;
+};
 
-void ddk750_setLogicalDispOut(disp_output_t output);
+
+void ddk750_setLogicalDispOut(enum disp_output output);
 
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index 3cdc4ae..f7d1e67 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -184,7 +184,7 @@ int hw_sm750_output_setMode(struct lynxfb_output *output,
struct fb_fix_screeninfo *fix)
 {
int ret;
-   disp_output_t dispSet;
+   enum disp_output dispSet;
int channel;
 
ret = 0;
-- 
1.8.3.1



[PATCH 9/9] staging: sm750fb: Remove typedef from "typedef enum _sii164_hot_plug_mode_t"

2017-05-13 Thread Matej Dujava
This patch removes typedefs from enum and renames it from "typedef enum
_sii164_hot_plug_mode_t" to "enum sii164_hot_plug_mode" as per kernel
coding standards.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_sii164.c | 2 +-
 drivers/staging/sm750fb/ddk750_sii164.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_sii164.c 
b/drivers/staging/sm750fb/ddk750_sii164.c
index 0431833..f7bf84e8 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -296,7 +296,7 @@ void sii164SetPower(unsigned char powerUp)
  *  sii164SelectHotPlugDetectionMode
  *  This function selects the mode of the hot plug detection.
  */
-static void sii164SelectHotPlugDetectionMode(sii164_hot_plug_mode_t 
hotPlugMode)
+static void sii164SelectHotPlugDetectionMode(enum sii164_hot_plug_mode 
hotPlugMode)
 {
unsigned char detectReg;
 
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h 
b/drivers/staging/sm750fb/ddk750_sii164.h
index 6968cf5..e06ba72 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -4,12 +4,12 @@
 #define USE_DVICHIP
 
 /* Hot Plug detection mode structure */
-typedef enum _sii164_hot_plug_mode_t {
+enum sii164_hot_plug_mode {
SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit 
(always high). */
SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt 
bit. */
SII164_HOTPLUG_USE_RSEN,/* Use Receiver Sense detect bit. */
SII164_HOTPLUG_USE_HTPLG/* Use Hot Plug detect bit. */
-} sii164_hot_plug_mode_t;
+};
 
 
 /* Silicon Image SiI164 chip prototype */
-- 
1.8.3.1



[PATCH 8/9] staging: sm750fb: Remove typedef from "typedef enum _DPMS_t"

2017-05-13 Thread Matej Dujava
This patch removes typedefs from enum and renames it from
"typedef enum _DPMS_t" to "enum DPMS" as per kernel coding standards.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_power.c | 2 +-
 drivers/staging/sm750fb/ddk750_power.h | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_power.c 
b/drivers/staging/sm750fb/ddk750_power.c
index 222ae1a..bc91e73 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -2,7 +2,7 @@
 #include "ddk750_reg.h"
 #include "ddk750_power.h"
 
-void ddk750_set_dpms(DPMS_t state)
+void ddk750_set_dpms(enum DPMS state)
 {
unsigned int value;
 
diff --git a/drivers/staging/sm750fb/ddk750_power.h 
b/drivers/staging/sm750fb/ddk750_power.h
index 44c4fc5..6764e53 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -1,20 +1,19 @@
 #ifndef DDK750_POWER_H__
 #define DDK750_POWER_H__
 
-typedef enum _DPMS_t {
+enum DPMS {
crtDPMS_ON = 0x0,
crtDPMS_STANDBY = 0x1,
crtDPMS_SUSPEND = 0x2,
crtDPMS_OFF = 0x3,
-}
-DPMS_t;
+};
 
 #define setDAC(off) {  \
poke32(MISC_CTRL,   \
   (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
 }
 
-void ddk750_set_dpms(DPMS_t state);
+void ddk750_set_dpms(enum DPMS state);
 void sm750_set_power_mode(unsigned int powerMode);
 void sm750_set_current_gate(unsigned int gate);
 
-- 
1.8.3.1



[PATCH 5/9] staging: sm750fb: Remove typedef from "typedef enum _logical_chip_type_t"

2017-05-13 Thread Matej Dujava
This patch removes typedefs from enum and renames it from "typedef enum
_logical_chip_type_t" to "enum logical_chip_type" as per kernel coding
standards.

Signed-off-by: Matej Dujava 
---
 drivers/staging/sm750fb/ddk750_chip.c | 4 ++--
 drivers/staging/sm750fb/ddk750_chip.h | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index 944dd25..1d62c2d 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -7,9 +7,9 @@
 
 #define MHz(x) ((x) * 100)
 
-static logical_chip_type_t chip;
+static enum logical_chip_type chip;
 
-logical_chip_type_t sm750_get_chip_type(void)
+enum logical_chip_type sm750_get_chip_type(void)
 {
return chip;
 }
diff --git a/drivers/staging/sm750fb/ddk750_chip.h 
b/drivers/staging/sm750fb/ddk750_chip.h
index 2c7a9b9..f2eee2b 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -23,13 +23,13 @@ static inline void poke32(u32 data, u32 addr)
 }
 
 /* This is all the chips recognized by this library */
-typedef enum _logical_chip_type_t {
+enum logical_chip_type {
SM_UNKNOWN,
SM718,
SM750,
SM750LE,
-}
-logical_chip_type_t;
+};
+
 
 typedef enum _clock_type_t {
MXCLK_PLL,
@@ -93,7 +93,7 @@ struct initchip_param {
/* More initialization parameter can be added if needed */
 };
 
-logical_chip_type_t sm750_get_chip_type(void);
+enum logical_chip_type sm750_get_chip_type(void);
 void sm750_set_chip_type(unsigned short devId, u8 revId);
 unsigned int sm750_calc_pll_value(unsigned int request, struct  pll_value 
*pll);
 unsigned int sm750_format_pll_reg(struct pll_value *pPLL);
-- 
1.8.3.1



[PATCH] drm/sti:fix spelling mistake: "compoment" -> "component"

2017-05-13 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in DRM_ERROR message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/sti/sti_compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 11d4e885893a..6e4bf68262db 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -129,7 +129,7 @@ static int sti_compositor_bind(struct device *dev,
}
break;
default:
-   DRM_ERROR("Unknown subdev compoment type\n");
+   DRM_ERROR("Unknown subdev component type\n");
return 1;
}
 
-- 
2.11.0



[PATCH] rtlwifi: rtl8723ae:fix spelling mistake: "Coexistance" -> "Coexistence"

2017-05-13 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in RT_TRACE text

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
index 859c045bd37c..47e5f9003bb0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c
@@ -2313,7 +2313,7 @@ static void rtl8723e_bt_var_init(struct ieee80211_hw *hw)
rtlpriv->btcoexist.eeprom_bt_radio_shared;
 
RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_TRACE,
-"BT Coexistance = 0x%x\n",
+"BT Coexistence = 0x%x\n",
 rtlpriv->btcoexist.bt_coexistence);
 
if (rtlpriv->btcoexist.bt_coexistence) {
-- 
2.11.0



[PATCH] staging: rtl8188eu, rtl8723bs: fix spelling mistake "Cancle" -> "Cancel"

2017-05-13 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistakes in a comments and RT_TRACE text.

Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 ++--
 drivers/staging/rtl8723bs/core/rtw_mlme.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 301085a459c9..de9ab59f898d 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1081,10 +1081,10 @@ void rtw_joinbss_event_prehandle(struct adapter 
*adapter, u8 *pbuf)
RT_TRACE(_module_rtl871x_mlme_c_, 
_drv_info_, ("adhoc mode, fw_state:%x", get_fwstate(pmlmepriv)));
}
 
-   /* s5. Cancle assoc_timer */
+   /* s5. Cancel assoc_timer */
del_timer_sync(>assoc_timer);
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("Cancle 
assoc_timer\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("Cancel 
assoc_timer\n"));
 
} else {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("rtw_joinbss_event_callback err: fw_state:%x", get_fwstate(pmlmepriv)));
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 9e355734f0c0..e61638291df1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1482,10 +1482,10 @@ void rtw_joinbss_event_prehandle(struct adapter 
*adapter, u8 *pbuf)
}
 
 
-   /* s5. Cancle assoc_timer */
+   /* s5. Cancel assoc_timer */
_cancel_timer(>assoc_timer, 
_cancelled);
 
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("Cancle 
assoc_timer\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("Cancel 
assoc_timer\n"));
 
} else{
RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, 
("rtw_joinbss_event_callback err: fw_state:%x", get_fwstate(pmlmepriv)));
-- 
2.11.0



Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Valentin Vidic
On Sat, May 13, 2017 at 02:58:54PM -0700, PGNet Dev wrote:
> Does this perhaps imply that Xen correctly uses HPET
> 
>   (XEN) [VT-D] MSI HPET: :f0:0f.0
>   (XEN) Platform timer is 14.318MHz HPET

I think so, yes.

> but that Dom0 does not
> 
>   current_clocksource
>   tsc

Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:

# dmesg | grep -i clocksource
[   58.944215] Switched to clocksource xen

-- 
Valentin


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev
On 5/13/17 2:32 PM, Valentin Vidic wrote:
> On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
>> xl dmesg | grep -i hpet   | grep -vi command
>>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
>>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
> 
> Ah, guess this is caused by console_to_ring boot option.
> 
> Better check you are not missing info from the Xen ring buffer.
> It should start with the Xen version like this:
> 

Interesting.

With, currently,

GRUB_CMDLINE_LINUX_XEN_REPLACE="... systemd.log_level=debug 
systemd.log_target=kmsg earlyprintk=xen,keep debug loglevel=8"

and

GRUB_CMDLINE_XEN=" ... console_timestamps console_to_ring 
conring_size=64 sched=credit2 sched_debug log_buf_len=16M iommu=verbose 
apic_verbosity=verbose loglvl=all guest_loglvl=all noreboot=false 
sync_console=true"

I've only

xl dmesg | head
299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical blocks: 
(3.00 TB/2.73 TiB)
[9.449299] sd 1:0:0:0: [sdb] 5860533168 512-byte logical 
blocks: (3.00 TB/2.73 TiB)
[9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[9.449300] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[9.449328] sd 1:0:0:0: [sdb] Write Protect is off
[9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[9.449329] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read 
cache: enabled, doesn't support DPO or FUA
[9.449347] sd 1:0:0:0: [sdb] Write cache: enabled, read 
cache: enabled, doesn't support DPO or FUA

Whereas in serial console,

Booting `OpenSUSE, with Xen hypervisor'Booting `OpenSUSE, with Xen 
hypervisor'



Loading Xen 4.9.0_04-493 with Linux 4.11.0-4.gcb15206-default 
...Loading Xen 4.9.0_04-493 wit
h Linux 4.11.0-4.gcb15206-default ...

/EndEntire
/EndEntire
file path: file path: 
/ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/
PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
]]/HD(2,1000,96000,c5cc9661271
ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)

/File(\EFI\OPENSUSE)/File(xen-4.9.0_04-493.efi)/File(xen-4.9.0_04-493.efi)/EndEntire
/EndEntire
Xen 4.9.0_04-493 (c/s ) EFI loader
Using configuration file 'xen-4.9.0_04-493.cfg'
vmlinuz-4.11.0-4.gcb15206-default: 0x8b986000-0x8c06bf60
initrd-4.11.0-4.gcb15206-default: 0x8aab2000-0x8b985978
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x928a7018
0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x9289e018
0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x9287d018
 __  ___  _   ___   ___ ___  _  _  _  _   ___ _ 
 \ \/ /___ _ __   | || | / _ \ / _ \   / _ \| || || || | / _ \___ / 
  \  // _ \ '_ \  | || || (_) | | | | | | | | || |_ __| || || (_) ||_ \ 
  /  \  __/ | | | |__   _\__, | |_| | | |_| |__   _|__|__   _\__, |__) |
 /_/\_\___|_| |_||_|(_)/_(_)___/___\___/   |_|   |_|   /_// 
  |_|   
(XEN) Xen version 4.9.0_04-493 (abu...@suse.de) (gcc (SUSE Linux) 
4.8.5) debug=y  Wed May 10 
21:26:38 UTC 2017
(XEN) Latest ChangeSet: 
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=4 
vga=gfx-1920x1080x16 com1=11520
0,8n1,pci console=com1,vga console_timestamps console_to_ring 
conring_size=64 sched=credit2 s
ched_debug reboot=acpi log_buf_len=16M iommu=verbose 
apic_verbosity=verbose loglvl=all guest_
loglvl=all noreboot=false sync_console=true
(XEN) Xen image load base address: 0x8c20
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 00048000 (usable)
...

Searching the *console* output for 'hpet',

grep -i hpet tmp.txt
(XEN) ACPI: HPET 9E8298F8, 0038 (r1 SUPERM SMCI--MB  1072009 
AMI.5)
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed0
(XEN) [VT-D] MSI HPET: :f0:0f.0
(XEN) Platform timer is 14.318MHz HPET
=xvc console=tty0 console=hvc0 elevator=deadline cpuidle 
cpufreq=xen:ondemand hpet=force,verb
  

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Valentin Vidic
On Sat, May 13, 2017 at 02:06:28PM -0700, PGNet Dev wrote:
> xl dmesg | grep -i hpet   | grep -vi command
>  [1.365876] hpet_acpi_add: no address or irqs in _CRS
>  [1.365876] hpet_acpi_add: no address or irqs in _CRS

Ah, guess this is caused by console_to_ring boot option.

Better check you are not missing info from the Xen ring buffer.
It should start with the Xen version like this:

# xl dmesg | head
(XEN) Xen version 4.4.1 (Debian 4.4.1-9+deb8u9) 
(ijack...@chiark.greenend.org.uk) (gcc (Debian 4.9.2-10) 4.9.2) debug=n Mon May 
 8 16:01:37 UTC 2017
(XEN) Bootloader: GRUB 2.02~beta2-22+deb8u1
(XEN) Command line: placeholder dom0_mem=2048M com2=115200,8n1 console=com2,vga
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures

-- 
Valentin


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 01:52:29PM -0700, Linus Torvalds wrote:
> I wouldn't change the existing "memdup_user()" interface itself, but
> if there really are users that can validly pass in a maxbyte value,
> why not add a new helper:
> 
>   void *memdup_user_limit(userptr, nmember, nsize, maxsize);
> 
> and then have
> 
>   #define memdup_user(ptr,size) memdup_user_limit(ptr, size, 1, -1)
> 
> or something. I definitely see a couple of memdup_user() people who do
> that "num*size" multiplication by hand, and it's very easy to get
> wrong and have an overflow.
> 
> And for a kvmalloc/kvfree() interface, you *definitely* want that
> maxsize thing, since it absolutely needs an upper limit.

*nod*

Speaking of insanities around open-coded memdup_user()...  Enjoy:

ias_opt = kmalloc(sizeof(struct irda_ias_set), GFP_ATOMIC);
if (ias_opt == NULL) {
err = -ENOMEM;
goto out;
}

/* Copy query to the driver. */
if (copy_from_user(ias_opt, optval, optlen)) {

Can't have it block, sir, has to be GFP_ATOMIC...  Whaddya mean, "what
if copy_from_user() blocks?"  As far as I can see, that came in circa
2.4.6, when local sturct irda_ias_set got switched to dynamic allocation...


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev

On 5/13/17 1:16 PM, Andrew Cooper wrote:

We don't have code like that in upstream Xen.  No function with that
name, or a string which looks like that error message.


noted


http://marc.info/?l=linux-kernel=149464267427111=2 indicates that
you are using a SuSE hypervisor.


yes, that's correct



Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev

On 5/13/17 1:28 PM, Valentin Vidic wrote:

On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:

back to the error at hand ...

  xl dmesg | grep -i hpet
   [1.365876] hpet_acpi_add: no address or irqs in _CRS
   [1.365876] hpet_acpi_add: no address or irqs in _CRS

again, only present when booting with Xen.

same kernel, no Xen, no such error.


Are you sure this is `xl dmesg`


yep.

xl dmesg | grep -i hpet   | grep -vi command
 [1.365876] hpet_acpi_add: no address or irqs in _CRS
 [1.365876] hpet_acpi_add: no address or irqs in _CRS

> and not `dmesg` output?

AND

dmesg | grep -i hpet   | grep -vi command
 [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 0005)

 [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
 [1.365876] hpet_acpi_add: no address or irqs in _CRS



Linux 4.12-rc1

2017-05-13 Thread Linus Torvalds
So I'm doing this one day early, because I don't like last-minute pull
requests during the merge window anyway, and tomorrow is mother's day,
so I may end up being roped into various happenings.

Besides, this has actually been a pretty large merge window, so
despite there technically being time for one more day of pulls, I
actually do have enough changes already. So there.

Despite it being fairly large, it has (so far) been pretty smooth. I
don't think I personally saw any breakage at all, which is always
nice. Usually I end up having something break, or trigger some silly
build failure that really should have been noticed before it even got
to me, but so far things are looking good.

Famous last words.

The diffstat for this release looks a bit odd, because it's absolutely
dominated by the new AMD Vega10 header files that have all the
register definitions in them. In fact, that's almost exactly half the
lines of diff in just that.  And if you ignore that part, the new
Intel Atom IPU driver ends up being a noticeable part of the rest.

But if you ignore those two big additions, the statistics look pretty
normal. Two thirds drivers, with the rest being arch updates,
documentation updates and "misc" (filesystems, networking, header
updates, core files).

One thing worth noting - I haven't uploaded diffs or tar-balls for
this rc. Those should now be automagically generated by kernel.org for
the rc's, but that also means that they won't be signed by my key. If
you really care about signing, get the git repo and check the tag.

Go test.

   Linus

---

Al Viro (7):
uaccess unification updates
iov_iter updates
splice updates
fs/compat.c cleanups
vfs fix
misc vfs updates
misc vfs updates

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (3):
misc updates
more updates
misc fixes

Arnd Bergmann (1):
TEE driver infrastructure and OP-TEE drivers

Bartlomiej Zolnierkiewicz (1):
fbdev updates

Bjorn Helgaas (1):
PCI updates

Bob Peterson (1):
GFS2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (1):
MTD updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (2):
arm64 updates
more arm64 updates

Chris Mason (1):
btrfs updates

Corey Minyard (1):
IPMI updates

Dan Williams (2):
libnvdimm updates
libnvdimm fixes

Darren Hart (1):
x86 platform-drivers update

Darrick Wong (1):
xfs updates

Dave Airlie (4):
drm u pdates
drm tegra updates
drm CoC pointer
drm fixes

David Howells (1):
hw lockdown support

David Millar (1):
networking updates

David Miller (4):
networking fixes
networking fixes
sparc updates
IDE updates

Dmitry Torokhov (2):
input subsystem updates
some more input subsystem updates

Doug Ledford (2):
rdma updates
more rdma updates

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (5):
USB updates
driver core updates
char/misc driver updates
staging/IIO updates
tty/serial updates

Guenter Roeck (1):
hwmon updates

Hans-Christian Noren Egtvedt (1):
AVR32 removal

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
ceph updates

Ingo Molnar (21):
EFI updates
scheduler updates
locking updates
perf updates
RAS updates
x86 boot updates
x86 cpu updates
x86 apic updates
x86 asm updates
x86 build update
x86 cleanups
x86 debug updates
x86 irq update
x86 platform updates
x86 vdso updates
x86 mm updates
RCU updates
x86 fixes
stackprotector fixlet
timer fix
perf updates/fixes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (1):
SCSI updates

James Hogan (2):
metag updates
MIPS updates

James Morris (1):
security subsystem updates

Jan Kara (2):
fsnotify updates
quota, reiserfs, udf and ext2 updates

Jassi Brar (1):
mailbox updates

Jens Axboe (4):
block layer updates
second round of block layer updates
block fixes and updates
block fixes

Jessica Yu (1):
modules updates

Jiri Kosina (3):
HID subsystem updates
livepatch updates
trivial tree updates

Joerg Roedel (1):
IOMMU updates

Jonathan Corbet (2):
documentation update
more documentation updates

Juergen Gross (2):
xen updates
xen fixes

Kees Cook (2):
pstore updates
hardened usercopy updates

Lee Jones (2):
backlight update
MFD updates

Ley Foon Tan (1):
nios2 updates

Linus Walleij (2):
pin control updates
GPIO updates

Luis de Bethencourt (1):
befs fix

Mark Brown (2):
regulator updates
spi updates

Martin Schwidefsky (1):
s390 updates

Masahiro Yamada (3):
Kbuild updates
misc Kbuild updates
Kbuild UAPI updates

Mauro Carvalho Chehab (1):
media updates

Max Filippov (1):
Xtensa updates

Michael 

Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Linus Torvalds
On Sat, May 13, 2017 at 1:37 PM, Al Viro  wrote:
>
> That's a valid point and it might apply to memdup_user() callers out there.
> Potential variants:
> * add an explicit upper bound on the size and turn that into
> memdup_user() (and check that all memdup_user() callers are bounded).
> * have memdup_user() itself pass __GFP_NOWARN.
> * add kvmemdup_user() that would use kvmalloc() (with its callers
> expected to use kvfree()); see who else might benefit from conversion.

All of the above sound reasonable.

I wouldn't change the existing "memdup_user()" interface itself, but
if there really are users that can validly pass in a maxbyte value,
why not add a new helper:

  void *memdup_user_limit(userptr, nmember, nsize, maxsize);

and then have

  #define memdup_user(ptr,size) memdup_user_limit(ptr, size, 1, -1)

or something. I definitely see a couple of memdup_user() people who do
that "num*size" multiplication by hand, and it's very easy to get
wrong and have an overflow.

And for a kvmalloc/kvfree() interface, you *definitely* want that
maxsize thing, since it absolutely needs an upper limit.

 Linus


[PATCH v2] usb: misc: legousbtower: Fix memory leak

2017-05-13 Thread Maksim Salau
get_version_reply is not freed if function returns with success.

Fixes: 942a48730faf ("usb: misc: legousbtower: Fix buffers on stack")
Reported-by: Heikki Krogerus 
Signed-off-by: Maksim Salau 
---

 v2:
 Changed tags to match guidelines.

 drivers/usb/misc/legousbtower.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/misc/legousbtower.c b/drivers/usb/misc/legousbtower.c
index aa3c280fdf8d..0782ac6f5edf 100644
--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -926,6 +926,7 @@ static int tower_probe (struct usb_interface *interface, 
const struct usb_device
 USB_MAJOR, dev->minor);
 
 exit:
+   kfree(get_version_reply);
return retval;
 
 error:
-- 
2.9.3



Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 10:32:31PM +0200, Geert Uytterhoeven wrote:

> You better run that one through linux-spi, to avoid conflicts, cfr.
> https://patchwork.kernel.org/patch/9714993/

What I'm going to do is never-rebased #for-spi (well, never after -rc1)
merged into #work.uaccess and proposed for pull to linux-spi.

The local tree is a mess right now - bloody lot of branches, huge unsorted
pile, etc.  This was from #unsorted, actually - should've picked the one
from #for-spi (a couple of brainos fixed in the version there)...


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> From: Linus Torvalds 
> Date: Tue, 24 Mar 2015 10:42:18 -0700
> >
> > So I'd suggest we should just do a wholesale replacement of
> > __copy_to/from_user() with the non-underlined cases. Then, we could
> > switch insividual ones back - with reasoning of why they matter, and
> > with pointers to how it does access_ok() two lines before.
> >
> > We should probably even consider looking at __get_user/__put_user().
> > Few of them are actually performance-critical.
> 
> Look at that date. It's over two years ago. In the intervening two
> years, how many of those conversions have happened?

Speaking of killing that kind of crap off: there was a question left from the
last cycle that hadn't been sorted out.

SCTP does this in a couple of places:
/* Check the user passed a healthy pointer.  */
if (unlikely(!access_ok(VERIFY_READ, addrs, addrs_size)))
return -EFAULT;

/* Alloc space for the address array in kernel memory.  */
kaddrs = kmalloc(addrs_size, GFP_USER | __GFP_NOWARN);
if (unlikely(!kaddrs))
return -ENOMEM;

if (__copy_from_user(kaddrs, addrs, addrs_size)) {
kfree(kaddrs);
return -EFAULT;
}
instead of memdup_user().  Part of the rationale is pretty weak (access_ok()
as sanity check to prevent user-triggerable attempts to allocate too much -
it still can trivially trigger 2G, so it's not worth much), part is more
interesting.  Namely, that whining into the syslog shouldn't be that easy
to trigger.

That's a valid point and it might apply to memdup_user() callers out there.
Potential variants:
* add an explicit upper bound on the size and turn that into
memdup_user() (and check that all memdup_user() callers are bounded).
* have memdup_user() itself pass __GFP_NOWARN.
* add kvmemdup_user() that would use kvmalloc() (with its callers
expected to use kvfree()); see who else might benefit from conversion.

Preferences?


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Geert Uytterhoeven
Hi Al,

On Sat, May 13, 2017 at 10:08 PM, Al Viro  wrote:
> On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote:
>
>> FWIW, just this cycle (this one I remembered off-hand, there might be
>> more):
>
> And looking through my queue (will be pushed to -next as soon as -rc1 goes
> out):
>
> commit 87fb4c8c103a4cdf17fead4aba58e96940a19a09
> Author: Al Viro 
> Date:   Thu Apr 20 15:47:34 2017 -0400
>
> spidev: quit messing with access_ok()
>
> Signed-off-by: Al Viro 
>
> diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
> index 9e2e099baf8c..8dd22de5e3b5 100644
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c

You better run that one through linux-spi, to avoid conflicts, cfr.
https://patchwork.kernel.org/patch/9714993/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Valentin Vidic
On Sat, May 13, 2017 at 01:05:22PM -0700, PGNet Dev wrote:
> back to the error at hand ...
> 
>  xl dmesg | grep -i hpet
>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
> 
> again, only present when booting with Xen.
> 
> same kernel, no Xen, no such error.

Are you sure this is `xl dmesg` and not `dmesg` output?

On Debian jessie it looks like the hypervisor is using
HPET by default as expected:

# xl dmesg | grep -i hpet
(XEN) ACPI: HPET 7986E860, 0038 (r1 SUPERM SMCI--MB1 INTL 20091013)
(XEN) Platform timer is 14.318MHz HPET

# dmesg | grep -i hpet
[0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
[   64.157167] hpet_acpi_add: no address or irqs in _CRS

-- 
Valentin


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Andrew Cooper
On 13/05/2017 21:05, PGNet Dev wrote:
> On 5/13/17 12:59 PM, Andrew Cooper wrote:
>> Ok.  Lack of a clocksource is to be expected.
>>
>> The reason why the HPETs are unavailable is that dom0 is not a position
>> to program them; dom0 doesn't know what Xen has set up in the IDT.
>>
>> Use `xl dmesg` to get to the hypervisor dmesg log.  You should see
>> mention of the HPET in there if Xen has found it.
>
> back to the error at hand ...
>
>  xl dmesg | grep -i hpet
>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
>   [1.365876] hpet_acpi_add: no address or irqs in _CRS
>
> again, only present when booting with Xen.
>
> same kernel, no Xen, no such error.

We don't have code like that in upstream Xen.  No function with that
name, or a string which looks like that error message.

http://marc.info/?l=linux-kernel=149464267427111=2 indicates that
you are using a SuSE hypervisor.

Jan/Juergen: Any ideas? This looks as if it is something local to your
patch queue.

~Andrew


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 08:56:59PM +0100, Al Viro wrote:

> FWIW, just this cycle (this one I remembered off-hand, there might be
> more):

And looking through my queue (will be pushed to -next as soon as -rc1 goes
out):

commit 87fb4c8c103a4cdf17fead4aba58e96940a19a09
Author: Al Viro 
Date:   Thu Apr 20 15:47:34 2017 -0400

spidev: quit messing with access_ok()

Signed-off-by: Al Viro 

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 9e2e099baf8c..8dd22de5e3b5 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -254,10 +254,6 @@ static int spidev_message(struct spidev_data *spidev,
goto done;
}
k_tmp->rx_buf = rx_buf;
-   if (!access_ok(VERIFY_WRITE, (u8 __user *)
-   (uintptr_t) u_tmp->rx_buf,
-   u_tmp->len))
-   goto done;
rx_buf += k_tmp->len;
}
if (u_tmp->tx_buf) {
@@ -305,7 +301,7 @@ static int spidev_message(struct spidev_data *spidev,
rx_buf = spidev->rx_buffer;
for (n = n_xfers, u_tmp = u_xfers; n; n--, u_tmp++) {
if (u_tmp->rx_buf) {
-   if (__copy_to_user((u8 __user *)
+   if (copy_to_user((u8 __user *)
(uintptr_t) u_tmp->rx_buf, rx_buf,
u_tmp->len)) {
status = -EFAULT;
@@ -325,8 +321,7 @@ static struct spi_ioc_transfer *
 spidev_get_ioc_message(unsigned int cmd, struct spi_ioc_transfer __user *u_ioc,
unsigned *n_ioc)
 {
-   struct spi_ioc_transfer *ioc;
-   u32 tmp;
+   u32 size;
 
/* Check type, command number and direction */
if (_IOC_TYPE(cmd) != SPI_IOC_MAGIC
@@ -334,22 +329,15 @@ spidev_get_ioc_message(unsigned int cmd, struct 
spi_ioc_transfer __user *u_ioc,
|| _IOC_DIR(cmd) != _IOC_WRITE)
return ERR_PTR(-ENOTTY);
 
-   tmp = _IOC_SIZE(cmd);
+   size = _IOC_SIZE(cmd);
if ((tmp % sizeof(struct spi_ioc_transfer)) != 0)
return ERR_PTR(-EINVAL);
-   *n_ioc = tmp / sizeof(struct spi_ioc_transfer);
+   *n_ioc = size / sizeof(struct spi_ioc_transfer);
if (*n_ioc == 0)
return NULL;
 
/* copy into scratch area */
-   ioc = kmalloc(tmp, GFP_KERNEL);
-   if (!ioc)
-   return ERR_PTR(-ENOMEM);
-   if (__copy_from_user(ioc, u_ioc, tmp)) {
-   kfree(ioc);
-   return ERR_PTR(-EFAULT);
-   }
-   return ioc;
+   return memdup_user(u_ioc, size);
 }
 
 static long
@@ -367,19 +355,6 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
if (_IOC_TYPE(cmd) != SPI_IOC_MAGIC)
return -ENOTTY;
 
-   /* Check access direction once here; don't repeat below.
-* IOC_DIR is from the user perspective, while access_ok is
-* from the kernel perspective; so they look reversed.
-*/
-   if (_IOC_DIR(cmd) & _IOC_READ)
-   err = !access_ok(VERIFY_WRITE,
-   (void __user *)arg, _IOC_SIZE(cmd));
-   if (err == 0 && _IOC_DIR(cmd) & _IOC_WRITE)
-   err = !access_ok(VERIFY_READ,
-   (void __user *)arg, _IOC_SIZE(cmd));
-   if (err)
-   return -EFAULT;
-
/* guard against device removal before, or while,
 * we issue this ioctl.
 */
@@ -402,31 +377,31 @@ spidev_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
/* read requests */
case SPI_IOC_RD_MODE:
-   retval = __put_user(spi->mode & SPI_MODE_MASK,
+   retval = put_user(spi->mode & SPI_MODE_MASK,
(__u8 __user *)arg);
break;
case SPI_IOC_RD_MODE32:
-   retval = __put_user(spi->mode & SPI_MODE_MASK,
+   retval = put_user(spi->mode & SPI_MODE_MASK,
(__u32 __user *)arg);
break;
case SPI_IOC_RD_LSB_FIRST:
-   retval = __put_user((spi->mode & SPI_LSB_FIRST) ?  1 : 0,
+   retval = put_user((spi->mode & SPI_LSB_FIRST) ?  1 : 0,
(__u8 __user *)arg);
break;
case SPI_IOC_RD_BITS_PER_WORD:
-   retval = __put_user(spi->bits_per_word, (__u8 __user *)arg);
+   retval = put_user(spi->bits_per_word, (__u8 __user *)arg);
break;
case SPI_IOC_RD_MAX_SPEED_HZ:
-   retval = __put_user(spidev->speed_hz, (__u32 __user *)arg);
+   retval = put_user(spidev->speed_hz, (__u32 

Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev

On 5/13/17 12:59 PM, Andrew Cooper wrote:

Ok.  Lack of a clocksource is to be expected.

The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.

Use `xl dmesg` to get to the hypervisor dmesg log.  You should see
mention of the HPET in there if Xen has found it.


back to the error at hand ...

 xl dmesg | grep -i hpet
  [1.365876] hpet_acpi_add: no address or irqs in _CRS
  [1.365876] hpet_acpi_add: no address or irqs in _CRS

again, only present when booting with Xen.

same kernel, no Xen, no such error.


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Andrew Cooper
On 13/05/2017 20:28, Randy Dunlap wrote:
> On 05/13/17 11:26, PGNet Dev wrote:
>> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>>> [adding HPET driver maintainer]
>> Thanks
>>
>>> A couple of comments below...
 In BIOS, HPET's enabled.
>>> How about if you just boot Linux without Xen?  Does HPET show up then?
>> yes, it appears so:
>>
>> cat devices/system/clocksource/clocksource0/available
>>   tsc hpet acpi_pm
> Adding xen mailing list:
>
> Is HPET support a known issue in Xen?

What is the issue here?

Xen owns (and may use) any HPETs in the system.  They are purposefully
unavailable to even dom0.

~Andrew


Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Andrew Cooper
On 13/05/2017 20:49, PGNet Dev wrote:
> On 5/13/17 12:38 PM, Andrew Cooper wrote:
>> What is the issue here?
>>
>> Xen owns (and may use) any HPETs in the system.  They are purposefully
>> unavailable to even dom0.
> The issue is that, when booting to Xen, hpet is not advertised as an 
> available clocksource, AND reports the hpet boot error pointed out by Randy.
>
> Following 
>
>   
> https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D
>
> there's discussion there re: 'if HPET is available / not missing'.
>
> It appears to be available only booting to non-Xen.
>
> What specific indication does one look for that Xen's using available hpet?
>

Ok.  Lack of a clocksource is to be expected.

The reason why the HPETs are unavailable is that dom0 is not a position
to program them; dom0 doesn't know what Xen has set up in the IDT.

Use `xl dmesg` to get to the hypervisor dmesg log.  You should see
mention of the HPET in there if Xen has found it.

~Andrew


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> > We should probably even consider looking at __get_user/__put_user().
> > Few of them are actually performance-critical.
> 
> Look at that date. It's over two years ago. In the intervening two
> years, how many of those conversions have happened?
> 
> Here's a hint: it's a very very round number.

FWIW, just this cycle (this one I remembered off-hand, there might be
more):

commit edb88cef0570914375d461107759cf0d6d677ed5
Author: Arnd Bergmann 
Date:   Sat Apr 22 00:02:31 2017 +0200

scsi: pmcraid: use normal copy_from_user

As pointed out by Al Viro for my previous series, the driver has no need
to call access_ok() and __copy_from_user()/__copy_to_user(). Changing
it to regular copy_from_user()/copy_to_user() simplifies the code without
any real downsides, making it less error-prone at best.

This patch by itself also addresses the warning about the access_ok()
macro on MIPS, but both fixes improve the code, so ideally we apply
them both.

Signed-off-by: Arnd Bergmann 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 



Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Clemens Ladisch
Randy Dunlap wrote:
> On 05/12/17 19:30, PGNet Dev wrote:
>>  dmesg | grep -i hpet
>>  [8.491738] hpet_acpi_add: no address or irqs in _CRS
>
> Above line marks a big failure. 
> ^^^
>
>> Disassembling the firmware acpi tables
>>
>>  cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out
>>  iasl -d /var/tmp/hpet.out

That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.

But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET registration is
always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c.
Try adding logging to hpet_late_init() to find out why it aborts.


Regards,
Clemens


Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

2017-05-13 Thread Matt Brown

On 05/10/2017 04:29 PM, Alan Cox wrote:

On Fri,  5 May 2017 19:20:16 -0400
Matt Brown  wrote:


This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.

This patch was inspired from GRKERNSEC_HARDEN_TTY.

This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace

Possible effects on userland:

There could be a few user programs that would be effected by this
change.
See: 
notable programs are: agetty, csh, xemacs and tcsh

However, I still believe that this change is worth it given that the
Kconfig defaults to n.


And it still doesn't deal with the fact that there are hundreds of other
ways to annoy the owner of a tty if it's passed to a lower privilege
child from framebuffer reprogramming through keyboard remaps.

The proper way to handle those cases is to create a pty/tty pair and use
that. Your patch is pure snake oil and if anything implies safety that
doesn't exist.



I'm not implying that my patch is supposed to provide safety for
"hundreds of other" issues. I'm looking to provide a way to lock down a
single TTY ioctl that has caused real security issues to arise. For
this reason, it's completely incorrect to say that this feature is
snake oil. My patch does exactly what it claims to do. No more no less.


In addition your change to allow it to be used by root in the guest
completely invalidates any protection you have because I can push

"rm -rf /\n"

as root in my namespace and exit

The tty buffers are not flushed across the context change so the shell
you return to gets the input and oh dear


This is precisely what my patch prevents! With my protection enabled, a
container will only be able to use the TIOCSTI ioctl on a tty if that
container has CAP_SYS_ADMIN in the user namespace in which the tty was
created.



Alan



Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev

On 5/13/17 12:45 PM, Clemens Ladisch wrote:

That table is not used by hpet_acpi_add; you have to check for the device
that mentions "PNP0103" in the DSDT table.

But anyway, as far as I can tell from my own machine, the _CRS in the
DSDT table never lists the HPET interrupts, and the HPET registration is
always done by hpet_reserve_platform_timers() in arch/x86/kernel/hpet.c.
Try adding logging to hpet_late_init() to find out why it aborts.


I assume you mean in kernel source code?

I'm using distro packages for both kernel & Xen -- not DIY building.



[PATCH] ligtnvm: if LUNs are already allocated fix return

2017-05-13 Thread Rakesh Pandit
While creating new device with NVM_DEV_CREATE if LUNs are already
allocated ioctl would return -ENOMEM which is wrong.  This patch
propagates -EBUSY from nvm_reserve_luns which is correct response.

Fixes: ade69e243 ("lightnvm: merge gennvm with core")
Signed-off-by: Rakesh Pandit 
---
 drivers/lightnvm/core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 6a4aa60..440deb5 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -235,7 +235,7 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
struct nvm_target *t;
struct nvm_tgt_dev *tgt_dev;
void *targetdata;
-   int ret;
+   int ret = 0;
 
tt = nvm_find_target_type(create->tgttype, 1);
if (!tt) {
@@ -252,8 +252,9 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
}
mutex_unlock(>mlock);
 
-   if (nvm_reserve_luns(dev, s->lun_begin, s->lun_end))
-   return -ENOMEM;
+   ret = nvm_reserve_luns(dev, s->lun_begin, s->lun_end);
+   if (ret)
+   goto err;
 
t = kmalloc(sizeof(struct nvm_target), GFP_KERNEL);
if (!t) {
@@ -314,8 +315,8 @@ static int nvm_create_tgt(struct nvm_dev *dev, struct 
nvm_ioctl_create *create)
mutex_lock(>mlock);
list_add_tail(>list, >targets);
mutex_unlock(>mlock);
-
-   return 0;
+err:
+   return ret;
 err_sysfs:
if (tt->exit)
tt->exit(targetdata);
-- 
2.9.3



Re: [Xen-devel] HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev
On 5/13/17 12:38 PM, Andrew Cooper wrote:
> What is the issue here?
> 
> Xen owns (and may use) any HPETs in the system.  They are purposefully
> unavailable to even dom0.

The issue is that, when booting to Xen, hpet is not advertised as an available 
clocksource, AND reports the hpet boot error pointed out by Randy.

Following 

  
https://wiki.xen.org/wiki/Xen_power_management#HPET_as_broadcast_timer_source_.28clocksource.29_.3D

there's discussion there re: 'if HPET is available / not missing'.

It appears to be available only booting to non-Xen.

What specific indication does one look for that Xen's using available hpet?



Re: [PATCH 09/17] doc: ReSTify apparmor.txt

2017-05-13 Thread John Johansen
On 05/13/2017 04:51 AM, Kees Cook wrote:
> Adjusts for ReST markup and moves under LSM admin guide.
> 
> Cc: John Johansen 
> Signed-off-by: Kees Cook 
Acked-by: John Johansen 

> ---
>  .../apparmor.txt => admin-guide/LSM/apparmor.rst}  | 36 
> ++
>  Documentation/admin-guide/LSM/index.rst|  1 +
>  Documentation/security/00-INDEX|  2 --
>  MAINTAINERS|  1 +
>  security/apparmor/match.c  |  2 +-
>  security/apparmor/policy_unpack.c  |  2 +-
>  6 files changed, 28 insertions(+), 16 deletions(-)
>  rename Documentation/{security/apparmor.txt => admin-guide/LSM/apparmor.rst} 
> (65%)
> 
> diff --git a/Documentation/security/apparmor.txt 
> b/Documentation/admin-guide/LSM/apparmor.rst
> similarity index 65%
> rename from Documentation/security/apparmor.txt
> rename to Documentation/admin-guide/LSM/apparmor.rst
> index 93c1fd7d0635..3e9734bd0e05 100644
> --- a/Documentation/security/apparmor.txt
> +++ b/Documentation/admin-guide/LSM/apparmor.rst
> @@ -1,4 +1,9 @@
>  What is AppArmor? ---
> +
> +AppArmor
> +
> +
> +What is AppArmor?
> +=
>  
>  AppArmor is MAC style security extension for the Linux kernel.  It implements
>  a task centered policy, with task "profiles" being created and loaded
> @@ -6,34 +11,41 @@ from user space.  Tasks on the system that do not have a 
> profile defined for
>  them run in an unconfined state which is equivalent to standard Linux DAC
>  permissions.
>  
>  How to enable/disable ---
> +How to enable/disable
> +=
> +
> +set ``CONFIG_SECURITY_APPARMOR=y``
>  
> -set CONFIG_SECURITY_APPARMOR=y
> +If AppArmor should be selected as the default security module then set::
>  
> -If AppArmor should be selected as the default security module then
> -   set CONFIG_DEFAULT_SECURITY="apparmor"
> -   and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
> +   CONFIG_DEFAULT_SECURITY="apparmor"
> +   CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
>  
>  Build the kernel
>  
>  If AppArmor is not the default security module it can be enabled by passing
> -security=apparmor on the kernel's command line.
> +``security=apparmor`` on the kernel's command line.
>  
>  If AppArmor is the default security module it can be disabled by passing
> -apparmor=0, security= (where XXX is valid security module), on the
> -kernel's command line
> +``apparmor=0, security=`` (where ```` is valid security module), on 
> the
> +kernel's command line.
>  
>  For AppArmor to enforce any restrictions beyond standard Linux DAC 
> permissions
>  policy must be loaded into the kernel from user space (see the Documentation
>  and tools links).
>  
>  Documentation ---
> +Documentation
> +=
>  
> -Documentation can be found on the wiki.
> +Documentation can be found on the wiki, linked below.
>  
>  Links ---
> +Links
> +=
>  
>  Mailing List - appar...@lists.ubuntu.com
> +
>  Wiki - http://apparmor.wiki.kernel.org/
> +
>  User space tools - https://launchpad.net/apparmor
> +
>  Kernel module - 
> git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
> diff --git a/Documentation/admin-guide/LSM/index.rst 
> b/Documentation/admin-guide/LSM/index.rst
> index cc0e04d63bf9..a4db29410ea0 100644
> --- a/Documentation/admin-guide/LSM/index.rst
> +++ b/Documentation/admin-guide/LSM/index.rst
> @@ -33,4 +33,5 @@ the one "major" module (e.g. SELinux) if there is one 
> configured.
>  .. toctree::
> :maxdepth: 1
>  
> +   apparmor
> SELinux
> diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
> index aaa0195418b3..22ebdc02f0dc 100644
> --- a/Documentation/security/00-INDEX
> +++ b/Documentation/security/00-INDEX
> @@ -4,8 +4,6 @@ Smack.txt
>   - documentation on the Smack Linux Security Module.
>  Yama.txt
>   - documentation on the Yama Linux Security Module.
> -apparmor.txt
> - - documentation on the AppArmor security extension.
>  keys-ecryptfs.txt
>   - description of the encryption keys for the ecryptfs filesystem.
>  keys-request-key.txt
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c85108b4f6c7..184cdd32a67e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11560,6 +11560,7 @@ W:apparmor.wiki.kernel.org
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
>  S:   Supported
>  F:   security/apparmor/
> +F:   Documentation/admin-guide/LSM/apparmor.rst
>  
>  LOADPIN SECURITY MODULE
>  M:   Kees Cook 
> diff --git a/security/apparmor/match.c b/security/apparmor/match.c
> index 960c913381e2..72c604350e80 100644
> --- a/security/apparmor/match.c
> +++ b/security/apparmor/match.c
> @@ -226,7 +226,7 @@ void aa_dfa_free_kref(struct kref *kref)
>   * @flags: flags controlling what type of accept tables are acceptable
>   *

Re: Is there an recommended way to refer to bitkeepr commits?

2017-05-13 Thread Andreas Schwab
On Mai 13 2017, Rob Landley  wrote:

> It's the "must be pushed/fetched explicitly" part that I couldn't figure
> out back when I tried it.

You have to use refs/replace/*:refs/replace/* as the refspec for push
and fetch.  By default, push and fetch only look at refs/heads/*.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 08:11:42PM +0100, Al Viro wrote:
> It's not impossible to review; the problem is in figuring out which codepaths
> are hot enough to worry about them.  And I'm even more convinced that
> bulk search-and-replace is the right approach here; we probably _can_ get
^- not
apologies for sloppy editing...

> rid of that shit this cycle (or, at least, reduce its use to very few places
> in arch/*), but that'll require some cooperation from architecture 
> maintainers.


[PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

2017-05-13 Thread Naveen N. Rao
If instance directories are deleted while there are registered function
triggers:

  # cd /sys/kernel/debug/tracing/instances
  # mkdir test
  # echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter
  # rmdir test
  Unable to handle kernel paging request for data at address 0x0008
  Unable to handle kernel paging request for data at address 0x0008
  Faulting instruction address: 0xc21edde8
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=2048
  NUMA
  pSeries
  Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm 
iptable_filter fuse binfmt_misc pseries_rng rng_core vmx_crypto ib_iser rdma_cm 
iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 
btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx 
xor raid6_pq libcrc32c multipath virtio_net virtio_blk virtio_pci crc32c_vpmsum 
virtio_ring virtio
  CPU: 8 PID: 8694 Comm: rmdir Not tainted 4.11.0-nnr+ #113
  task: c000bab52800 task.stack: c000baba
  NIP: c21edde8 LR: c21f0590 CTR: c2119620
  REGS: c000baba3870 TRAP: 0300   Not tainted  (4.11.0-nnr+)
  MSR: 80009033 
CR: 22002422  XER: 2000
  CFAR: 7fffabb725a8 DAR: 0008 DSISR: 4000 SOFTE: 0
  GPR00: c220f750 c000baba3af0 c3157e00 
  GPR04: 0040 00eb 0040 
  GPR08:  0113  c305db98
  GPR12: c2119620 cfd42c00  
  GPR16:    
  GPR20:   c000bab52e90 
  GPR24:  00eb 0040 c000baba3bb0
  GPR28: c0009cb06eb0 c000bab52800 c0009cb06eb0 c000baba3bb0
  NIP [c21edde8] ring_buffer_lock_reserve+0x8/0x4e0
  LR [c21f0590] trace_event_buffer_lock_reserve+0xe0/0x1a0
  Call Trace:
  [c000baba3af0] [c21f96c8] trace_event_buffer_commit+0x1b8/0x280 
(unreliable)
  [c000baba3b60] [c220f750] trace_event_buffer_reserve+0x80/0xd0
  [c000baba3b90] [c21196b8] 
trace_event_raw_event_sched_switch+0x98/0x180
  [c000baba3c10] [c29d9980] __schedule+0x6e0/0xab0
  [c000baba3ce0] [c2122230] do_task_dead+0x70/0xc0
  [c000baba3d10] [c20ea9c8] do_exit+0x828/0xd00
  [c000baba3dd0] [c20eaf70] do_group_exit+0x60/0x100
  [c000baba3e10] [c20eb034] SyS_exit_group+0x24/0x30
  [c000baba3e30] [c200bcec] system_call+0x38/0x54
  Instruction dump:
  6000 6042 7d244b78 7f63db78 4bffaa09 393efff8 793e0020 3920
  4bfffecc 6042 3c4c00f7 3842a020 <81230008> 2f89 409e02f0 a14d0008
  ---[ end trace b917b8985d0e650b ]---
  Unable to handle kernel paging request for data at address 0x0008
  Faulting instruction address: 0xc21edde8
  Unable to handle kernel paging request for data at address 0x0008
  Faulting instruction address: 0xc21edde8
  Faulting instruction address: 0xc21edde8

To address this, let's clear all registered function probes before
deleting the ftrace instance.

Reported-by: Michael Ellerman 
Signed-off-by: Naveen N. Rao 
---
 kernel/trace/ftrace.c | 8 
 kernel/trace/trace.c  | 1 +
 kernel/trace/trace.h  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 28dc824ad072..1b96d927a082 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4256,6 +4256,14 @@ unregister_ftrace_function_probe_func(char *glob, struct 
trace_array *tr,
return ret;
 }
 
+void clear_ftrace_function_probes(struct trace_array *tr)
+{
+   struct ftrace_func_probe *probe, *n;
+
+   list_for_each_entry_safe(probe, n, >func_probes, list)
+   unregister_ftrace_function_probe_func(NULL, tr, 
probe->probe_ops);
+}
+
 static LIST_HEAD(ftrace_commands);
 static DEFINE_MUTEX(ftrace_cmd_mutex);
 
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index c4536c449021..3f2aed4ad1ed 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7550,6 +7550,7 @@ static int instance_rmdir(const char *name)
}
 
tracing_set_nop(tr);
+   clear_ftrace_function_probes(tr);
event_trace_del_tracer(tr);
ftrace_clear_pids(tr);
ftrace_destroy_function_files(tr);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 291a1bca5748..98e0845f7235 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -980,6 +980,7 @@ register_ftrace_function_probe(char *glob, struct 
trace_array *tr,
 extern int
 

[PATCH 1/4] ftrace: Simplify glob handling in unregister_ftrace_function_probe_func()

2017-05-13 Thread Naveen N. Rao
Handle a NULL glob properly.

Signed-off-by: Naveen N. Rao 
---
 kernel/trace/ftrace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 39dca4e86a94..28dc824ad072 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4144,9 +4144,9 @@ unregister_ftrace_function_probe_func(char *glob, struct 
trace_array *tr,
int i, ret = -ENODEV;
int size;
 
-   if (glob && (strcmp(glob, "*") == 0 || !strlen(glob)))
+   if (!glob || (glob && (strcmp(glob, "*") == 0 || !strlen(glob
func_g.search = NULL;
-   else if (glob) {
+   else {
int not;
 
func_g.type = filter_parse_regex(glob, strlen(glob),
-- 
2.12.2



[PATCH 4/4] selftests/ftrace: Add test to remove instance with active event triggers

2017-05-13 Thread Naveen N. Rao
Add a test to ensure we clean up properly when removing an instance
with active event triggers.

Signed-off-by: Naveen N. Rao 
---
Steven,
I have also removed what looked like an incorrect 'exit' in the middle
of this test. Kindly take a look if that's ok.

- Naveen

 tools/testing/selftests/ftrace/test.d/instances/instance-event.tc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc 
b/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
index 4c5a061a5b4e..c73db7863adb 100644
--- a/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
+++ b/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
@@ -75,9 +75,13 @@ rmdir foo
 if [ -d foo ]; then
 fail "foo still exists"
 fi
-exit 0
-
 
+mkdir foo
+echo "schedule:enable_event:sched:sched_switch" > foo/set_ftrace_filter
+rmdir foo
+if [ -d foo ]; then
+fail "foo still exists"
+fi
 
 
 instance_slam() {
-- 
2.12.2



[PATCH 0/4] ftrace: Fix a few issues

2017-05-13 Thread Naveen N. Rao
This series fixes a kernel oops when an ftrace instance is deleted while
there are still active event triggers. Patch 2 provides details on how
to reproduce as well as the kernel oops message.

This issue was reported by Michael Ellerman as a crash seen when trying
to run the ftrace test suite. In looking into it, I noticed that the
issue actually showed up due to a few bashisms in the ftrace tests when
run on Ubuntu. Those bashisms meant that the ftrace instance was being
deleted without removing the event triggers. Patch 3 includes a fix for
the bashisms.

Patch 4 adds a test case to explicitly catch this issue going forward.


- Naveen

Naveen N. Rao (4):
  ftrace: Simplify glob handling in
unregister_ftrace_function_probe_func()
  ftrace/instances: Clear function triggers when removing instances
  selftests/ftrace: Fix bashisms
  selftests/ftrace: Add test to remove instance with active event
triggers

 kernel/trace/ftrace.c| 12 ++--
 kernel/trace/trace.c |  1 +
 kernel/trace/trace.h |  1 +
 tools/testing/selftests/ftrace/ftracetest|  2 +-
 .../selftests/ftrace/test.d/ftrace/func_event_triggers.tc|  2 +-
 tools/testing/selftests/ftrace/test.d/functions  |  4 ++--
 .../selftests/ftrace/test.d/instances/instance-event.tc  |  8 ++--
 7 files changed, 22 insertions(+), 8 deletions(-)

-- 
2.12.2



[PATCH 3/4] selftests/ftrace: Fix bashisms

2017-05-13 Thread Naveen N. Rao
Fix a few bashisms in ftrace selftests.

Signed-off-by: Naveen N. Rao 
---
 tools/testing/selftests/ftrace/ftracetest   | 2 +-
 tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc | 2 +-
 tools/testing/selftests/ftrace/test.d/functions | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 32e6211e1c6e..717581145cfc 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -58,7 +58,7 @@ parse_opts() { # opts
 ;;
 --verbose|-v|-vv)
   VERBOSE=$((VERBOSE + 1))
-  [ $1 == '-vv' ] && VERBOSE=$((VERBOSE + 1))
+  [ $1 = '-vv' ] && VERBOSE=$((VERBOSE + 1))
   shift 1
 ;;
 --debug|-d)
diff --git 
a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
index 07bb3e5930b4..aa31368851c9 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_event_triggers.tc
@@ -48,7 +48,7 @@ test_event_enabled() {
 e=`cat $EVENT_ENABLE`
 if [ "$e" != $val ]; then
echo "Expected $val but found $e"
-   exit -1
+   exit 1
 fi
 }
 
diff --git a/tools/testing/selftests/ftrace/test.d/functions 
b/tools/testing/selftests/ftrace/test.d/functions
index 9aec6fcb7729..f2019b37370d 100644
--- a/tools/testing/selftests/ftrace/test.d/functions
+++ b/tools/testing/selftests/ftrace/test.d/functions
@@ -34,10 +34,10 @@ reset_ftrace_filter() { # reset all triggers in 
set_ftrace_filter
 echo > set_ftrace_filter
 grep -v '^#' set_ftrace_filter | while read t; do
tr=`echo $t | cut -d: -f2`
-   if [ "$tr" == "" ]; then
+   if [ "$tr" = "" ]; then
continue
fi
-   if [ $tr == "enable_event" -o $tr == "disable_event" ]; then
+   if [ $tr = "enable_event" -o $tr = "disable_event" ]; then
tr=`echo $t | cut -d: -f1-4`
limit=`echo $t | cut -d: -f5`
else
-- 
2.12.2



Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Randy Dunlap
On 05/13/17 11:26, PGNet Dev wrote:
> On 5/13/17 10:41 AM, Randy Dunlap wrote:
>> [adding HPET driver maintainer]
> 
> Thanks
> 
>> A couple of comments below...
> 
>>> In BIOS, HPET's enabled.
>>
>> How about if you just boot Linux without Xen?  Does HPET show up then?
> 
> yes, it appears so:
> 
> cat devices/system/clocksource/clocksource0/available
>   tsc hpet acpi_pm

Adding xen mailing list:

Is HPET support a known issue in Xen?

release: 4.11.0-4.gcb15206-default
xen_version: 4.9.0_04-493


Original message is here:
http://marc.info/?l=linux-kernel=149464267427111=2


Thanks.

>>> [8.491738] hpet_acpi_add: no address or irqs in _CRS
>>
>> Above line marks a big failure. 
>> ^^^
> 
> I suspected that's problematic.
> 
> In the non-Xen case
> 
> dmesg | grep -i hpet
>   [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM SMCI--MB 
> 01072009 AMI. 0005)
>   [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
>   [0.00] clocksource: hpet: mask: 0x max_cycles: 0x, 
> max_idle_ns: 133484882848 ns
>   [0.00] hpet clockevent registered
>   [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9
>   [1.398047] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0, 0, 0, 0, 0
>   [1.404226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
>   [1.412080] clocksource: Switched to clocksource hpet
>   [3.627234] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes 
> nvram, hpet irqs
> 


-- 
~Randy


Re: [PATCH 2/2] ARM: dts: nexus7: Add regulator tweaks and wcnss entry to support wifi

2017-05-13 Thread Bjorn Andersson
On Fri 12 May 14:18 PDT 2017, John Stultz wrote:

>   lvs7 {
>   bias-pull-down;
> + regulator-always-on;
>   };

Looking at the downstream regulator definition lvs7 is identified as
"pll_vdd" - which I believe is what Qualcomm abbreviates as "px". It's
supplied by S4 and as such will provide 1.8V to something. So it's quite
likely that I picked the wrong regulator in the dtsi and that this is
the px supply of the wcnss.

Unfortunately I don't have any 8064 device (with wcnss) hooked up and I
can't find any schematics :/

Would you mind changing the riva-pil vddpx-supply to _lvs7 and
give this a spin?

Regards,
Bjorn


Re: [v3 3/9] mm: add "zero" argument to vmemmap allocators

2017-05-13 Thread kbuild test robot
Hi Pavel,

[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170512]
[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/Pavel-Tatashin/parallelized-struct-page-zeroing/20170507-061412
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: ia64-gensparse_defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All error/warnings (new ones prefixed by >>):

   mm/sparse-vmemmap.c: In function '__earlyonly_bootmem_alloc':
>> mm/sparse-vmemmap.c:45:14: error: implicit declaration of function 
>> 'memblock_virt_alloc_try_nid_raw' [-Werror=implicit-function-declaration]
 void *mem = memblock_virt_alloc_try_nid_raw(size, align, goal,
 ^~~
>> mm/sparse-vmemmap.c:45:14: warning: initialization makes pointer from 
>> integer without a cast [-Wint-conversion]
   cc1: some warnings being treated as errors

vim +/memblock_virt_alloc_try_nid_raw +45 mm/sparse-vmemmap.c

39  static void * __ref __earlyonly_bootmem_alloc(int node,
40  unsigned long size,
41  unsigned long align,
42  unsigned long goal,
43  bool zero)
44  {
  > 45  void *mem = memblock_virt_alloc_try_nid_raw(size, align, goal,
46  
BOOTMEM_ALLOC_ACCESSIBLE,
47  node);
48  if (!mem) {

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


.config.gz
Description: application/gzip


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 12:00:10PM -0700, Linus Torvalds wrote:
> On Sat, May 13, 2017 at 11:04 AM, Al Viro  wrote:
> >
> >
> > My point is, this stuff needs looking at.
> 
> No.
> 
> You don't have a point. I've tried to explain that there's no
> performance difference, and there is no way in hell that the current
> "__" versions are better.
> 
> So what's the point in looking? All you are ever going to come up with
> is theoretical "this might" cases.

Umm...  Just during this subthread - a couple of likely breakages in
xen (which would need looking into, right?) and "oopsen on alpha would
stop actually printing code", which is better to spot early.  The first
one might be theoretical, but it's worth giving heads-up to xen folks;
I'm fairly sure that this spot will break.  The second is not theoretical
at all - it *will* break.


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 07:26:56PM +0100, Al Viro wrote:
> BTW, even in arch/* they tend to nest.  E.g. arch/alpha has 133 callers
> total.  Distribution by files:
>  35 arch/alpha/kernel/osf_sys.c
>  92 arch/alpha/kernel/signal.c
>   1 arch/alpha/kernel/traps.c
>   4 arch/alpha/lib/csum_partial_copy.c
>   1 arch/alpha/mm/fault.c

Another large pile is on sparc (208 callers).  Except that on sparc64
access_ok() is constant 1, which reduces it to 42 callers.
3 arch/sparc/kernel/ptrace_32.c (all in arch_ptrace())
   31 arch/sparc/kernel/signal_32.c (5 in do_sigreturn(),
 6 in do_rt_sigreturn(),
 8 in setup_frame(),
 11 in setup_rt_frame(),
 1 in do_sys_sigstack())
7 arch/sparc/kernel/sigutil_32.c (2 in save_fpu_state(),
  2 in restore_fpu_state(),
  2 in save_rwin_state(),
  1 in restore_rwin_state()
1 arch/sparc/mm/fault_32.c (in compute_si_addr())

The last one ignores -EFAULT, BTW - not sure what should it have done
in that case, though.  It's calculation of ->si_addr on SIGSEGV and SIGBUS
in case of data access SIGSEGV or SIGBUS; it wants to peek into insn to
figure out the effective address.  arch_ptrace() one is zeroing several
fields in userland struct fps for PTRACE_GETFPREGS.  Could've been
put_user() (or clear_user(), for that matter); we'd just done
copy_regset_to_user() on adjacent addresses, so the lack of access_ok() is not
a security hole there).  Everything else is in sigframe handling...

Other large piles are on mips, ppc and itanic.  parisc is next, but there
access_ok() is constant 1 as well.  Same for s390 and m68k.  nios2 and
unicore32 are a bit under 80 callers each and the next are tile (~60),
sh (~50) and then it drops off fast.

It's not impossible to review; the problem is in figuring out which codepaths
are hot enough to worry about them.  And I'm even more convinced that
bulk search-and-replace is the right approach here; we probably _can_ get
rid of that shit this cycle (or, at least, reduce its use to very few places
in arch/*), but that'll require some cooperation from architecture maintainers.


[PATCH] crypto: algapi: Use pr_err common logging style.

2017-05-13 Thread Karim Eshapa
Use more common error logging style.

Signed-off-by: Karim Eshapa 
---
 crypto/algapi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 9eed4ef..e4cc761 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -260,7 +260,7 @@ void crypto_alg_tested(const char *name, int err)
goto found;
}
 
-   printk(KERN_ERR "alg: Unexpected test result for %s: %d\n", name, err);
+   pr_err("alg: Unexpected test result for %s: %d\n", name, err);
goto unlock;
 
 found:
-- 
2.7.4



[PATCH linux-next] device-dax: fix BLOCK dependency

2017-05-13 Thread Fabian Frederick
commit ef51042472f5 ("block, dax: move "select DAX" from BLOCK to FS_DAX")
uses get_start_sect() which requires CONFIG_BLOCK

make allnoconfig + dax gives the following:

drivers/dax/super.c: In function 'bdev_dax_pgoff':
drivers/dax/super.c:50:26: error: implicit declaration of function
'get_start_sect' [-Werror=implicit-function-declaration]

Signed-off-by: Fabian Frederick 
---
 drivers/dax/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
index b79aa8f..1806628 100644
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -1,5 +1,6 @@
 menuconfig DAX
tristate "DAX: direct access to differentiated memory"
+   depends on BLOCK
select SRCU
default m if NVDIMM_DAX
 
-- 
2.9.3



Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Linus Torvalds
On Sat, May 13, 2017 at 11:04 AM, Al Viro  wrote:
>
>
> My point is, this stuff needs looking at.

No.

You don't have a point. I've tried to explain that there's no
performance difference, and there is no way in hell that the current
"__" versions are better.

So what's the point in looking? All you are ever going to come up with
is theoretical "this might" cases.

The only sane forward is to just get rid of them. At that point, you
*may* end up actually noticing something, but if you do, it's not a
"you might" issue.

There's literally no upside to this "needs looking at". There are only
downsides.

And one major downside of your "needs looking at". is this one:

From: Linus Torvalds 
Date: Tue, 24 Mar 2015 10:42:18 -0700
>
> So I'd suggest we should just do a wholesale replacement of
> __copy_to/from_user() with the non-underlined cases. Then, we could
> switch insividual ones back - with reasoning of why they matter, and
> with pointers to how it does access_ok() two lines before.
>
> We should probably even consider looking at __get_user/__put_user().
> Few of them are actually performance-critical.

Look at that date. It's over two years ago. In the intervening two
years, how many of those conversions have happened?

Here's a hint: it's a very very round number.

 Linus


Re: [PATCH v6 3/5] test: add new driver_data load tester

2017-05-13 Thread Luis R. Rodriguez
On Fri, May 12, 2017 at 05:52:18PM +0200, Luis R. Rodriguez wrote:
> On Fri, May 12, 2017 at 09:20:24AM +0900, AKASHI Takahiro wrote:
> > On Thu, May 11, 2017 at 08:26:29PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> > > > On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > > > > diff --git a/tools/testing/selftests/firmware/driver_data.sh 
> > > > > > > b/tools/testing/selftests/firmware/driver_data.sh
> > > > > ...
> > > > > > > +ALL_TESTS="$ALL_TESTS 0012:1:1"
> > > > > > > +ALL_TESTS="$ALL_TESTS 0013:1:1"
> > > > > > 
> > > > > > Do you have good reasons for "the number of times" here?
> > > > > 
> > > > > Just that 1 was not enough and more than 10 seemed too much. As is 
> > > > > the tests
> > > > 
> > > > In my opinion, "1," or "2" given the nature of firmware caching, is good
> > > > enough, but it's up to you.
> > > 
> > > No, firmware caching deserves its own test unit on its own, but that will 
> > > be
> > > enabled through a separate test once we move 
> > > DRIVER_DATA_PRIV_REQ_NO_CACHE 
> > > to DRIVER_DATA_REQ_NO_CACHE (a private feature to a publicly available
> > > enabled feature). This will be enabled for the upcoming work which enables
> > > FGPA firmware upload which will first enable request_firmware_into_buf()
> > > through the driver data API which uses this.
> > 
> > I thought of implementing NO_CACHE option by myself, but came up with
> > no practical use cases other than my test case :)
> 
> FWIW, my understanding is that such work is underway. I think it may be
> ready first than your signature work so it may make sense to coordinate
> with that developer on their work as you might be able to make use of their
> tests, etc.
> 
> > > > BTW, firmware caching is a bit annoying in my signature tests
> > > > because caching will bypass the verification checks when we iterates
> > > > tests with different conditions.
> > > 
> > > It would seems to make sense to me to only need to verify files when read
> > > for the first time, once its cache I don't see why we would re-verify 
> > > them ?
> > 
> > Let me explain my test scenario:
> > case (a): firmware w/o signature for signature-not-required driver
> > case (b): firmware w/o signature for signature-required driver
> >... and so on
> > 
> > Case (a) and (b) are exercised with the same firmware blob but with
> > different 'test_config's of test_driver_data driver.
> > 
> > First do case (a) and it succeeds, caching the blob, then do case (b).
> > It should fail, but actually succeeds due to firmware caching.
> > 
> > Yes, we can change the order, (b) then (a), to make tests run correctly.
> 
> I see. OK we should consider if firmware requirements can ever vary for
> a file. If not then a cached firmware file can have a sig_check which
> any request can fill in. Upon request firmware, if the cache is present
> *but* the sig check requirements differ (in this simple case where
> signature requirements cannot vary) then the cache present will not
> suffice so we should allow a full new file check through to allow
> to fill the sig_check. If signatures requirements can vary then we
> could have a linked list of signature requirements and at cache check
> time we'd have to check if they match the requirements.
> 
> Just one way to try to address this I think. But hey this is all firmware
> signing related. I suppose a more relevant question to this thread is if
> there might be current criteria or criteria being introduced in this patch
> series which is similar to the signature check which should also be
> extended in these sorts of caching checks.
> 
> > But again, when we iterate this set of test cases under "-c" repeatedly,
> > this will happen again as you can imagine.
> 
> Makes sense.
> 
> > Thanks to firmware caching, each of iterations of tests is not executed
> > under the exactly same condition. That is the problem.
> 
> Sure, specially since asynchornous lookups won't be serialized we can't
> expect any proper order for which request goes in first. If the extra
> caching requirements were however taken into consideration I would expect
> this to not matter though.

Note that a bug was just opened on multiple fw requests and only one completes
fine, it sounds like a real bug, and if so sounds related to this topical case
you are testing against as well.

https://bugzilla.kernel.org/show_bug.cgi?id=195477

It has a proposed patch I have not yet had a chance to properly review / test:

https://bugzilla.kernel.org/attachment.cgi?id=256493=diff==1=raw

  Luis


Re: Threads stuck in zap_pid_ns_processes()

2017-05-13 Thread Eric W. Biederman
Guenter Roeck  writes:

> On 05/12/2017 01:03 PM, Eric W. Biederman wrote:
>> Guenter Roeck  writes:
>>
>>> Hi Eric,
>>>
>>> On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote:
 Guenter Roeck  writes:

> Hi Eric,
>
> On Fri, May 12, 2017 at 08:26:27AM -0500, Eric W. Biederman wrote:
>> Vovo Yang  writes:
>>
>>> On Fri, May 12, 2017 at 7:19 AM, Eric W. Biederman
>>>  wrote:
 Guenter Roeck  writes:

> What I know so far is
> - We see this condition on a regular basis in the field. Regular is
>   relative, of course - let's say maybe 1 in a Milion Chromebooks
>   per day reports a crash because of it. That is not that many,
>   but it adds up.
> - We are able to reproduce the problem with a performance benchmark
>   which opens 100 chrome tabs. While that is a lot, it should not
>   result in a kernel hang/crash.
> - Vovo proviced the test code last night. I don't know if this is
>   exactly what is observed in the benchmark, or how it relates to the
>   benchmark in the first place, but it is the first time we are 
> actually
>   able to reliably create a condition where the problem is seen.

 Thank you.  I will be interesting to hear what is happening in the
 chrome perfomance benchmark that triggers this.

>>> What's happening in the benchmark:
>>> 1. A chrome renderer process was created with CLONE_NEWPID
>>> 2. The process crashed
>>> 3. Chrome breakpad service calls ptrace(PTRACE_ATTACH, ..) to attach to 
>>> every
>>>   threads of the crashed process to dump info
>>> 4. When breakpad detach the crashed process, the crashed process stuck 
>>> in
>>>   zap_pid_ns_processes()
>>
>> Very interesting thank you.
>>
>> So the question is specifically which interaction is causing this.
>>
>> In the test case provided it was a sibling task in the pid namespace
>> dying and not being reaped.  Which may be what is happening with
>> breakpad.  So far I have yet to see kernel bug but I won't rule one out.
>>
>
> I am trying to understand what you are looking for. I would have thought
> that both the test application as well as the Chrome functionality
> described above show that there are situations where 
> zap_pid_ns_processes()
> can get stuck and cause hung task timeouts in conjunction with the use of
> ptrace().
>
> Your last sentence seems to suggest that you believe that the kernel might
> do what it is expected to do. Assuming this is the case, what else would
> you like to see ? A test application which matches exactly the Chrome use
> case ? We can try to provide that, but I don't entirely understand how
> that would change the situation. After all, we already know that it is
> possible to get a thread into this condition, and we already have one
> means to reproduce it.
>
> Replacing TASK_UNINTERRUPTIBLE with TASK_INTERRUPTABLE works for both the
> test application and the Chrome benchmark. The thread is still stuck in
> zap_pid_ns_processes(), but it is now in S (sleep) state instead of D,
> and no longer results in a hung task timeout. It remains in that state
> until the parent process terminates. I am not entirely happy with it
> since the processes are still stuck and may pile up over time, but at
> least it solves the immediate problem for us.
>
> Question now is what to do with that solution. We can of course apply
> it locally to Chrome OS, but I would rather have it upstream - especially
> since we have to assume that any users of Chrome on Linux, or more
> generically anyone using ptrace in conjunction with CLONE_NEWPID, may
> experience the same problem. Right now I have no idea how to get there,
> though. Can you provide some guidance ?

 Apologies for not being clear.  I intend to send a pull request with the
>>>
>>> No worries.
>>>
 the TASK_UINTERRUPTIBLE to TASK_INTERRUPTIBLE change to Linus in the
 next week or so with a Cc stable and an appropriate Fixes tag.  So the
 fix can be backported.

>>> Great, that is good to know.
>>>
 I have a more comprehensive change queued I will probably merge for 4.13
 already but it just changes what kind of zombies you see.  It won't
 remove the ``stuck'' zombies.

 So what I am looking for now is:
 Why are things getting stuck in your benchmark?

 -  Is it a userspace bug?

   In which case we can figure out what userspace (aka breakpad) needs
to do to avoid the problem.

>>> I spent some time trying to understand what breakpad is doing. I don't
>>> really see how it 

Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 07:04:13PM +0100, Al Viro wrote:

> My point is, this stuff needs looking at.  Even this quick look in arch/x86
> has shown several fairly different classes of that stuff, probably needing
> different approaches.  And that - on an architecture that had tons of TLC
> around signal delivery; I'm not saying that result is optimal (asm-goto sounds
> potentially useful there), but it had a lot of attention given to it...

BTW, even in arch/* they tend to nest.  E.g. arch/alpha has 133 callers
total.  Distribution by files:
 35 arch/alpha/kernel/osf_sys.c
 92 arch/alpha/kernel/signal.c
  1 arch/alpha/kernel/traps.c
  4 arch/alpha/lib/csum_partial_copy.c
  1 arch/alpha/mm/fault.c
Distribution by functions:
  1 osf_getdomainname() [1]
  2 osf_sigstack()
  2 get_tv32()
  2 put_tv32()
  4 get_it32()
  4 put_it32()
  2 osf_select()
 18 osf_wait4() [2]
  6 osf_sigaction()
 34 restore_sigcontext()
  1 do_sigreturn()
 42 setup_sigcontext()
  3 setup_frame()
  6 setup_rt_frame()
  1 dik_show_code() [3]
  2 csum_partial_cfu_aligned()
  2 csum_partial_cfu_src_aligned()
  1 do_page_fault() [4]

[1] insane, BTW - should be strnlen() + copy_to_user(); should report -EFAULT
on failure, while we are at it.
[2] with fairly disgusting use of set_fs() in the mix.
[3] would break with get_user() - it's oopser fetching code to printk.
[4] this:
/* As of EV6, a load into $31/$f31 is a prefetch, and never faults
   (or is suppressed by the PALcode).  Support that for older CPUs
   by ignoring such an instruction.  */
if (cause == 0) {
unsigned int insn;
__get_user(insn, (unsigned int __user *)regs->pc);
if ((insn >> 21 & 0x1f) == 0x1f &&
/* ldq ldl ldt lds ldg ldf ldwu ldbu */
(1ul << (insn >> 26) & 0x30f1400ul)) {
regs->pc += 4;
return;
}
}


Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread PGNet Dev

On 5/13/17 10:41 AM, Randy Dunlap wrote:

[adding HPET driver maintainer]


Thanks


A couple of comments below...



In BIOS, HPET's enabled.


How about if you just boot Linux without Xen?  Does HPET show up then?


yes, it appears so:

cat devices/system/clocksource/clocksource0/available
  tsc hpet acpi_pm


[8.491738] hpet_acpi_add: no address or irqs in _CRS


Above line marks a big failure. 
^^^


I suspected that's problematic.

In the non-Xen case

dmesg | grep -i hpet
  [0.00] ACPI: HPET 0x9E8298F8 38 (v01 SUPERM 
SMCI--MB 01072009 AMI. 0005)

  [0.00] ACPI: HPET id: 0x8086a701 base: 0xfed0
  [0.00] clocksource: hpet: mask: 0x max_cycles: 
0x, max_idle_ns: 133484882848 ns

  [0.00] hpet clockevent registered
  [0.144010] DMAR-IR: HPET id 0 under DRHD base 0xfed9
  [1.398047] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0, 0, 0, 0, 0
  [1.404226] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
  [1.412080] clocksource: Switched to clocksource hpet
  [3.627234] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes 
nvram, hpet irqs




Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 10:18:22AM -0700, Linus Torvalds wrote:

> > x86 actually tends to use get_user_ex/put_user_ex instead.
> 
> Yes. Because anybody who *really* cared about performance will have
> converted already. The real cost has been stac/clac for a few years
> now.

On x86.  Which has (not counting arch/x86/um, which definitely needs
a careful look - there __..._user() is the same as ..._user() and costly
as hell) all of 12 callers of __get_user() and 31 callers of __put_user().
More than a half of the latter - in cp_stat64() and I would at least try
and see if "convert on stack, then copy_to_user" is better for that one.
Other than that, all we have is:

arch/x86/entry/common.c:372:__get_user(*(u32 *)>bp,
arch/x86/ia32/ia32_signal.c:124:if (__get_user(set.sig[0], 
>sc.oldmask)
arch/x86/ia32/ia32_signal.c:275:if (__put_user(sig, >sig))
arch/x86/include/asm/xen/page.h:86: return __put_user(val, (unsigned long 
__user *)addr);
arch/x86/include/asm/xen/page.h:91: return __get_user(*val, (unsigned long 
__user *)addr);
arch/x86/kernel/fpu/signal.c:100:   err |= __get_user(xfeatures, (__u32 
*)>header.xfeatures);
arch/x86/kernel/fpu/signal.c:115:   err |= __put_user(xfeatures, (__u32 
*)>header.xfeatures);
arch/x86/kernel/fpu/signal.c:46:if (__get_user(magic2, (__u32 __user 
*)(fpstate + fx_sw->xstate_size))
arch/x86/kernel/fpu/signal.c:66:__put_user(xsave->i387.swd, 
>status) ||
arch/x86/kernel/fpu/signal.c:67:__put_user(X86_FXSR_MAGIC, 
>magic))
arch/x86/kernel/fpu/signal.c:72:if (__get_user(swd, >swd) 
|| __put_user(swd, >status))
arch/x86/kernel/fpu/signal.c:72:if (__get_user(swd, >swd) 
|| __put_user(swd, >status))
arch/x86/kernel/fpu/signal.c:93:err |= __put_user(FP_XSTATE_MAGIC2,
arch/x86/kernel/ptrace.c:1043:  if (__put_user(word, u++))
arch/x86/kernel/ptrace.c:1070:  ret = __get_user(word, u++);
arch/x86/kernel/ptrace.c:472:   if (__put_user(getreg(target, 
pos), u++))
arch/x86/kernel/ptrace.c:499:   ret = __get_user(word, u++);
arch/x86/kernel/signal.c:326:   if (__put_user(sig, >sig))
arch/x86/kernel/signal.c:347:   err |= __put_user(restorer, >pretcode);
arch/x86/kernel/signal.c:356:   err |= __put_user(*((u64 *)), (u64 
*)frame->retcode);
arch/x86/kernel/signal.c:613:   if (__get_user(set.sig[0], >sc.oldmask) 
|| (_NSIG_WORDS > 1
arch/x86/kernel/signal.c:647:   if (__get_user(uc_flags, >uc.uc_flags))
arch/x86/kernel/signal.c:870:   if (__get_user(uc_flags, >uc.uc_flags))
arch/x86/lib/csum-wrappers_64.c:103:*errp = 
__put_user(val16, (__u16 __user *)dst);
arch/x86/lib/csum-wrappers_64.c:45: if (__get_user(val16, 
(const __u16 __user *)src))

A bunch of strays in signal.c (extending ..._ex use might be a good idea)
xen_safe_{write,read}_ulong() (might very well break from adding access_ok() -
or be security holes; I'm not familiar enough with that code to tell) and
csum_partial_copy_{to,from}_user() - those would need to extend stac/clac
pairs already there and switch to unsafe_...

Plus several loops in ptrace - might or might not be sensitive, no idea.

Plus do_fast_syscall_32().  Might be sensitive, Andy would be the guy to
talk to, AFAICS.

> And some of the existing cases are just disgusting. There's no excuse
> for compat code or for ioctl to use the "__" versions. That seems to
> be the bulk of those uses too.

Sure.

My point is, this stuff needs looking at.  Even this quick look in arch/x86
has shown several fairly different classes of that stuff, probably needing
different approaches.  And that - on an architecture that had tons of TLC
around signal delivery; I'm not saying that result is optimal (asm-goto sounds
potentially useful there), but it had a lot of attention given to it...


Re: HPET enabled in BIOS, not presented as available_clocksource -- config, kernel code, &/or BIOS?

2017-05-13 Thread Randy Dunlap
[adding HPET driver maintainer]

A couple of comments below...


On 05/12/17 19:30, PGNet Dev wrote:
> I run kernel 4.11.0-4 on a Supermicro X10SAT motherboard.
> 
> HPET's enabled in BIOS, and apparently firmware table data is available.
> 
> But, hpet is not an available_clocksource.
> 
> Where's this need to be addressed/fixed?  In my config, in kernel code, &/or 
> in BIOS?
> 
> info:
> 
> @ the mobo,
> 
>   dmidecode
>   # dmidecode 3.0
>   Getting SMBIOS data from sysfs.
>   SMBIOS 2.7 present.
>   81 structures occupying 3317 bytes.
>   Table at 0x000EC200.
> 
>   Handle 0x, DMI type 0, 24 bytes
>   BIOS Information
>   Vendor: American Megatrends Inc.
>   Version: 3.0
>   Release Date: 05/26/2015
>   Address: 0xF
>   Runtime Size: 64 kB
>   ROM Size: 16384 kB
>   Characteristics:
>   PCI is supported
>   BIOS is upgradeable
>   BIOS shadowing is allowed
>   Boot from CD is supported
>   Selectable boot is supported
>   BIOS ROM is socketed
>   EDD is supported
>   5.25"/1.2 MB floppy services are supported (int 
> 13h)
>   3.5"/720 kB floppy services are supported (int 
> 13h)
>   3.5"/2.88 MB floppy services are supported (int 
> 13h)
>   Print screen service is supported (int 5h)
>   8042 keyboard services are supported (int 9h)
>   Serial services are supported (int 14h)
>   Printer services are supported (int 17h)
>   ACPI is supported
>   USB legacy is supported
>   BIOS boot specification is supported
>   Targeted content distribution is supported
>   UEFI is supported
>   BIOS Revision: 4.6
> 
> In BIOS, HPET's enabled.

How about if you just boot Linux without Xen?  Does HPET show up then?


> On boot to Xen on linux64
> 
>   xl info
>   release: 4.11.0-4.gcb15206-default
>   version: #1 SMP PREEMPT Thu May 11 07:36:09 UTC 
> 2017 (cb15206)
>   machine: x86_64
>   nr_cpus: 4
>   max_cpu_id : 3
>   nr_nodes   : 1
>   cores_per_socket   : 4
>   threads_per_core   : 1
>   cpu_mhz: 3092
>   hw_caps: 
> bfebfbff:77faf3ff:2c100800:0021:0001:27ab::0100
>   virt_caps  : hvm hvm_directio
>   total_memory   : 32493
>   free_memory: 25899
>   sharing_freed_memory   : 0
>   sharing_used_memory: 0
>   outstanding_claims : 0
>   free_cpus  : 0
>   xen_major  : 4
>   xen_minor  : 9
>   xen_extra  : .0_04-493
>   xen_version: 4.9.0_04-493
>   xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p 
> hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
>   xen_scheduler  : credit2
>   xen_pagesize   : 4096
>   platform_params: virt_start=0x8000
>   xen_changeset  :
>   xen_commandline: dom0_mem=4096M,max:4096M 
> dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga 
> console_timestamps console_to_ring conring_size=64 sched=credit2 sched_debug 
> reboot=acpi log_buf_len=16M iommu=verbose apic_verbosity=verbose loglvl=all 
> guest_loglvl=all noreboot=false sync_console=true
>   cc_compiler: gcc (SUSE Linux) 4.8.5
>   cc_compile_by  : abuild
>   cc_compile_domain  : suse.de
>   cc_compile_date: Wed May 10 21:26:38 UTC 2017
>   build_id   : dde541fac1512c7b1ce17e7496aab57a
>   xend_config_format : 4
> 
>   grep -i hpet /boot/config-4.11.0-4.gcb15206-default
>   CONFIG_HPET_TIMER=y
>   CONFIG_HPET_EMULATE_RTC=y
>   CONFIG_HPET=y
>   CONFIG_HPET_MMAP=y
>   CONFIG_HPET_MMAP_DEFAULT=y
> 
> 
> , dmesg reports
> 
>   dmesg | grep -i hpet
>   [0.00] Command line: root=/dev/mapper/VG0_ROOT rd.shell 
> 

Re: Is there an recommended way to refer to bitkeepr commits?

2017-05-13 Thread Rob Landley
On 05/12/2017 12:49 PM, Andreas Schwab wrote:
> On Mai 12 2017, Rob Landley  wrote:
> 
>> Last I checked I couldn't just "git push" the fullhist tree to
>> git.kernel.org because git graft didn't propagate right.
> 
> Perhaps you could recreate them with git replace --graft.  That creates
> replace objects that can be pushed and fetched.  (They are stored in
> refs/replace, and must be pushed/fetched explicitly.)

It's the "must be pushed/fetched explicitly" part that I couldn't figure
out back when I tried it.

I inherited this tree from somebody who made it. I noticed its existence
because lwn.net covered it, and then 6 months later it had vanished
without trace (as so many things do). I reproduced it from the build
script (if you can't reproduce the experiment from initial starting
conditions, it's not science), went "look, cool thing", and hosted a
copy with an occasional repaint.

I would be _thrilled_ to hand it off to somebody who knows what they're
doing with git. I'm just unusually interested in computer history and
the preservation thereof. (https://landley.net/history/mirror).

Rob


[PATCH] staging: atomisp: fix non static symbol warnings

2017-05-13 Thread Juan Antonio Pedreira Martos
Fix some unneeded exported symbols by marking them as static.
This was found with the 'sparse' tool.

Signed-off-by: Juan Antonio Pedreira Martos 
---
 .../media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 5b4506a71126..15409e96449d 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -436,7 +436,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int 
on)
return -EINVAL;
 }
 
-int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
@@ -455,7 +455,8 @@ int gmin_v1p2_ctrl(struct v4l2_subdev *subdev, int on)
 
return -EINVAL;
 }
-int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
+
+static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -491,7 +492,7 @@ int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
int ret;
@@ -527,7 +528,7 @@ int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int on)
return -EINVAL;
 }
 
-int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
+static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
 {
int ret = 0;
struct gmin_subdev *gs = find_gmin_subdev(subdev);
-- 
2.13.0



RE: [PATCH] mmc: core: Delete an error message for a failed memory allocation in three functions

2017-05-13 Thread Winkler, Tomas


> -Original Message-
> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
> Sent: Saturday, May 13, 2017 15:54
> To: linux-...@vger.kernel.org; Bojan Prtvar ; Linus
> Walleij ; Paul Burton ;
> Shawn Lin ; Ulf Hansson
> ; Uri Yanai ; Winkler,
> Tomas 
> Cc: LKML ; kernel-janit...@vger.kernel.org
> Subject: [PATCH] mmc: core: Delete an error message for a failed memory
> allocation in three functions
> 
> From: Markus Elfring 
> Date: Sat, 13 May 2017 14:40:08 +0200
> 
> Omit an extra message for a memory allocation failure in these functions.
> 
> This issue was detected by using the Coccinelle software.
> 
> Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-
> Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring 

Looks, OK to me.
Tomas

> ---
>  drivers/mmc/core/sd.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index
> d109634fbfce..1d7542daecbe 100644
> --- a/drivers/mmc/core/sd.c
> +++ b/drivers/mmc/core/sd.c
> @@ -294,12 +294,8 @@ static int mmc_read_switch(struct mmc_card *card)
>   err = -EIO;
> 
>   status = kmalloc(64, GFP_KERNEL);
> - if (!status) {
> - pr_err("%s: could not allocate a buffer for "
> - "switch capabilities.\n",
> - mmc_hostname(card->host));
> + if (!status)
>   return -ENOMEM;
> - }
> 
>   /*
>* Find out the card's support bits with a mode 0 operation.
> @@ -359,11 +355,8 @@ int mmc_sd_switch_hs(struct mmc_card *card)
>   return 0;
> 
>   status = kmalloc(64, GFP_KERNEL);
> - if (!status) {
> - pr_err("%s: could not allocate a buffer for "
> - "switch capabilities.\n", mmc_hostname(card-
> >host));
> + if (!status)
>   return -ENOMEM;
> - }
> 
>   err = mmc_sd_switch(card, 1, 0, 1, status);
>   if (err)
> @@ -596,11 +589,8 @@ static int mmc_sd_init_uhs_card(struct mmc_card
> *card)
>   return 0;
> 
>   status = kmalloc(64, GFP_KERNEL);
> - if (!status) {
> - pr_err("%s: could not allocate a buffer for "
> - "switch capabilities.\n", mmc_hostname(card-
> >host));
> + if (!status)
>   return -ENOMEM;
> - }
> 
>   /* Set 4-bit bus width */
>   if ((card->host->caps & MMC_CAP_4_BIT_DATA) &&
> --
> 2.12.3



[PATCH 1/2] ARM: dts: uniphier: fix simple-bus unit address format error

2017-05-13 Thread Masahiro Yamada
Compiling the UniPhier DT files with W=1, DTC warns like follows:

Warning (simple_bus_reg): Node 
/soc/system-bus@58c0/support_card@1,1f0/ethernet@ simple-bus 
unit address format error, expected "0"
Warning (simple_bus_reg): Node 
/soc/system-bus@58c0/support_card@1,1f0/uart@000b simple-bus unit 
address format error, expected "b"
Warning (simple_bus_reg): Node /soc/smpctrl@5980 simple-bus unit address 
format error, expected "59801000"

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4.dtsi  | 2 +-
 arch/arm/boot/dts/uniphier-pro4.dtsi | 2 +-
 arch/arm/boot/dts/uniphier-pro5.dtsi | 2 +-
 arch/arm/boot/dts/uniphier-pxs2.dtsi | 2 +-
 arch/arm/boot/dts/uniphier-sld3.dtsi | 2 +-
 arch/arm/boot/dts/uniphier-sld8.dtsi | 2 +-
 arch/arm/boot/dts/uniphier-support-card.dtsi | 4 ++--
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 4f5fe15..e608895 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -201,7 +201,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-pro4.dtsi
index 794a85a..f55708e 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -233,7 +233,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-pro5.dtsi
index 81605e3..9577769 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -320,7 +320,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi 
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index bc5a1af..bf3bafc 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -304,7 +304,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-sld3.dtsi 
b/arch/arm/boot/dts/uniphier-sld3.dtsi
index 01d77ed..7c9f41d 100644
--- a/arch/arm/boot/dts/uniphier-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-sld3.dtsi
@@ -216,7 +216,7 @@
#size-cells = <1>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi 
b/arch/arm/boot/dts/uniphier-sld8.dtsi
index eb06fdc..19aa139 100644
--- a/arch/arm/boot/dts/uniphier-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
@@ -201,7 +201,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi 
b/arch/arm/boot/dts/uniphier-support-card.dtsi
index f61dfec..fdbf0f6 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -53,14 +53,14 @@
#size-cells = <1>;
ranges = <0x 1 0x01f0 0x0010>;
 
-   ethsc: ethernet@ {
+   ethsc: ethernet@0 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <0x 0x1000>;
phy-mode = "mii";
reg-io-width = <4>;
};
 
-   serialsc: uart@000b {
+   serialsc: uart@b {
compatible = "ns16550a";
reg = <0x000b 0x20>;
clock-frequency = <12288000>;
-- 
2.7.4



[PATCH 2/2] arm64: dts: uniphier: fix simple-bus unit address format error

2017-05-13 Thread Masahiro Yamada
Compiling the UniPhier DT files with W=1, DTC warns like follows:

Warning (simple_bus_reg): Node /soc/smpctrl@5980 simple-bus unit address 
format error, expected "59801000"

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index dc0cd94..20bea49 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -268,7 +268,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index c7bd006..4b856af 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -337,7 +337,7 @@
pinctrl-0 = <_system_bus>;
};
 
-   smpctrl@5980 {
+   smpctrl@59801000 {
compatible = "socionext,uniphier-smpctrl";
reg = <0x59801000 0x400>;
};
-- 
2.7.4



[PATCH] arch: remove GENERIC_FIND_FIRST_BIT

2017-05-13 Thread Yury Norov
This option, if disabled, is used to alias find_first_bit() to 
find_next_bit() with the trivial macro:
#define find_first_bit(addr, size) find_next_bit((addr), (size), 0)

And the same for find_first_zero_bit().

The problem here is that the implementation of find_next_bit() is more
complex, and that extra complexity is not really needed if the offset
that passed to find_next_bit() is known to be 0.

This patch removes GENERIC_FIND_FIRST_BIT and drops the alias to 
find_next_bit().
Architectures that enable GENERIC_FIND_FIRST_BIT will be obviously not affected
with this change. Namely, arc, s390, tile, unicore32 and x86. Some architectures
implement their own implementations, so they are not affected too. They are: 
arm,
m68k, unicore32. (Unicore32 both enables the CONFIG_GENERIC_FIND_FIRST_BIT and 
has
custom implementation for it.) Others will switch to separate implementation.

Tested on arm64.

There is a couple of patches in the kernel that remove similar config options:
63e424c84429 ("arch: remove CONFIG_GENERIC_FIND_{NEXT_BIT,BIT_LE,LAST_BIT}") and
65af3a3f89d7 ("arch: remove CONFIG_GENERIC_FIND_NEXT_BIT again"), but the
GENERIC_FIND_FIRST_BIT is the last one that still there. So this path finishes
the work.

Signed-off-by: Yury Norov 
---
 arch/arc/Kconfig  | 1 -
 arch/s390/Kconfig | 1 -
 arch/tile/Kconfig | 1 -
 arch/unicore32/Kconfig| 1 -
 arch/x86/Kconfig  | 1 -
 arch/x86/um/Kconfig   | 1 -
 include/asm-generic/bitops/find.h | 8 
 lib/Kconfig   | 3 ---
 8 files changed, 17 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index cab9c53e0354..ebc3b1cab103 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -17,7 +17,6 @@ config ARC
select COMMON_CLK
select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC)
select GENERIC_CLOCKEVENTS
-   select GENERIC_FIND_FIRST_BIT
# for now, we don't need GENERIC_IRQ_PROBE, CONFIG_GENERIC_IRQ_CHIP
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index e7ff58150e8f..a3e61ca22d73 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -119,7 +119,6 @@ config S390
select GENERIC_CLOCKEVENTS
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_DEVICES if !SMP
-   select GENERIC_FIND_FIRST_BIT
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 845dcbd8235e..423817d88b8c 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -10,7 +10,6 @@ config TILE
select CC_OPTIMIZE_FOR_SIZE
select EDAC_SUPPORT
select GENERIC_CLOCKEVENTS
-   select GENERIC_FIND_FIRST_BIT
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select GENERIC_PENDING_IRQ if SMP
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index 9629fd827d6b..c1ba1c95bd32 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -13,7 +13,6 @@ config UNICORE32
select HAVE_KERNEL_LZMA
select VIRT_TO_BUS
select ARCH_HAVE_CUSTOM_GPIO_H
-   select GENERIC_FIND_FIRST_BIT
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ead9e32744c7..abccd8ecb275 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -86,7 +86,6 @@ config X86
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
-   select GENERIC_FIND_FIRST_BIT
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 8436bcd9beba..fa93329042c4 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -12,7 +12,6 @@ endmenu
 
 config UML_X86
def_bool y
-   select GENERIC_FIND_FIRST_BIT
 
 config 64BIT
bool "64-bit kernel" if SUBARCH = "x86"
diff --git a/include/asm-generic/bitops/find.h 
b/include/asm-generic/bitops/find.h
index 998d4d544f18..790b333cff8b 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -29,8 +29,6 @@ extern unsigned long find_next_zero_bit(const unsigned long 
*addr, unsigned
long size, unsigned long offset);
 #endif
 
-#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
-
 /**
  * find_first_bit - find the first set bit in a memory region
  * @addr: The address to start the search at
@@ -52,11 +50,5 @@ extern unsigned long find_first_bit(const unsigned long 
*addr,
  */
 extern unsigned long find_first_zero_bit(const unsigned long *addr,
 unsigned long size);
-#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
-
-#define find_first_bit(addr, size) 

Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Linus Torvalds
On Sat, May 13, 2017 at 10:00 AM, Al Viro  wrote:
> On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote:
>> > IOW, we have
>> > * most of users in arch/* (heavily dominated by signal-related 
>> > code,
>> > both loads and stores).  Those need careful massage; maybe unsafe-based
>> > solution, maybe something else, but it's obviously per-architecture work
>> > and these paths are sensitive.
>>
>> Why are they sensitive?
>
> Because there we do have tons of back-to-back __get_user() (on sigreturn())
> or __put_user() (on signal setup).

It doesn't actually matter. Regular "put_user()" doesn't generate
noticeably worse code.

It's not a normal function call, it's still an inline asm - so it
basically generates the exact same code as __xyz_user(), except it's a
call to a fixed copy of the code.

So the only difference tends to be
 (a) the extra call/ret instructions, possibly frame pointers
 (b) fixed registers
 (c) the added addr_limit checks

but (a) is cheap, and (b) isn't a big deal since with "asm volatile"
you can't re-order those things against each other anyway. So (b) ends
up being approximately the cost of "one extra lea instruction" for the
address generation that would otherwise be in the load/store
instruction.

And (c) is actually a reason *for* doing it. We've had bugs due to
people not getting it right.

So there really is basically no performance downside.  Even with
consecutive uses.  The code that uses a function call might even be
smaller (ie the 1.7kB savings isn't necessarily all in the out-of-line
exception handling cases: the stac/clac instructions are six bytes for
each use, so it more than makes up for the call instruction).

> x86 actually tends to use get_user_ex/put_user_ex instead.

Yes. Because anybody who *really* cared about performance will have
converted already. The real cost has been stac/clac for a few years
now.

So we pretty much know that none of the remaining users are really all
that critical. Certainly not "five cycles" kind of critical.

>> Anybody who *relies* on not checking the address_limit is so broken as
>> to be not even funny.
>
> Except for open-coded probe_kernel_read() somewhere in arch/*; I have not
> read through those 700+ callers, so I don't know if there's any such.

.. and those need to be fixed.

But I'm not seeing the point in wasting valuable human time in reading
through thousands of cases, when we can just automate it and see if
anything breaks.

Because it will break in a *safe* direction. You'll get an error from
bad uses that shouldn't have worked to begin with.

And some of the existing cases are just disgusting. There's no excuse
for compat code or for ioctl to use the "__" versions. That seems to
be the bulk of those uses too.

 Linus


Re: Is there an recommended way to refer to bitkeepr commits?

2017-05-13 Thread Rob Landley
On 05/13/2017 04:35 AM, Thomas Gleixner wrote:
> On Fri, 12 May 2017, Eric W. Biederman wrote:
>> Which leaves me perplexed.  The hashes from tglx's current tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
>> on kernel.org and the hashes in your full history tree differ.
>> Given that they are in theory the same tree this distrubs me.

The original build script used to make fullhist is at:

  http://landley.net/kdocs/fullhist/make-full-linux-history.tgz

And his original description of what he did and why is at:

  https://lwn.net/Articles/285366/

He mentioned something about rewriting dates?

  I used the "graft" feature of git (thanks to Junio and people
  on #git for the tip) to link them together. I also modified
  (via a git-filter-branch) the dates of some commits as for
  instance all commits from the Dave Jones's repo had the
  same date (23 Nov 2007). For this I mainly used the timestamp info
  of files on kernel.org. The script and info I used are also
  available on my website[2].

(I tried to read his conversion plumbing but it's in ocaml.)

Apparently he only considered the git commits in Linus's tree to be
worth preserving. I'd forgotten that part. (It was 9 years ago. I
remembered the pre-bitkeeper tree got edited but I forgot the other one
did too.)

>> Case in point in the commit connected to:
>> "[PATCH] linux-2.5.66-signal-cleanup.patch"
>> in tglx's tree is:   da334d91ff7001d234863fc7692de1ff90bed57a
> 
> That's the proper sha1 for my tree. I jsut verified it against the original
> tree which I still have in my archive.
> 
>> *scratches my head*
>>
>> Something appears to have changed somewhere.
> 
> Correct. That full history git rewrote the commits in my bitkeeper import.

I only checked that the current ones in Linus's tree were the same.
Nobody'd ever pointed me at a file hash in your conversion of bitkeeper
to git, so over the years I forgot that the date editing extended into
bitkeeper for some reason.

> history.git:
> 
>   commit 7a2deb32924142696b8174cdf9b38cd72a11fc96
>   Author: Linus Torvalds 
>   Date:   Mon Feb 4 17:40:40 2002 -0800
> 
> Import changeset

February 4, 2002.

> full-history:
> 
>   commit 26245c315da55330cb25dbfdd80be62db41dedb2
>   Author: linus1 
>   Date:   Thu Jan 4 12:00:00 2001 -0600
> 
> Import changeset

January 4, 2001.

According to https://www.kernel.org/pub/linux/kernel/v2.4/ January 4
2001 is when 2.4.0 was released. So yes, it looks like he rewrote these
dates to be correct.

I see what he did. Linus started his bitkeeper tree by importing 2.4.0
and then applying a year's worth of release diffs from 2.4.0 as
individual commits. That year+ worth of work was all dated February 4,
2002 in the repo, so the fullhist script went through and changed the
dates on those commits to match the release tarballs for those kernel
versions, and that changed the hashes in the rest of the history tree.

Upside, there's no longer a year+ hole in the commit dates (which makes
looking up associated mailing list posts a lot easier). Downside: this
changed the history.git commit hashes for the rest of that era. (I'd
missed that.)

> and as a consequence all other commits have different shas as well.

The most embarassing part is that the ocaml plumbing appears to
occasionally leak host context when doing the conversion, specifically
from "git log 26245c315da5" (checking to make sure the fullhist tree's
dates make sense in context) I get:

commit 26245c315da55330cb25dbfdd80be62db41dedb2
Author: linus1 
Date:   Thu Jan 4 12:00:00 2001 -0600

Import changeset

commit 13a80dffb74939e292b6e90e5d79dd26d577489f
Author: linus1 
Date:   Thu Jan 4 12:00:00 2001 -0600

add prerelease patch to get a 2.4.0

commit 4c5b4d50bb08753433f5962bd926198fe2b7105d
Author: linus1 
Date:   Sun Dec 31 12:00:00 2000 -0600

That landley@driftood should not be there. Sigh.

I guess the question is which is more broken? I linked the build scripts
above if somebody else wants to modify or rerun them, but... lithp. Do
you prefer a year gap in the archive dates, or do you prefer to call the
history.git hashes cannonical?

Rob


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 06:00:56PM +0100, Al Viro wrote:

> > But I don't see the excuse for not just doing it. If nobody notices,
> > it's an obvious improvement. And if somebody *does* notice, we know
> > how to do it properly with unsafe_xyz_user(), because "__xyz_user()"
> > most definitely isn't it.
> 
> I think we ought to actually look through those places - there are few
> enough of them (outside of arch/, that is) and stac/clac overhead is
> not the only problem they tend to have.

PS: just to make it clear - I do _not_ propose to keep that shit around
indefinitely; I want __get_user()/__put_user() gone by the end of that
work.


Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 09:15:07AM -0700, Linus Torvalds wrote:
> > IOW, we have
> > * most of users in arch/* (heavily dominated by signal-related code,
> > both loads and stores).  Those need careful massage; maybe unsafe-based
> > solution, maybe something else, but it's obviously per-architecture work
> > and these paths are sensitive.
> 
> Why are they sensitive?

Because there we do have tons of back-to-back __get_user() (on sigreturn())
or __put_user() (on signal setup).

> Why not just do this:
> 
>   git grep -l '\<__\(\(get\)\|\(put\)\)_user(' -- arch/x86
> :^arch/x86/include/asm/uaccess.h
> | xargs sed -i 's/__\(\(\(get\)\|\(put\)\)_user(\)/\1/g'
> 
> which converts all the x86 uses in one go.

x86 actually tends to use get_user_ex/put_user_ex instead.

> Anybody who *relies* on not checking the address_limit is so broken as
> to be not even funny.

Except for open-coded probe_kernel_read() somewhere in arch/*; I have not
read through those 700+ callers, so I don't know if there's any such.
Sure, those won't be performance-sensitive.

> And anything that is so performance-sensitive
> that anybody can even measure the effect of the above we can convert
> later.

> Sure, do it in pieces (eg each architecture separately, then
> "drivers", then "networking", then whatever, until all done), just so
> that *if* something actually depends on semantics (and that really
> shouldn't be the case), we have at least some information from a
> bisect.
>
> But I don't see the excuse for not just doing it. If nobody notices,
> it's an obvious improvement. And if somebody *does* notice, we know
> how to do it properly with unsafe_xyz_user(), because "__xyz_user()"
> most definitely isn't it.

I think we ought to actually look through those places - there are few
enough of them (outside of arch/, that is) and stac/clac overhead is
not the only problem they tend to have.


[PATCH v2] staging: ccree: Fix blank lines codestyle issue

2017-05-13 Thread Alexander Mazyrin
Checkpatch emits CHECK: Please don't use multiple blank lines.

Remove multiple blank lines.

Signed-off-by: Alexander Mazyrin 
---
 drivers/staging/ccree/ssi_aead.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 0382917..c1ddd7f 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -2827,6 +2827,3 @@ int ssi_aead_alloc(struct ssi_drvdata *drvdata)
 fail0:
return rc;
 }
-
-
-
-- 
2.1.4



Re: [git pull] uaccess-related bits of vfs.git

2017-05-13 Thread Al Viro
On Sat, May 13, 2017 at 02:05:27PM +0200, Adam Borowski wrote:

> As someone from the peanuts gallery, I took a look for __put_user() in my
> usual haunt, drivers/tty/vt/
> 
> * use 1: con_[gs]et_trans_*():
>   Copies a linear array of 256 bytes/shorts, one by one.
>   The obvious patch has 9 insertions(+), 22 deletions(-).
> 
> * use 2: con_[gs]et_unimap():
>   Ditto, up to 65535*2 shorts, also in a nice linear array.
> 
> * use 3: tioclinux():
>   Does a __put into a place that was checked only for read.  This got me
>   frightened as it initially looked like something that can allow an user to
>   write where they shouldn't.  Fortunately, it turns out the first argument
>   to access_ok() is ignored on every single architecture -- why does it even
>   exist then?  I imagined it's there for some odd arch that allows writes
>   when in privileged mode, but unlike what the docs say, VERIFY_WRITE is
>   exactly same as VERIFY_READ.

It's a remnant of old kludge that never properly worked in the first place.
access_ok() should have been called userland_range() - that's all it
checks and that's all it *can* check.

As it is, each of those __get_user() can bloody well yield -EFAULT.  Despite
having "passed" access_ok().  Again, the only thing access_ok() checks is
that (on architecture with shared address space for userland and kernel)
the addresses given are on the userland side.  That's _it_ - they can
be unmapped, mmapped to broken floppy, whatever; you'll find out when
you try to actually copy bytes from from it.

What the kludge used to attempt was "let's check that we are not trying
to copy into read-only mmapped area - 80386 MMU is fucked in head and won't
fault on such stores in ring 0".  It had always been racy.  Look:
thread A: going to copy something to user-supplied address.  Do access_ok().
thread A: looks like it's mapped writable, let's go ahead and copy
thread A: do something blocking before actually doing __put_user() or
__copy_to_user() or whatever it's going to be.
thread B: munmap(), mmap() something read-only here.
thread A: get to actual __put_user()/__copy_to_user().
80386: hey, it's ring 0, no need to look at the write protect bit in page
tables.  What can go wrong, anyway?

You can't move any non-static checks to access_ok().  On any architecture.
Anything that could change between access_ok() and actual copying can't
be checked in access_ok().  As it is, access_ok() has actively misleading
calling conventions:
* the name implies that having passed access_ok() you don't have
to worry about EFAULT
* 'direction' argument of that thing reinforces that impression
*and* has to be produced by the caller.  Most simply pass a constant,
which immediately gets dropped (as an aside, take a look at 4b4554f6d - it's
amusing), but in some cases it's calculated elsewhere and carefully passed
through several levels of call chain.  Only to be discarded by access_ok(),
of course...

> Ie, every use in this sample is wrong.  I suspect the rest of the kernel
> should be similar.

Looking through vt...

* con_set_trans_old(): copy_from_user() + loop for doing or with
  UNI_DIRECT_BASE.  Almost certainly will be faster that way - on *any*
  architecture.
* con_get_trans_old(): copy_to_user() would be an obvious optimization.
* con_set_trans_new(): copy_from_user().
* con_get_trans_new(): copy_to_user().
* con_set_unimap(): memdup_user() instead of the entire kmalloc_array +
loop copying the sucker member by member.  With ushort ct you don't need
overflow-related logics of kmalloc_array() anyway...
* con_get_unimap(): copy_to_user() + put_user() (for uct)
* set_selection(): just copy_from_user() into local struct tiocl_selection.
* tioclinux(): use put_user().  Yes, you will repeat the same check twice.
Once per ioctl(), that involves enough work to make that "recalculate
access_ok() once for no reason" non-issue on any architecture.
* vt_ioctl(): turn that ushort ll,cc,vlin,clin,vcol,ccol; into
  struct vt_consize size; or something like that and use copy_from_user()

And AFAICS you can lose each and every access_ok() call in there.


Re: [PATCH 2/2] ARM: davinci: PM: Do not free useful resources in normal path in 'davinci_pm_init'

2017-05-13 Thread Christophe JAILLET

Le 13/05/2017 à 15:22, walter harms a écrit :


Am 13.05.2017 13:40, schrieb Christophe JAILLET:

This looks spurious to iounmap resources in the normal path of this init
function.
The 3 ioremap'ed fields of 'pm_config' can be accessed later on in other
functions, so it is likely that we should return 'success' before unrolling
everything.

Fixes: aa9aa1ec2df6 ("ARM: davinci: PM: rework init, remove platform device")
Signed-off-by: Christophe JAILLET 
---
This patch is just a *guess*. The end of the function looks more like a
error handling code rather than a normal path.
---
  arch/arm/mach-davinci/pm.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index d282b0783ecf..163d865abbf9 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -161,6 +161,7 @@ int __init davinci_pm_init(void)
davinci_cpu_suspend_sz);
  
  	suspend_set_ops(_pm_ops);

+   return 0;
  
  no_sram_mem:

iounmap(pm_config.ddrpsc_reg_base);


looks like, but that would mean that is wrong also:

davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
if (!davinci_sram_suspend) {
pr_err("PM: cannot allocate SRAM memory\n");
return -ENOMEM;
}

what means 1 iounmap missing.

re,
  wh


This is what I try to fix in the [1/2] patch.

CJ



  1   2   3   >