Dear Friend,
Dear Friend, I am Mrs Clara David. am sending you this brief letter to solicit your partnership to transfer $18.5 million US Dollars.I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box (mrsclarada...@gmail.com) as i wait to hear from you. Best regard Mrs Clara David.
[PATCH] csky: remove deprecated arch/csky/boot/dts/include/dt-bindings
Having a symbolic link arch/*/boot/dts/include/dt-bindings was
deprecated by commit d5d332d3f7e8 ("devicetree: Move include
prefixes from arch to separate directory").
Signed-off-by: Masahiro Yamada
---
arch/csky/boot/dts/include/dt-bindings | 1 -
1 file changed, 1 deletion(-)
delete mode 12 arch/csky/boot/dts/include/dt-bindings
diff --git a/arch/csky/boot/dts/include/dt-bindings
b/arch/csky/boot/dts/include/dt-bindings
deleted file mode 12
index 08c00e4..000
--- a/arch/csky/boot/dts/include/dt-bindings
+++ /dev/null
@@ -1 +0,0 @@
-../../../../../include/dt-bindings
\ No newline at end of file
--
2.7.4
Re: use generic DMA mapping code in powerpc V4
On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote: > OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use > the dma_direct mapping routines) > > git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a > > git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b > > Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet > doesn't work. Are there any interesting messages in the boot log? Can you send me the dmesg?
Re: [PATCH V9 4/5] i2c: tegra: update transfer timeout
On Fri, Feb 01, 2019 at 07:37:45PM +, Sowjanya Komatineni wrote: > > > > BYTES_PER_FIFO_WORD 4 > > > > > > #define I2C_CNFG 0x000 > > > @@ -893,8 +892,9 @@ static int tegra_i2c_issue_bus_clear(struct > > > tegra_i2c_dev *i2c_dev) > > > i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG); > > > tegra_i2c_unmask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE); > > > > > > - time_left = wait_for_completion_timeout(_dev->msg_complete, > > > - TEGRA_I2C_TIMEOUT); > > > + time_left = wait_for_completion_timeout( > > > + _dev->msg_complete, > > > + msecs_to_jiffies(1000)); > > > > So potentially tegra_i2c_xfer_msg() could take more than 1 second > > and then fail with -EAGAIN, correct? In that case we should set > > adapter.timeout in probe to a larger value: > > > Bus clear pulse threshold we are setting is 9 (default as per spec) so > bus clear should happen after finishing sending of 9 pulses. > So 1sec is very long time for bus to get released and in case of ARB > LOST whole transfer to return EAGAIN will be much less then 1sec What if for example we have a very long transfer, say some 64 KiB on Tegra194 and about 95% through the transfer something causes the bus to lock up. The transfer so far would've taken something on the order of 5 seconds, but we'd still fail, potentially with -EAGAIN, right? Or is there some other mechanism that would prevent the above from happening? Thierry signature.asc Description: PGP signature
[PATCH v2] cpufreq: tegra124: add missing of_node_put()
of_cpu_device_node_get() will increase the refcount of device_node,
it is necessary to call of_node_put() at the end to release the
refcount.
Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124")
Cc: # 4.4+
Signed-off-by: Yangtao Li
---
v2:
- move of_node_put() to the very end
---
drivers/cpufreq/tegra124-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/tegra124-cpufreq.c
b/drivers/cpufreq/tegra124-cpufreq.c
index 43530254201a..4bb154f6c54c 100644
--- a/drivers/cpufreq/tegra124-cpufreq.c
+++ b/drivers/cpufreq/tegra124-cpufreq.c
@@ -134,6 +134,8 @@ static int tegra124_cpufreq_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
+ of_node_put(np);
+
return 0;
out_switch_to_pllx:
--
2.17.0
Re: [PATCH] staging: comedi: dt2811: fix integer overflow in multiply
On Sun, Feb 03, 2019 at 02:29:04PM +0300, Dan Carpenter wrote:
> > diff --git a/drivers/staging/comedi/drivers/dt2811.c
> > b/drivers/staging/comedi/drivers/dt2811.c
> > index 05207a519755..820e75f850ff 100644
> > --- a/drivers/staging/comedi/drivers/dt2811.c
> > +++ b/drivers/staging/comedi/drivers/dt2811.c
> > @@ -323,7 +323,8 @@ static unsigned int dt2811_ns_to_timer(unsigned int
> > *nanosec,
> > for (_mult = 0; _mult <= 7; _mult++) {
> > unsigned int div = dt2811_clk_dividers[_div];
> > unsigned int mult = dt2811_clk_multipliers[_mult];
> > - unsigned long long divider = div * mult;
> > + unsigned long long divider =
> > + (unsigned long long)div * mult;
>
> The max "div" can be is 12. The max "mult" can be is 10,000,000. So
> this is a false positive because there is no overflow. The code is not
> complicated. Unfortunately, Smatch has the exact same problem...
Smatch actually parses this correctly, but I had a power failure over
the weekend that messed up my results.
regards,
dan carpenter
Re: linux-next: build failure after merge of the drm-tegra tree
On Mon, Feb 04, 2019 at 11:12:41AM +1100, Stephen Rothwell wrote:
> Hi Thierry,
>
> After merging the drm-tegra tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/host1x/cdma.c: In function 'host1x_cdma_wait_pushbuffer_space':
> drivers/gpu/host1x/cdma.c:279:13: error: 'struct host1x_cdma' has no member
> named 'sem'
>down(>sem);
> ^~
>
> Caused by commit
>
> abb289796799 ("gpu: host1x: Use completion instead of semaphore")
>
> interacting with commit
>
> db5652be58a9 ("gpu: host1x: Introduce support for wide opcodes")
>
> I have used the drm-tegra tree from next-20190201 for today.
Oh my... so I go through all the build testing and then pull in the
seemlessly harmless fix and ruin everything...
I've fixed it up in my tree now, thanks.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH] cpufreq: tegra124: add missing of_node_put()
On Mon, Feb 04, 2019 at 01:35:01AM -0500, Yangtao Li wrote: > of_cpu_device_node_get() will increase the refcount of device_node, > it is necessary to call of_node_put() at the end to release the > refcount. > > Signed-off-by: Yangtao Li > --- > drivers/cpufreq/tegra124-cpufreq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/tegra124-cpufreq.c > b/drivers/cpufreq/tegra124-cpufreq.c > index 43530254201a..140a9266b64a 100644 > --- a/drivers/cpufreq/tegra124-cpufreq.c > +++ b/drivers/cpufreq/tegra124-cpufreq.c > @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct platform_device > *pdev) > goto out_put_pllx_clk; > } > > + of_node_put(np); > + > ret = tegra124_cpu_switch_to_dfll(priv); > if (ret) > goto out_put_pllp_clk; I think this needs to move to the very end of the function, for example after the call to platform_set_drvdata(), to avoid releasing it twice in error paths. Thierry signature.asc Description: PGP signature
Re: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail
On Mon, 4 Feb 2019 at 08:18, Ingo Molnar wrote:
>
>
> * Ard Biesheuvel wrote:
>
> > From: Sai Praneeth Prakhya
> >
> > efi_map_region() creates VA mappings for an given EFI region using any one
> > of the two helper functions (namely __map_region() and old_map_region()).
> > These helper functions *could* fail while creating mappings and presently
> > their return value is not checked. Not checking for the return value of
> > these functions might create issues because after these functions return
> > "md->virt_addr" is set to the requested virtual address (so it's assumed
> > that these functions always succeed which is not quite true). This
> > assumption leads to "md->virt_addr" having invalid mapping should any of
> > __map_region() or old_map_region() fail.
> >
> > Hence, check for the return value of these functions and if indeed they
> > fail, turn off EFI Runtime Services forever because kernel cannot
> > prioritize among EFI regions.
> >
> > This also fixes the comment "FIXME: add error handling" in
> > kexec_enter_virtual_mode().
> >
> > Signed-off-by: Sai Praneeth Prakhya
> > Cc: Borislav Petkov
> > Cc: Ingo Molnar
> > Signed-off-by: Ard Biesheuvel
> > ---
> > arch/x86/include/asm/efi.h | 6 +++---
> > arch/x86/platform/efi/efi.c| 21 +-
> > arch/x86/platform/efi/efi_32.c | 6 +++---
> > arch/x86/platform/efi/efi_64.c | 39 ++
> > 4 files changed, 48 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> > index 107283b1eb1e..a37378f986ec 100644
> > --- a/arch/x86/include/asm/efi.h
> > +++ b/arch/x86/include/asm/efi.h
> > @@ -125,12 +125,12 @@ extern pgd_t * __init efi_call_phys_prolog(void);
> > extern void __init efi_call_phys_epilog(pgd_t *save_pgd);
> > extern void __init efi_print_memmap(void);
> > extern void __init efi_memory_uc(u64 addr, unsigned long size);
> > -extern void __init efi_map_region(efi_memory_desc_t *md);
> > -extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
> > +extern int __init efi_map_region(efi_memory_desc_t *md);
> > +extern int __init efi_map_region_fixed(efi_memory_desc_t *md);
> > extern void efi_sync_low_kernel_mappings(void);
> > extern int __init efi_alloc_page_tables(void);
> > extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned
> > num_pages);
> > -extern void __init old_map_region(efi_memory_desc_t *md);
> > +extern int __init old_map_region(efi_memory_desc_t *md);
> > extern void __init runtime_code_page_mkexec(void);
> > extern void __init efi_runtime_update_mappings(void);
> > extern void __init efi_dump_pagetable(void);
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index e1cb01a22fa8..3d43ec58775b 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -581,7 +581,7 @@ void __init efi_memory_uc(u64 addr, unsigned long size)
> > set_memory_uc(addr, npages);
> > }
> >
> > -void __init old_map_region(efi_memory_desc_t *md)
> > +int __init old_map_region(efi_memory_desc_t *md)
> > {
> > u64 start_pfn, end_pfn, end;
> > unsigned long size;
> > @@ -601,10 +601,14 @@ void __init old_map_region(efi_memory_desc_t *md)
> > va = efi_ioremap(md->phys_addr, size,
> >md->type, md->attribute);
> >
> > - md->virt_addr = (u64) (unsigned long) va;
> > - if (!va)
> > + if (!va) {
> > pr_err("ioremap of 0x%llX failed!\n",
> > (unsigned long long)md->phys_addr);
> > + return -ENOMEM;
> > + }
> > +
> > + md->virt_addr = (u64)(unsigned long)va;
> > + return 0;
>
> Just wondering, shouldn't the failure path set ->virt_addr to something
> safe, just in case a caller doesn't check the error and relies on it?
>
> That's because in this commit we've now changed it from 0 to undefined.
>
Indeed. We don't usually rely on the value of ->virt_addr when
EFI_RUNTIME_SERVICES is unset, but there is some sysfs code, and
perhaps some other places where we do reference ->virt_addr, and not
assigning it at all is obviously wrong, and potentially hazardous.
> > +int __init efi_map_region_fixed(efi_memory_desc_t *md) { return 0; }
>
> Inline functions should be marked inline ...
>
> > if (efi_va < EFI_VA_END) {
> > - pr_warn(FW_WARN "VA address range overflow!\n");
> > - return;
> > + pr_err(FW_WARN "VA address range overflow!\n");
> > + return -ENOMEM;
> > }
> >
> > /* Do the VA map */
> > - __map_region(md, efi_va);
> > + if (__map_region(md, efi_va))
> > + return -ENOMEM;
> > +
> > md->virt_addr = efi_va;
> > + return 0;
>
> Same error return problem of leaving ->virt_addr undefined.
>
> Note that I also fixed up the grammar and readability of the changelog -
> see the updated version below.
>
> Thanks,
>
> Ingo
>
>
Re: [PATCH v2] Bluetooth: Add NULL check for tiocmget() and tiocmset()
On Sun, Feb 03, 2019 at 11:53:23AM +0100, Johan Hovold wrote:
> On Sat, Feb 02, 2019 at 10:38:24PM -0800, Myungho Jung wrote:
> > On Thu, Jan 31, 2019 at 04:40:00PM +0100, Johan Hovold wrote:
> > > On Tue, Jan 29, 2019 at 09:39:28PM -0800, Myungho Jung wrote:
> > > > tiocmget() and tiocmset() operations are optional and some tty drivers
> > > > like pty miss the operations. We need NULL check to prevent from
> > > > dereference.
> > > >
> > > > Signed-off-by: Myungho Jung
> > > > ---
> > > > drivers/bluetooth/hci_ath.c | 6 ++
> > > > drivers/bluetooth/hci_ldisc.c | 4
> > > > 2 files changed, 10 insertions(+)
> > >
> > > Ah, you had already submitted a v2.
> > >
> > > I still suggest splitting this one in two patches and that you add a
> > > Fixes and stable tag to each so that they both get backported to stable.
> > >
> > > Also, when resubmitting, make sure to include a short changelog here
> > > below the cut-off line (---).
> > >
> > > >
> > > > diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
> > > > index d568fbd94d6c..fb9f6323a911 100644
> > > > --- a/drivers/bluetooth/hci_ath.c
> > > > +++ b/drivers/bluetooth/hci_ath.c
> > > > @@ -185,8 +185,14 @@ static int ath_set_bdaddr(struct hci_dev *hdev,
> > > > const bdaddr_t *bdaddr)
> > > >
> > > > static int ath_setup(struct hci_uart *hu)
> > > > {
> > > > + struct tty_struct *tty = hu->tty;
> > > > +
> > > > BT_DBG("hu %p", hu);
> > > >
> > > > + /* tty driver should support operations to set RTS */
> > > > + if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset)
> > > > + return -EOPNOTSUPP;
> > >
> > > -ENODEV might be more appropriate.
> > >
> > > Johan
> >
> > I'll split into 2 seperate patches. So, do I need to add stable tag on each
> > patch like below to be cherry-picked?
> >
> > Cc: # :
> >
> > I looked for a good example from mailing list but didn't find one.
>
> Almost right, the format you use above is actually used to identify
> dependencies for backports.
>
> You should add a Fixes tag identifying the commit which introduced each
> bug and a stable-cc tag. If you want you can indicate the version after
> a # sign, but that can also be inferred from the fixes tag.
>
> For the hci_ldisc fix I think the tags would be:
>
> Fixes: 2a973dfada2b ("Bluetooth: hci_uart: Add new line discipline
> enhancements")
> Cc: stable # 4.2
>
> You can use git blame to track down the offending commits.
>
> This should all be explained here:
>
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
> Johan
Thank you for the explanation. I'll carefully read the page and submit the next
patch.
Thanks,
Myungho
Re: [PATCH] cpufreq: tegra124: add missing of_node_put()
On Mon, Feb 4, 2019 at 3:18 PM Viresh Kumar wrote:
>
> On 04-02-19, 15:00, Frank Lee wrote:
> > On Mon, Feb 4, 2019 at 2:36 PM Viresh Kumar wrote:
> > >
> > > On 04-02-19, 01:35, Yangtao Li wrote:
> > > > of_cpu_device_node_get() will increase the refcount of device_node,
> > > > it is necessary to call of_node_put() at the end to release the
> > > > refcount.
> > > >
> > > > Signed-off-by: Yangtao Li
> > > > ---
> > > > drivers/cpufreq/tegra124-cpufreq.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> > > > b/drivers/cpufreq/tegra124-cpufreq.c
> > > > index 43530254201a..140a9266b64a 100644
> > > > --- a/drivers/cpufreq/tegra124-cpufreq.c
> > > > +++ b/drivers/cpufreq/tegra124-cpufreq.c
> > > > @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct
> > > > platform_device *pdev)
> > > > goto out_put_pllx_clk;
> > > > }
> > > >
> > > > + of_node_put(np);
> > > > +
> > > > ret = tegra124_cpu_switch_to_dfll(priv);
> > > > if (ret)
> > > > goto out_put_pllp_clk;
> > >
> > > Fixes and stable tags ?
> > Hi viresh,
> >
> > Like this？
> >
> > Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124")
> > Cc: sta...@vger.kernel.org
>
> This needs to be something like:
>
> Cc: 4.5+ sta...@vger.kernel.org #4.5+
>
> Also I don't think your patch is entirely correct as we will end up
> doing of_node_put() twice in error path.
Thanks for your reminder, I will modify it immediately.
MBR,
Yangtao
>
> --
> viresh
Re: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail
* Ingo Molnar wrote: > Note that I also fixed up the grammar and readability of the changelog - > see the updated version below. > > Thanks, > > Ingo > > => > Subject: x86/efi: Return error status if mapping of EFI regions fails > From: Ard Biesheuvel > Date: Sat, 2 Feb 2019 10:41:11 +0100 > > From: Sai Praneeth Prakhya Also note that I left out this patch from the series for the time being under the assumption that it gets a v2 update. Since it has no dependencies in the remaining patches AFAICS I applied all the other patches to tip:efi/core. Thanks, Ingo
Re: [PATCH v10 1/3] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
On 18-01-19, 11:10, Long Cheng wrote:
> +static enum dma_status mtk_uart_apdma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie,
> + struct dma_tx_state *txstate)
> +{
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + enum dma_status ret;
> + unsigned long flags;
> +
> + if (!txstate)
> + return DMA_ERROR;
Why, it is not a mandatory arg!
> + ret = dma_cookie_status(chan, cookie, txstate);
> + spin_lock_irqsave(>vc.lock, flags);
> + if (ret == DMA_IN_PROGRESS) {
> + c->rx_status = mtk_uart_apdma_read(c, VFF_RPT) & VFF_RING_SIZE;
> + dma_set_residue(txstate, c->rx_status);
> + } else if (ret == DMA_COMPLETE && c->dir == DMA_DEV_TO_MEM) {
> + dma_set_residue(txstate, c->rx_status);
what is the point is setting residue to comleted txn, it is zero!
> + } else {
> + dma_set_residue(txstate, 0);
naah that doesnt sound correct!
> +static void mtk_uart_apdma_config_write(struct dma_chan *chan,
> +struct dma_slave_config *cfg,
> +enum dma_transfer_direction dir)
> +{
> + struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
> + struct mtk_uart_apdmadev *mtkd =
> + to_mtk_uart_apdma_dev(c->vc.chan.device);
> + unsigned int tmp;
> +
> + if (mtk_uart_apdma_read(c, VFF_EN) == VFF_EN_B)
> + return;
> +
> + c->dir = dir;
> +
> + if (dir == DMA_DEV_TO_MEM) {
> + tmp = cfg->src_addr_width * 1024;
why multiply by 1024?
> +static int mtk_uart_apdma_device_pause(struct dma_chan *chan)
> +{
> + /* just for check caps pass */
> + return 0;
> +}
please remove, this is not a mandatory fn
--
~Vinod
[tip:efi/core] x86/efi: Mark can_free_region() as an __init function
Commit-ID: 8fe55212aacfce9b7718de7964b3a3096ec30919
Gitweb: https://git.kernel.org/tip/8fe55212aacfce9b7718de7964b3a3096ec30919
Author: Sai Praneeth Prakhya
AuthorDate: Sat, 2 Feb 2019 10:41:10 +0100
Committer: Ingo Molnar
CommitDate: Mon, 4 Feb 2019 08:19:22 +0100
x86/efi: Mark can_free_region() as an __init function
can_free_region() is called only once during boot, by
efi_reserve_boot_services().
Hence, mark it as an __init function.
Signed-off-by: Sai Praneeth Prakhya
Signed-off-by: Ard Biesheuvel
Cc: AKASHI Takahiro
Cc: Alexander Graf
Cc: Bjorn Andersson
Cc: Borislav Petkov
Cc: Heinrich Schuchardt
Cc: Jeffrey Hugo
Cc: Lee Jones
Cc: Leif Lindholm
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20190202094119.13230-2-ard.biesheu...@linaro.org
Signed-off-by: Ingo Molnar
---
arch/x86/platform/efi/quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 17456a1d3f04..9ce85e605052 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -304,7 +304,7 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
* - Not within any part of the kernel
* - Not the BIOS reserved area (E820_TYPE_RESERVED, E820_TYPE_NVS, etc)
*/
-static bool can_free_region(u64 start, u64 size)
+static __init bool can_free_region(u64 start, u64 size)
{
if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
return false;
Re: [PATCH] cpufreq: tegra124: add missing of_node_put()
On 04-02-19, 15:00, Frank Lee wrote:
> On Mon, Feb 4, 2019 at 2:36 PM Viresh Kumar wrote:
> >
> > On 04-02-19, 01:35, Yangtao Li wrote:
> > > of_cpu_device_node_get() will increase the refcount of device_node,
> > > it is necessary to call of_node_put() at the end to release the
> > > refcount.
> > >
> > > Signed-off-by: Yangtao Li
> > > ---
> > > drivers/cpufreq/tegra124-cpufreq.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> > > b/drivers/cpufreq/tegra124-cpufreq.c
> > > index 43530254201a..140a9266b64a 100644
> > > --- a/drivers/cpufreq/tegra124-cpufreq.c
> > > +++ b/drivers/cpufreq/tegra124-cpufreq.c
> > > @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct
> > > platform_device *pdev)
> > > goto out_put_pllx_clk;
> > > }
> > >
> > > + of_node_put(np);
> > > +
> > > ret = tegra124_cpu_switch_to_dfll(priv);
> > > if (ret)
> > > goto out_put_pllp_clk;
> >
> > Fixes and stable tags ?
> Hi viresh,
>
> Like this？
>
> Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124")
> Cc: sta...@vger.kernel.org
This needs to be something like:
Cc: 4.5+ sta...@vger.kernel.org #4.5+
Also I don't think your patch is entirely correct as we will end up
doing of_node_put() twice in error path.
--
viresh
Re: [PATCH 02/10] x86/efi: Return error status if mapping EFI regions fail
* Ard Biesheuvel wrote:
> From: Sai Praneeth Prakhya
>
> efi_map_region() creates VA mappings for an given EFI region using any one
> of the two helper functions (namely __map_region() and old_map_region()).
> These helper functions *could* fail while creating mappings and presently
> their return value is not checked. Not checking for the return value of
> these functions might create issues because after these functions return
> "md->virt_addr" is set to the requested virtual address (so it's assumed
> that these functions always succeed which is not quite true). This
> assumption leads to "md->virt_addr" having invalid mapping should any of
> __map_region() or old_map_region() fail.
>
> Hence, check for the return value of these functions and if indeed they
> fail, turn off EFI Runtime Services forever because kernel cannot
> prioritize among EFI regions.
>
> This also fixes the comment "FIXME: add error handling" in
> kexec_enter_virtual_mode().
>
> Signed-off-by: Sai Praneeth Prakhya
> Cc: Borislav Petkov
> Cc: Ingo Molnar
> Signed-off-by: Ard Biesheuvel
> ---
> arch/x86/include/asm/efi.h | 6 +++---
> arch/x86/platform/efi/efi.c| 21 +-
> arch/x86/platform/efi/efi_32.c | 6 +++---
> arch/x86/platform/efi/efi_64.c | 39 ++
> 4 files changed, 48 insertions(+), 24 deletions(-)
>
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 107283b1eb1e..a37378f986ec 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -125,12 +125,12 @@ extern pgd_t * __init efi_call_phys_prolog(void);
> extern void __init efi_call_phys_epilog(pgd_t *save_pgd);
> extern void __init efi_print_memmap(void);
> extern void __init efi_memory_uc(u64 addr, unsigned long size);
> -extern void __init efi_map_region(efi_memory_desc_t *md);
> -extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
> +extern int __init efi_map_region(efi_memory_desc_t *md);
> +extern int __init efi_map_region_fixed(efi_memory_desc_t *md);
> extern void efi_sync_low_kernel_mappings(void);
> extern int __init efi_alloc_page_tables(void);
> extern int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned
> num_pages);
> -extern void __init old_map_region(efi_memory_desc_t *md);
> +extern int __init old_map_region(efi_memory_desc_t *md);
> extern void __init runtime_code_page_mkexec(void);
> extern void __init efi_runtime_update_mappings(void);
> extern void __init efi_dump_pagetable(void);
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e1cb01a22fa8..3d43ec58775b 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -581,7 +581,7 @@ void __init efi_memory_uc(u64 addr, unsigned long size)
> set_memory_uc(addr, npages);
> }
>
> -void __init old_map_region(efi_memory_desc_t *md)
> +int __init old_map_region(efi_memory_desc_t *md)
> {
> u64 start_pfn, end_pfn, end;
> unsigned long size;
> @@ -601,10 +601,14 @@ void __init old_map_region(efi_memory_desc_t *md)
> va = efi_ioremap(md->phys_addr, size,
>md->type, md->attribute);
>
> - md->virt_addr = (u64) (unsigned long) va;
> - if (!va)
> + if (!va) {
> pr_err("ioremap of 0x%llX failed!\n",
> (unsigned long long)md->phys_addr);
> + return -ENOMEM;
> + }
> +
> + md->virt_addr = (u64)(unsigned long)va;
> + return 0;
Just wondering, shouldn't the failure path set ->virt_addr to something
safe, just in case a caller doesn't check the error and relies on it?
That's because in this commit we've now changed it from 0 to undefined.
> +int __init efi_map_region_fixed(efi_memory_desc_t *md) { return 0; }
Inline functions should be marked inline ...
> if (efi_va < EFI_VA_END) {
> - pr_warn(FW_WARN "VA address range overflow!\n");
> - return;
> + pr_err(FW_WARN "VA address range overflow!\n");
> + return -ENOMEM;
> }
>
> /* Do the VA map */
> - __map_region(md, efi_va);
> + if (__map_region(md, efi_va))
> + return -ENOMEM;
> +
> md->virt_addr = efi_va;
> + return 0;
Same error return problem of leaving ->virt_addr undefined.
Note that I also fixed up the grammar and readability of the changelog -
see the updated version below.
Thanks,
Ingo
=>
Subject: x86/efi: Return error status if mapping of EFI regions fails
From: Ard Biesheuvel
Date: Sat, 2 Feb 2019 10:41:11 +0100
From: Sai Praneeth Prakhya
efi_map_region() creates VA mappings for a given EFI region using one
of the two helper functions (namely __map_region() and old_map_region()).
These helper functions could fail while creating mappings and presently
their return value is not checked.
Not checking for the return value of these functions might create bugs,
because after these
AW: [PATCH] iio: adc: at91: disable adc channel interrupt in timeout case
Actually this issue occurred to us with an concrete product, where we
experienced a system hang at -20 °C.
It was triggered by a race condition between the Touch Trigger and the Channel
Trigger of the ADC. Once triggered we got in to the situation where an ongoing
Channel Conversion was lost (Timeout case).When we queried a second channel
than we got a system hang. Investigating this issue we developed an error
demonstrator - reading alternating two channels as fast as possible (when Touch
is enabled). This also provokes this issue at room temperature.
For the error demonstrator use following commandline to compile:
$ arm-buildroot-linux-gnueabihf-gcc adc_demo_error.c -D2ND_CHANNEL -o
adc_demo_error2
-
// adc_demo_error.c
#include
#include
#define VLEN 10
int main()
{
int fd_adc,fd_adc2;
int ret;
char dummy[VLEN];
fd_adc = open
("/sys/devices/platform/ahb/ahb:apb/f8018000.adc/iio:device0/in_voltage4_raw",O_RDONLY);
#ifdef 2ND_CHANNEL
fd_adc2 = open
("/sys/devices/platform/ahb/ahb:apb/f8018000.adc/iio:device0/in_voltage5_raw",O_RDONLY);
#endif
while(1) {
lseek(fd_adc, 0, SEEK_SET);
ret = read(fd_adc, dummy, VLEN);
#ifdef 2ND_CHANNEL
lseek(fd_adc2, 0, SEEK_SET);
ret = read(fd_adc2, dummy, VLEN);
#endif
}
}
Greeting, Georg
-Ursprüngliche Nachricht-
Von: Jonathan Cameron [mailto:ji...@kernel.org]
Gesendet: Samstag, 02. Februar 2019 11:21
An: Georg Ottinger
Cc: eugen.hris...@microchip.com; Stefan Etzlstorfer ;
Hartmut Knaack ; Lars-Peter Clausen ; Peter
Meerwald-Stadler ; Nicolas Ferre
; Alexandre Belloni
; Ludovic Desroches
; David S. Miller ; Ard
Biesheuvel ; Kees Cook ;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-kernel@vger.kernel.org; Maxime Ripard
Betreff: Re: [PATCH] iio: adc: at91: disable adc channel interrupt in timeout
case
On Wed, 30 Jan 2019 14:42:02 +0100
wrote:
> From: Georg Ottinger
>
> Having a brief look at at91_adc_read_raw() it is obvious that in the
> case of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR
> registers is omitted. If 2 different channels are queried we can end
> up with a situation where two interrupts are enabled, but only one
> interrupt is cleared in the interrupt handler. Resulting in a
> interrupt loop and a system hang.
>
> Signed-off-by: Georg Ottinger
Whilst I agree this looks like a correct change, I would like Maxime to take a
look as he is obviously much more familiar with the driver than I am.
I suspect you can only actually get there in the event of a hardware failure as
that isn't actually a timeout you should ever see.
Could be wrong though!
Thanks,
Jonathan
> ---
> drivers/iio/adc/at91_adc.c | 28 +---
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 75d2f7358..596841a3c 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -704,23 +704,29 @@ static int at91_adc_read_raw(struct iio_dev *idev,
> ret = wait_event_interruptible_timeout(st->wq_data_avail,
> st->done,
> msecs_to_jiffies(1000));
> - if (ret == 0)
> - ret = -ETIMEDOUT;
> - if (ret < 0) {
> - mutex_unlock(>lock);
> - return ret;
> - }
> -
> - *val = st->last_value;
>
> + /* Disable interrupts, regardless if adc conversion was
> + * successful or not
> + */
> at91_adc_writel(st, AT91_ADC_CHDR,
> AT91_ADC_CH(chan->channel));
> at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
>
> - st->last_value = 0;
> - st->done = false;
> + if (ret > 0) {
> + /* a valid conversion took place */
> + *val = st->last_value;
> + st->last_value = 0;
> + st->done = false;
> + ret = IIO_VAL_INT;
> + } else if (ret == 0) {
> + /* conversion timeout */
> + dev_err(>dev, "ADC Channel %d timeout.\n",
> + chan->channel);
> + ret = -ETIMEDOUT;
> + }
> +
> mutex_unlock(>lock);
> - return IIO_VAL_INT;
> + return ret;
>
> case IIO_CHAN_INFO_SCALE:
> *val = st->vref_mv;
[PATCH v4] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
Counter values for per-channel interrupts and ring buffer full
conditions are useful for investigating performance.
Expose counters in sysfs for 2 types of guest to host interrupts:
1) Interrupts caused by the channel's outbound ring buffer transitioning
from empty to not empty
2) Interrupts caused by the channel's inbound ring buffer transitioning
from full to not full while a packet is waiting for enough buffer space to
become available
Expose 2 counters in sysfs for the number of times that write operations
encountered a full outbound ring buffer:
1) The total number of write operations that encountered a full
condition
2) The number of write operations that were the first to encounter a
full condition
Increment the outbound full condition counters in the
hv_ringbuffer_write() function because, for most drivers, a full
outbound ring buffer is detected in that function. Also increment the
outbound full condition counters in the set_channel_pending_send_size()
function. In the hv_sock driver, a full outbound ring buffer is detected
and set_channel_pending_send_size() is called before
hv_ringbuffer_write() is called.
I tested this patch by confirming that the sysfs files were created and
observing the counter values. The values seemed to increase by a
reasonable amount when the Hyper-v related drivers were in use.
Signed-off-by: Kimberly Brown
---
Changes in v4:
- In the commit message, added a paragraph describing why the full
condition counters are incremented in two functions.
- In the four new "_show" functions, added a cast to "(unsigned long
long)" in the sprintf() calls. This problem was reported by S.
Hemminger.
- In the vmbus_channel struct definition, moved the three new fields
pertaining to full ring buffers ("intr_in_full", "out_full_total",
"out_full_first") to the bottom of the struct. These fields should
not be used often because full ring buffers should not be encountered
often. This change addresses S. Hemminger's concern about the new
fields causing additional cache misses in the hot path.
- In the set_channel_pending_send_size() function, moved the
acquire/release of the spinlock to inside the if-statement. The
spinlock needs to protect only the incrementing variables. Since full
ring buffers should not be encountered often, the addition of this
spinlock acquire/release should not affect performance. This change
addresses S. Hemminger's concern that additional locking will affect
performance.
NOTE: S. Hemminger also requested that I consider placing the new bool
field, "out_full_flag", in a bitfield. I chose not to make this
change because setting an individual bit in a bitfield is less
efficient than setting the value of a bool.
Changes in v3:
- Used the outbound ring buffer spinlock to protect the the full
condition counters in set_channel_pending_send_size()
- Corrected the KernelVersion values for the new entries in
Documentation/ABI/stable/sysfs-bus-vmbus
Changes in v2:
- Added mailing lists to the cc list
- Removed the host to guest interrupt counters proposed in v1 because
they were not accurate
- Added full condition counters for the channel's outbound ring buffer
Documentation/ABI/stable/sysfs-bus-vmbus | 33 +
drivers/hv/ring_buffer.c | 14 +++-
drivers/hv/vmbus_drv.c | 36 +++
include/linux/hyperv.h | 46
4 files changed, 128 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
b/Documentation/ABI/stable/sysfs-bus-vmbus
index 3fed8fdb873d..826689dcc2e6 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -146,3 +146,36 @@ KernelVersion: 4.16
Contact: Stephen Hemminger
Description: Binary file created by uio_hv_generic for ring buffer
Users: Userspace drivers
+
+What: /sys/bus/vmbus/devices//channels//intr_in_full
+Date: February 2019
+KernelVersion: 5.0
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the inbound ring
+ buffer transitioning from full to not full while a packet is
+ waiting for buffer space to become available
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//intr_out_empty
+Date: February 2019
+KernelVersion: 5.0
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the outbound ring
+ buffer transitioning from empty to not empty
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//out_full_first
+Date: February 2019
+KernelVersion: 5.0
+Contact:Michael Kelley
+Description:Number of write operations that were the first to encounter an
+ outbound ring buffer full condition
+Users:
[PATCH] regulator: rk808: Convert rk805 buck1/2 to use linear range
It looks like linear range is suitable to describe the voltage table
for rk805 buck1/2:
selector 0 ~ 59: 0.7125V with uV_step = 12500
selector 60 ~ 62: 1.8V with uV_step = 20
selector 63: 2.3V
With this change, then rk805 buck1/2 can reuse rk808_reg_ops_ranges.
Signed-off-by: Axel Lin
---
Hi Otavio,
I don't have this h/w.
Please help review and test if this patch works.
Thanks,
Axel
drivers/regulator/rk808-regulator.c | 55 +++--
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 79e79cdd503b..23713e16c286 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -289,21 +289,6 @@ static int rk808_set_ramp_delay(struct regulator_dev
*rdev, int ramp_delay)
RK808_RAMP_RATE_MASK, ramp_value);
}
-static int rk805_set_suspend_voltage(struct regulator_dev *rdev, int uv)
-{
- unsigned int reg;
- int sel = regulator_map_voltage_ascend(rdev, uv, uv);
-
- if (sel < 0)
- return -EINVAL;
-
- reg = rdev->desc->vsel_reg + RK808_SLP_REG_OFFSET;
-
- return regmap_update_bits(rdev->regmap, reg,
- rdev->desc->vsel_mask,
- sel);
-}
-
static int rk808_set_suspend_voltage(struct regulator_dev *rdev, int uv)
{
unsigned int reg;
@@ -399,19 +384,6 @@ static const struct regulator_ops rk805_switch_ops = {
.set_suspend_disable= rk805_set_suspend_disable,
};
-static struct regulator_ops rk805_buck1_2_ops = {
- .list_voltage = regulator_list_voltage_table,
- .map_voltage= regulator_map_voltage_ascend,
- .get_voltage_sel= regulator_get_voltage_sel_regmap,
- .set_voltage_sel= regulator_set_voltage_sel_regmap,
- .enable = regulator_enable_regmap,
- .disable= regulator_disable_regmap,
- .is_enabled = regulator_is_enabled_regmap,
- .set_suspend_voltage= rk805_set_suspend_voltage,
- .set_suspend_enable = rk805_set_suspend_enable,
- .set_suspend_disable= rk805_set_suspend_disable,
-};
-
static const struct regulator_ops rk808_buck1_2_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
@@ -461,15 +433,10 @@ static const struct regulator_ops rk808_switch_ops = {
.set_suspend_disable= rk808_set_suspend_disable,
};
-static const int rk805_buck_1_2_voltages[] = {
- 712500, 725000, 737500, 75, 762500, 775000, 787500, 80,
- 812500, 825000, 837500, 85, 862500, 875000, 887500, 90,
- 912500, 925000, 937500, 95, 962500, 975000, 987500, 100,
- 1012500, 1025000, 1037500, 105, 1062500, 1075000, 1087500, 110,
- 1112500, 1125000, 1137500, 115, 1162500, 1175000, 1187500, 120,
- 1212500, 1225000, 1237500, 125, 1262500, 1275000, 1287500, 130,
- 1312500, 1325000, 1337500, 135, 1362500, 1375000, 1387500, 140,
- 1412500, 1425000, 1437500, 145, 180, 200, 220, 230,
+static const struct regulator_linear_range rk805_buck_1_2_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(712500, 0, 59, 12500),
+ REGULATOR_LINEAR_RANGE(180, 60, 62, 20),
+ REGULATOR_LINEAR_RANGE(230, 63, 63, 0),
};
static const struct regulator_desc rk805_reg[] = {
@@ -479,10 +446,11 @@ static const struct regulator_desc rk805_reg[] = {
.of_match = of_match_ptr("DCDC_REG1"),
.regulators_node = of_match_ptr("regulators"),
.id = RK805_ID_DCDC1,
- .ops = _buck1_2_ops,
+ .ops = _reg_ops_ranges,
.type = REGULATOR_VOLTAGE,
- .n_voltages = ARRAY_SIZE(rk805_buck_1_2_voltages),
- .volt_table = rk805_buck_1_2_voltages,
+ .n_voltages = 64,
+ .linear_ranges = rk805_buck_1_2_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(rk805_buck_1_2_voltage_ranges),
.vsel_reg = RK805_BUCK1_ON_VSEL_REG,
.vsel_mask = RK818_BUCK_VSEL_MASK,
.enable_reg = RK805_DCDC_EN_REG,
@@ -494,10 +462,11 @@ static const struct regulator_desc rk805_reg[] = {
.of_match = of_match_ptr("DCDC_REG2"),
.regulators_node = of_match_ptr("regulators"),
.id = RK805_ID_DCDC2,
- .ops = _buck1_2_ops,
+ .ops = _reg_ops_ranges,
.type = REGULATOR_VOLTAGE,
- .n_voltages = ARRAY_SIZE(rk805_buck_1_2_voltages),
- .volt_table = rk805_buck_1_2_voltages,
+ .n_voltages = 64,
+ .linear_ranges =
Re: Question on handling managed IRQs when hotplugging CPUs
On 2/1/19 10:57 PM, Thomas Gleixner wrote: On Fri, 1 Feb 2019, Hannes Reinecke wrote: Thing is, if we have _managed_ CPU hotplug (ie if the hardware provides some means of quiescing the CPU before hotplug) then the whole thing is trivial; disable SQ and wait for all outstanding commands to complete. Then trivially all requests are completed and the issue is resolved. Even with todays infrastructure. And I'm not sure if we can handle surprise CPU hotplug at all, given all the possible race conditions. But then I might be wrong. The kernel would completely fall apart when a CPU would vanish by surprise, i.e. uncontrolled by the kernel. Then the SCSI driver exploding would be the least of our problems. Hehe. As I thought. So, as the user then has to wait for the system to declars 'ready for CPU remove', why can't we just disable the SQ and wait for all I/O to complete? We can make it more fine-grained by just waiting on all outstanding I/O on that SQ to complete, but waiting for all I/O should be good as an initial try. With that we wouldn't need to fiddle with driver internals, and could make it pretty generic. And we could always add more detailed logic if the driver has the means for doing so. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH] dmaengine: imx-dma: fix wrong callback invoke
On 15-01-19, 17:15, Leonid Iziumtsev wrote:
> Once the "ld_queue" list is not empty, next descriptor will migrate
> into "ld_active" list. The "desc" variable will be overwritten
> during that transition. And later the dmaengine_desc_get_callback_invoke()
> will use it as an argument. As result we invoke wrong callback.
>
> That behaviour was in place since:
> commit fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet").
> But after commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job")
> things got worse, since possible delay between tasklet_schedule()
> from DMA irq handler and actual tasklet function execution got bigger.
> And that gave more time for new DMA request to be submitted and
> to be put into "ld_queue" list.
>
> It has been noticed that DMA issue is causing problems for "mxc-mmc"
> driver. While stressing the system with heavy network traffic and
> writing/reading to/from sd card simultaneously the timeout may happen:
>
> 10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900)
>
> That often lead to file system corruption.
Applied and tagged to stable, thanks
--
~Vinod
Re: [PATCH] dmaengine: fsl-edma: dma map slave device address
On 18-01-19, 12:06, Laurentiu Tudor wrote: > This mapping needs to be created in order for slave dma transfers > to work on systems with SMMU. The implementation mostly mimics the > one in pl330 dma driver, authored by Robin Murphy. Applied, thanks -- ~Vinod
Re: [PATCH] cpufreq: tegra124: add missing of_node_put()
On Mon, Feb 4, 2019 at 2:36 PM Viresh Kumar wrote:
>
> On 04-02-19, 01:35, Yangtao Li wrote:
> > of_cpu_device_node_get() will increase the refcount of device_node,
> > it is necessary to call of_node_put() at the end to release the
> > refcount.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/cpufreq/tegra124-cpufreq.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> > b/drivers/cpufreq/tegra124-cpufreq.c
> > index 43530254201a..140a9266b64a 100644
> > --- a/drivers/cpufreq/tegra124-cpufreq.c
> > +++ b/drivers/cpufreq/tegra124-cpufreq.c
> > @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct
> > platform_device *pdev)
> > goto out_put_pllx_clk;
> > }
> >
> > + of_node_put(np);
> > +
> > ret = tegra124_cpu_switch_to_dfll(priv);
> > if (ret)
> > goto out_put_pllp_clk;
>
> Fixes and stable tags ?
Hi viresh,
Like this？
Fixes: 9eb15dbbfa1a2 ("cpufreq: Add cpufreq driver for Tegra124")
Cc: sta...@vger.kernel.org
MBR,
Yangtao
>
> --
> viresh
Re: [Xen-devel][PATCH] drm/xen-front: Fix mmap attributes for display buffers
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecombine while mmaping.
>> This fixes mismatch of buffer pages' memory attributes between
>> the frontend and backend which may cause screen artifacts.
>>
>> Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
>> frontend")
>>
>> Signed-off-by: Oleksandr Andrushchenko
>>
>> Suggested-by: Julien Grall
>> ---
>> drivers/gpu/drm/xen/xen_drm_front_gem.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
>> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>> index d303a2e17f5e..9d5c03d7668d 100644
>> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
>> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
>> @@ -235,8 +235,7 @@ static int gem_mmap_obj(struct xen_gem_object
>> *xen_obj,
>> vma->vm_flags &= ~VM_PFNMAP;
>> vma->vm_flags |= VM_MIXEDMAP;
>> vma->vm_pgoff = 0;
>> - vma->vm_page_prot =
>> - pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>
> The patch looks good to me. It would be worth expanding the comment a
> bit before to explain that we overwrite vm_page_prot to use cacheable
> attribute as required by the Xen ABI.
>
> With the comment updated:
>
> Acked-by: Julien Grall
>
> Cheers,
>
Applied to drm-misc-next
Re: [Xen-devel] [PATCH -next] drm/xen-front: Drop pointless static qualifier in fb_destroy()
On 1/26/19 2:05 PM, YueHaibing wrote:
> There is no need to have the 'struct drm_framebuffer *fb' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index 860da05..c2955d3 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -54,7 +54,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> struct xen_drm_front_drm_info *drm_info = dev->dev_private;
> - static struct drm_framebuffer *fb;
> + struct drm_framebuffer *fb;
> struct drm_gem_object *gem_obj;
> int ret;
>
Applied to drm-misc-next
Re: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
Hi Lan, Thank you for the patch! Yet something to improve: [auto build test ERROR on iommu/next] [also build test ERROR on v5.0-rc4 next-20190204] [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/lantianyu1986-gmail-com/x86-Hyper-V-IOMMU-Add-Hyper-V-IOMMU-driver-to-support-x2apic-mode/20190204-132009 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: i386-randconfig-a3-02040849 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): arch/x86/kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform': >> arch/x86/kernel/cpu/mshyperv.c:339:3: error: 'x2apic_phys' undeclared (first >> use in this function) x2apic_phys = 1; ^ arch/x86/kernel/cpu/mshyperv.c:339:3: note: each undeclared identifier is reported only once for each function it appears in vim +/x2apic_phys +339 arch/x86/kernel/cpu/mshyperv.c 331 332 /* 333 * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, 334 * set x2apic destination mode to physcial mode when x2apic is available 335 * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs 336 * have 8-bit APIC id. 337 */ 338 if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > 339 x2apic_phys = 1; 340 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
RE: [PATCH] uprobes: convert uprobe.ref to refcount_t
> * Elena Reshetova [2019-01-16 13:20:27]: > > > atomic_t variables are currently used to implement reference > > counters with the following properties: > > - counter is initialized to 1 using atomic_set() > > - a resource is freed upon counter reaching zero > > - once counter reaches zero, its further > >increments aren't allowed > > - counter schema uses basic atomic operations > >(set, inc, inc_not_zero, dec_and_test, etc.) > > > > Such atomic variables should be converted to a newly provided > > refcount_t type and API that prevents accidental counter overflows > > and underflows. This is important since overflows and underflows > > can lead to use-after-free situation and be exploitable. > > > > The variable uprobe.ref is used as pure reference counter. > > Convert it to refcount_t and fix up the operations. > > > > **Important note for maintainers: > > > > Some functions from refcount_t API defined in lib/refcount.c > > have different memory ordering guarantees than their atomic > > counterparts. > > The full comparison can be seen in > > https://lkml.org/lkml/2017/11/15/57 and it is hopefully soon > > in state to be merged to the documentation tree. > > Normally the differences should not matter since refcount_t provides > > enough guarantees to satisfy the refcounting use cases, but in > > some rare cases it might matter. > > Please double check that you don't have some undocumented > > memory guarantees for this variable usage. > > > > For the uprobe.ref it might make a difference > > in following places: > > - put_uprobe(): decrement in refcount_dec_and_test() only > >provides RELEASE ordering and control dependency on success > >vs. fully ordered atomic counterpart > > > > Suggested-by: Kees Cook > > Reviewed-by: David Windsor > > Reviewed-by: Hans Liljestrand > > Signed-off-by: Elena Reshetova > > --- > > kernel/events/uprobes.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Looks good to me. > > Reviewed-by: Srikar Dronamraju Thank you very much Srikar! Would you be able to take this patch to integration? Best Regards, Elena.
Re: [PATCH] cpufreq: qcom-kryo: make some variables static
On 04-02-19, 01:13, Yangtao Li wrote:
> The variables are local to the source and do not
> need to be in global scope, so make them static.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index 2a3675c24032..1c8583cc06a2 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -42,7 +42,7 @@ enum _msm8996_version {
> NUM_OF_MSM8996_VERSIONS,
> };
>
> -struct platform_device *cpufreq_dt_pdev, *kryo_cpufreq_pdev;
> +static struct platform_device *cpufreq_dt_pdev, *kryo_cpufreq_pdev;
>
> static enum _msm8996_version qcom_cpufreq_kryo_get_msm_id(void)
> {
Applied. Thanks.
--
viresh
[PATCH] cpufreq: tegra124: add missing of_node_put()
of_cpu_device_node_get() will increase the refcount of device_node, it is necessary to call of_node_put() at the end to release the refcount. Signed-off-by: Yangtao Li --- drivers/cpufreq/tegra124-cpufreq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c index 43530254201a..140a9266b64a 100644 --- a/drivers/cpufreq/tegra124-cpufreq.c +++ b/drivers/cpufreq/tegra124-cpufreq.c @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct platform_device *pdev) goto out_put_pllx_clk; } + of_node_put(np); + ret = tegra124_cpu_switch_to_dfll(priv); if (ret) goto out_put_pllp_clk; -- 2.17.0
Re: [PATCH] cpufreq: tegra124: add missing of_node_put()
On 04-02-19, 01:35, Yangtao Li wrote: > of_cpu_device_node_get() will increase the refcount of device_node, > it is necessary to call of_node_put() at the end to release the > refcount. > > Signed-off-by: Yangtao Li > --- > drivers/cpufreq/tegra124-cpufreq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/tegra124-cpufreq.c > b/drivers/cpufreq/tegra124-cpufreq.c > index 43530254201a..140a9266b64a 100644 > --- a/drivers/cpufreq/tegra124-cpufreq.c > +++ b/drivers/cpufreq/tegra124-cpufreq.c > @@ -118,6 +118,8 @@ static int tegra124_cpufreq_probe(struct platform_device > *pdev) > goto out_put_pllx_clk; > } > > + of_node_put(np); > + > ret = tegra124_cpu_switch_to_dfll(priv); > if (ret) > goto out_put_pllp_clk; Fixes and stable tags ? -- viresh
[PATCH] cpufreq: qcom-kryo: make some variables static
The variables are local to the source and do not
need to be in global scope, so make them static.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/qcom-cpufreq-kryo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
b/drivers/cpufreq/qcom-cpufreq-kryo.c
index 2a3675c24032..1c8583cc06a2 100644
--- a/drivers/cpufreq/qcom-cpufreq-kryo.c
+++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
@@ -42,7 +42,7 @@ enum _msm8996_version {
NUM_OF_MSM8996_VERSIONS,
};
-struct platform_device *cpufreq_dt_pdev, *kryo_cpufreq_pdev;
+static struct platform_device *cpufreq_dt_pdev, *kryo_cpufreq_pdev;
static enum _msm8996_version qcom_cpufreq_kryo_get_msm_id(void)
{
--
2.17.0
Re: [PATCH v2] arm64: dts: hikey: Give wifi some time after power-on
On Fri, 1 Feb 2019 at 17:34, Wei Xu wrote:
>
> Hi Jan,
>
> On 1/24/2019 7:52 AM, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > Somewhere along recent changes to power control of the wl1835, power-on
> > became very unreliable on the hikey, failing like this:
> >
> > wl1271_sdio: probe of mmc2:0001:1 failed with error -16
> > wl1271_sdio: probe of mmc2:0001:2 failed with error -16
> >
> > After playing with some dt parameters and comparing to other users of
> > this chip, it turned out we need some power-on delay to make things
> > stable again. In contrast to those other users which define 200 ms, the
> > hikey would already be happy with 1 ms. Still, we use the safer 10 ms,
> > like on the Ultra96.
> >
> > Fixes: ea452678734e ("arm64: dts: hikey: Fix WiFi support")
> > Signed-off-by: Jan Kiszka
> > Acked-by: Ulf Hansson
>
> Applied to the hisilicon soc dt tree.
Wei, can you please also add a stable tag to it?
[...]
Thanks and kind regards
Uffe
divide error in vivid_thread_vid_cap
Hello, syzbot found the following crash on: HEAD commit:12491ed354d2 Merge tag 'devicetree-fixes-for-5.0-3' of git.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1328ae8740 kernel config: https://syzkaller.appspot.com/x/.config?x=2e0064f906afee10 dashboard link: https://syzkaller.appspot.com/bug?extid=75293f834026a7e97684 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+75293f834026a7e97...@syzkaller.appspotmail.com divide error: [#1] PREEMPT SMP KASAN kobject: 'tx-0' (17161f7f): kobject_uevent_env CPU: 0 PID: 23689 Comm: vivid-003-vid-c Not tainted 5.0.0-rc4+ #58 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x2840 drivers/media/platform/vivid/vivid-kthread-cap.c:789 Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 RSP: 0018:88808b4afd68 EFLAGS: 00010246 kobject: 'tx-0' (17161f7f): fill_kobj_path: path = '/devices/virtual/net/gre0/queues/tx-0' RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: RDX: RSI: 0004 RDI: 0004 RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008 R10: 89997010 R11: 0001 R12: fffc R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140 FS: () GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0 Call Trace: kobject: 'gretap0' (d7549098): kobject_add_internal: parent: 'net', set: 'devices' kobject: 'loop2' (94ed4ee4): kobject_uevent_env kobject: 'loop2' (94ed4ee4): fill_kobj_path: path = '/devices/virtual/block/loop2' kthread+0x357/0x430 kernel/kthread.c:246 kobject: 'gretap0' (d7549098): kobject_uevent_env ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Modules linked in: kobject: 'gretap0' (d7549098): fill_kobj_path: path = '/devices/virtual/net/gretap0' ---[ end trace bc5c8b25b64d768f ]--- kobject: 'loop1' (32036b86): kobject_uevent_env RIP: 0010:vivid_cap_update_frame_period drivers/media/platform/vivid/vivid-kthread-cap.c:661 [inline] RIP: 0010:vivid_thread_vid_cap+0x221/0x2840 drivers/media/platform/vivid/vivid-kthread-cap.c:789 kobject: 'loop1' (32036b86): fill_kobj_path: path = '/devices/virtual/block/loop1' Code: 48 c1 e9 03 0f b6 0c 11 48 89 f2 48 69 c0 00 ca 9a 3b 83 c2 03 38 ca 7c 08 84 c9 0f 85 f0 1e 00 00 41 8b 8f 24 64 00 00 31 d2 <48> f7 f1 49 89 c4 48 89 c3 49 8d 87 28 64 00 00 48 89 c2 48 89 45 kobject: 'loop0' (dd9927c3): kobject_uevent_env RSP: 0018:88808b4afd68 EFLAGS: 00010246 RAX: 00de5a6f8e00 RBX: 000100047b22 RCX: kobject: 'queues' (7ed20666): kobject_add_internal: parent: 'gretap0', set: '' RDX: RSI: 0004 RDI: 0004 RBP: 88808b4aff00 R08: 88804862e1c0 R09: 89997008 kobject: 'loop0' (dd9927c3): fill_kobj_path: path = '/devices/virtual/block/loop0' R10: 89997010 R11: 0001 R12: fffc kobject: 'queues' (7ed20666): kobject_uevent_env R13: 8880a17e0500 R14: 88803e40f760 R15: 8882182b0140 FS: () GS:8880ae80() knlGS: kobject: 'loop5' (a41f9e79): kobject_uevent_env CS: 0010 DS: ES: CR0: 80050033 kobject: 'queues' (7ed20666): kobject_uevent_env: filter function caused the event to drop! CR2: 004cdc90 CR3: 5d827000 CR4: 001426f0 kobject: 'loop5' (a41f9e79): fill_kobj_path: path = '/devices/virtual/block/loop5' --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
Re: Userspace regression with 6baca7601bde ("scsi: target: drop unused pi_prot_format attribute storage")
On 2/4/19 1:40 AM, David Disseldorp wrote: Hi Laura, Thanks for the report... On Sun, 3 Feb 2019 17:56:00 +0100, Laura Abbott wrote: Fedora got a bug report of a new permission denied error with 5.0-rc2: File "/usr/lib/python3.7/site-packages/rtslib_fb/utils.py", line 100, in fread with open(path, 'r') as file_fd: PermissionError: [Errno 13] Permission denied: '/sys/kernel/config/target/core/fileio_28/xxx/attrib/pi_prot_format' This looks like an intentional behavior change with commit 6baca7601bdee2e57f20c45d63eb53b89b33e816 Author: David Disseldorp Date: Fri Nov 23 18:36:11 2018 +0100 scsi: target: drop unused pi_prot_format attribute storage On write, the pi_prot_format configfs attribute invokes the device format_prot() callback if present. Read dumps the contents of se_dev_attrib.pi_prot_format which is always zero. Make the configfs attribute write-only, and drop the always zero se_dev_attrib.pi_prot_format storage. Signed-off-by: David Disseldorp Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Unfortunately, existing code that's opening with read permissions is now broken. Can this be reverted? Full bug at https://bugzilla.redhat.com/show_bug.cgi?id=1667505 Lee (cc'ed) pinged me a couple of days ago about the same issue. My preference would be to add back a dummy read handler without the corresponding (unused) se_dev_attrib.pi_prot_format member. I'll prepare something tomorrow with this, but if it's urgent then I'd also be okay with a straight revert. Cheers, David A fix is fine by me. Thanks for the prompt response. Thanks, Laura
Re: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
Hi Lan, Thank you for the patch! Yet something to improve: [auto build test ERROR on iommu/next] [also build test ERROR on v5.0-rc4 next-20190201] [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/lantianyu1986-gmail-com/x86-Hyper-V-IOMMU-Add-Hyper-V-IOMMU-driver-to-support-x2apic-mode/20190204-132009 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: x86_64-randconfig-x005-201905 (attached as .config) compiler: gcc-8 (Debian 8.2.0-14) 8.2.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): arch/x86//kernel/cpu/mshyperv.c: In function 'ms_hyperv_init_platform': >> arch/x86//kernel/cpu/mshyperv.c:339:3: error: 'x2apic_phys' undeclared >> (first use in this function); did you mean 'x2apic_mode'? x2apic_phys = 1; ^~~ x2apic_mode arch/x86//kernel/cpu/mshyperv.c:339:3: note: each undeclared identifier is reported only once for each function it appears in vim +339 arch/x86//kernel/cpu/mshyperv.c 331 332 /* 333 * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, 334 * set x2apic destination mode to physcial mode when x2apic is available 335 * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs 336 * have 8-bit APIC id. 337 */ 338 if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > 339 x2apic_phys = 1; 340 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] mm/slab: Increase width of first /proc/slabinfo column
On Fri, Feb 01, 2019 at 02:03:46PM -0800, Andrew Morton wrote: > On Thu, 31 Jan 2019 18:43:10 -0800 Matthew Wilcox wrote: > > > On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote: > > > Currently when displaying /proc/slabinfo if any cache names are too long > > > then the output columns are not aligned. We could do something fancy to > > > get the maximum length of any cache name in the system or we could just > > > increase the hardcoded width. Currently it is 17 characters. Monitors > > > are wide these days so lets just increase it to 30 characters. > > > > I had a proposal some time ago to turn the slab name from being kmalloced > > to being an inline 16 bytes (with some fun hacks for cgroups). I think > > that's a better approach than permitting such long names. For example, > > ext4_allocation_context could be shortened to ext4_alloc_ctx without > > losing any expressivity. > > > > There are some back-compatibility concerns here. I'm don't understand sorry what back-compatibility concerns (please see sentiment at end of email :) > And truncating long names might result in duplicates. So I thought I had a good idea - add a pr_warn() if cache name > 16 and patch all current intree calls to kmem_cache_create() called as such. This process very kindly lead me to the fact that this does *not* work because of the macro KMEM_CACHE (which uses the struct name as the cache name). So, back to the drawing board. I'm concerned that this may be a waste of peoples time, if so please say so and I'll move on to something else. thanks, Tobin.
linux-next: Fixes tag needs some work in the drm tree
Hi all,
In commit
4b5105036afb ("drm/amd/display: Don't leak memory when updating streams")
Fixes tags
Fixes: c00e0cc0fdc0 ("drm/amd/display: Call into DC once per multiplane flip")
Fixes: ea39594e0855 ("drm/amd/display: Perform plane updates only when
needed")
have this problem:
- Target SHA1s do not exist
--
Cheers,
Stephen Rothwell
pgpjBphTiXlzC.pgp
Description: OpenPGP digital signature
RE: [PATCH] acpi/nfit: Require opt-in for read-only label configurations
> From: Dan Williams
> Sent: Sunday, February 3, 2019 11:29 AM
> ...
> Recent fixes to command handling enabled Linux to read label
> configurations that it could not before. Unfortunately that means that
> configurations that were operating in label-less mode will be broken as
> the kernel ignores the existing namespace configuration and tries to
> honor the new found labels.
>
> Fortunately this seems limited to a case where Linux can quirk the
> behavior and maintain the existing label-less semantics by default.
> When the platform does not emit an _LSW method, disable all label access
> methods. Provide a 'force_labels' module parameter to allow read-only
> label operation.
>
> Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
> Reported-by: Dexuan Cui
> Signed-off-by: Dan Williams
Hi Dan,
Thanks for the patch and all the detailed explanation! With this patch,
the "fsdax" namespace can be properly detected now!
Thanks,
-- Dexuan
Re: general protection fault in rose_send_frame
syzbot has found a reproducer for the following crash on:
HEAD commit:9fb20801dab4 net: Fix ip_mc_{dec,inc}_group allocation con..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17530a0f40
kernel config: https://syzkaller.appspot.com/x/.config?x=33ad02b9305759c3
dashboard link: https://syzkaller.appspot.com/bug?extid=7078ae989d857fe17988
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=148b35f8c0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7078ae989d857fe17...@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device batadv0
device rose0 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_CHANGE): rose0: link becomes ready
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7801 Comm: udevd Not tainted 5.0.0-rc4+ #44
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rose_send_frame+0x1a8/0x280 net/rose/rose_link.c:104
Code: c1 ea 03 80 3c 02 00 0f 85 8d 00 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 58 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75
7e 49 8b 94 24 58 03 00 00 e9 b8 fe ff ff e8 60 cd
RSP: :8880ae907ae8 EFLAGS: 00010202
RAX: dc00 RBX: 88809a954500 RCX: 86360ccb
RDX: 006b RSI: 86360dfc RDI: 0358
RBP: 8880ae907b18 R08: 888094b50080 R09: ed10146ad41d
R10: ed10146ad41c R11: 8880a356a0e3 R12:
R13: 0078 R14: 0005 R15: 8880a886acc0
FS: 7f75710e57a0() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f7570790590 CR3: 9fb95000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
rose_transmit_clear_request+0x1de/0x2a0 net/rose/rose_link.c:258
rose_rx_call_request+0x4ea/0x1990 net/rose/af_rose.c:999
rose_loopback_timer+0x26a/0x3f0 net/rose/rose_loopback.c:100
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1/0x20 kernel/kcov.c:174
Code: c3 0f 1f 84 00 00 00 00 00 55 48 89 f2 48 89 fe bf 06 00 00 00 48 89
e5 48 8b 4d 08 e8 18 ff ff ff 5d c3 66 0f 1f 44 00 00 55 <40> 0f b6 d6 40
0f b6 f7 bf 01 00 00 00 48 89 e5 48 8b 4d 08 e8 f6
RSP: :8880a806fb90 EFLAGS: 0246 ORIG_RAX: ff13
RAX: 888094b50080 RBX: 8880a806fca8 RCX: 818a7cde
RDX: RSI: RDI:
RBP: 8880a806fcd0 R08: 888094b50080 R09: 0004
R10: ed1015d25bc7 R11: 8880ae92de3b R12: ea25f980
R13: 88809b8a87b8 R14: 0001 R15: 0084
do_fault_around mm/memory.c:3391 [inline]
do_read_fault mm/memory.c:3425 [inline]
do_fault mm/memory.c:3556 [inline]
handle_pte_fault mm/memory.c:3787 [inline]
__handle_mm_fault+0x3226/0x3f20 mm/memory.c:3911
handle_mm_fault+0x43f/0xb30 mm/memory.c:3948
do_user_addr_fault arch/x86/mm/fault.c:1475 [inline]
__do_page_fault+0x5da/0xd60 arch/x86/mm/fault.c:1541
do_page_fault+0x71/0x581 arch/x86/mm/fault.c:1572
page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1143
RIP: 0033:0x7f7570790590
Code: 00 74 0f f0 ff 0d ac 41 31 00 0f 85 d3 6b 00 00 eb 0c ff 0d 9e 41 31
00 0f 85 c5 6b 00 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 <8b> 0d 4e 1b 31
00 85 c9 7e 6c 48 8b 15 97 41 31 00 48 8b 05 78 17
RSP: 002b:7ffec2e21978 EFLAGS: 00010206
RAX: 7f7570aa4740 RBX: 7ffec2e219a0 RCX: 7f75705162a0
RDX: 7f7570790590 RSI: 7f7570512240 RDI: 7f7570aa26c0
RBP: 7ffec2e219e0 R08: 1ce4 R09: 1ce4
R10: 7f7570512240 R11: 7f75710e57a0 R12:
R13: R14: 7f75710f0040 R15: 0005
Modules linked in:
---[ end trace 19f243a97b44aa5b ]---
RIP: 0010:rose_send_frame+0x1a8/0x280 net/rose/rose_link.c:104
Code: c1 ea 03 80 3c 02 00 0f 85 8d 00 00 00 48 b8 00 00 00 00 00 fc ff df
4c 8b 63 20 49 8d bc 24 58 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75
7e 49 8b 94 24 58 03 00 00 e9 b8 fe ff ff e8 60 cd
RSP: :8880ae907ae8 EFLAGS: 00010202
RAX:
Re: [PATCH v4] bluetooth: Fix WARNING in tty_set_termios()
Hi Shuah,
> tty_set_termios() has the following WARN_ON which can be triggered with a
> syscall to invoke TIOCSETD __NR_ioctl.
>
> WARN_ON(tty->driver->type == TTY_DRIVER_TYPE_PTY &&
>tty->driver->subtype == PTY_TYPE_MASTER);
> Reference:
> https://syzkaller.appspot.com/bug?id=2410d22f1d8e5984217329dd0884b01d99e3e48d
>
> "The problem started with commit 7721383f4199 ("Bluetooth: hci_uart: Support
> operational speed during setup") which introduced a new way for how
> tty_set_termios() could end up being called for a master pty."
>
> Fix it by by preventing setting the HCI line discipline for PTYs in
> hci_uart_tty_open().
>
> Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com
> Cc: Johan Hovold
> Cc: Marcel Holtmann
> Cc: Al Viro
> Signed-off-by: Shuah Khan
> ---
> drivers/bluetooth/hci_ldisc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index fbf7b4df23ab..c8faa4759cb7 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -475,9 +475,9 @@ static int hci_uart_tty_open(struct tty_struct *tty)
> BT_DBG("tty %p", tty);
>
> /* Error if the tty has no write op instead of leaving an exploitable
> - * hole
> + * hole. In addition check if setting HCI line discipline is allowed.
>*/
this comment is wrong. The result of setting the HCI line discipline is a call
into hci_uart_tty_open. You have to check ops->write and ops->set_termios since
both are required. That is it.
> - if (tty->ops->write == NULL)
> + if (tty->ops->write == NULL || tty->ops->set_termios == NULL)
> return -EOPNOTSUPP;
And while at it, change this to (!tty->ops->write).
Regards
Marcel
linux-next: Tree for Feb 4
Hi all, Changes since 20190201: The vfs tree still had its build failure for which I applied a patch. The net-next tree gained a build failure for which I applied a fix patch. The drm-tegra tree gained a build failure so I used the version from next-20190201. The driver-core tree lost its build failure. Non-merge commits (relative to Linus' tree): 5280 6047 files changed, 219992 insertions(+), 146740 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (24b888d8d598 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (c4a8fb41246c ARCv2: lib: memcpy: fix doing prefetchw outside of buffer) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (f7daa9c8fd19 arm64: hibernate: Clean the __hyp_text to PoC after resume) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8dfb8d2cceb7 net: systemport: Fix WoL with password after deep sleep) Merging bpf/master (e7b816415e03 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (09db51241118 esp: Skip TX bytes accounting when sending from a request socket) Merging netfilter/master (ba59fb027307 sctp: walk the list of asoc safely) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (8c22d81d5535 MAINTAINERS: add entry for redpine wireless driver) Merging mac80211/master (e005bd7ddea0 cfg80211: call disconnect_wk when AP stops) Merging rdma-fixes/for-rc (7b21b69ab203 IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociate) Merging sound-current/for-linus (305a0ade1809 ALSA: hda - Serialize codec registrations) Merging sound-asoc-fixes/for-linus (923ed80588cf Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (c05e202d60de Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (2186097e00f9 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f14bcc0add3a Revert "PCI: armada8k: Add support for gpio controlled reset signal") Merging driver-core.current/driver-core-linus (36991ca68db9 blk-mq: protect debugfs_create_files() from failures) Merging tty.current/tty-linus (fedb5760648a serial: fix race between flush_to_ldisc and tty_open) Merging usb.current/usb-linus (a07ddce4df80 usb: typec: tcpm: Correct the PPS out_volt calculation) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (f17b5f06cb92 Linux 5.0-rc4) Merging
[PATCH 5/6] mm/gup: /proc/vmstat support for get/put user pages
From: John Hubbard
Add five new /proc/vmstat items, to provide some
visibility into what get_user_pages() and put_user_page()
are doing.
After booting and running fio (https://github.com/axboe/fio)
a few times on an NVMe device, as a way to get lots of
get_user_pages_fast() calls, the counters look like this:
$ cat /proc/vmstat |grep gup
nr_gup_slow_pages_requested 21319
nr_gup_fast_pages_requested 11533792
nr_gup_fast_page_backoffs 0
nr_gup_page_count_overflows 0
nr_gup_pages_returned 11555104
Interpretation of the above:
Total gup requests (slow + fast): 11555111
Total put_user_page calls:11555104
This shows 7 more calls to get_user_pages(), than to
put_user_page(). That may, or may not, represent a
problem worth investigating.
Normally, those last two numbers should be equal, but a
couple of things may cause them to differ:
1) Inherent race condition in reading /proc/vmstat values.
2) Bugs at any of the get_user_pages*() call sites. Those
sites need to match get_user_pages() and put_user_page() calls.
Signed-off-by: John Hubbard
---
include/linux/mmzone.h | 5 +
mm/gup.c | 20
mm/swap.c | 1 +
mm/vmstat.c| 5 +
4 files changed, 31 insertions(+)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 842f9189537b..f20c14958a2b 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -183,6 +183,11 @@ enum node_stat_item {
NR_DIRTIED, /* page dirtyings since bootup */
NR_WRITTEN, /* page writings since bootup */
NR_KERNEL_MISC_RECLAIMABLE, /* reclaimable non-slab kernel pages */
+ NR_GUP_SLOW_PAGES_REQUESTED,/* via: get_user_pages() */
+ NR_GUP_FAST_PAGES_REQUESTED,/* via: get_user_pages_fast() */
+ NR_GUP_FAST_PAGE_BACKOFFS, /* gup_fast() lost to page_mkclean() */
+ NR_GUP_PAGE_COUNT_OVERFLOWS,/* gup count overflowed: gup() failed */
+ NR_GUP_PAGES_RETURNED, /* via: put_user_page() */
NR_VM_NODE_STAT_ITEMS
};
diff --git a/mm/gup.c b/mm/gup.c
index 3291da342f9c..848ee7899831 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -37,6 +37,8 @@ int get_gup_pin_page(struct page *page)
page = compound_head(page);
if (page_ref_count(page) >= (UINT_MAX - GUP_PIN_COUNTING_BIAS)) {
+ mod_node_page_state(page_pgdat(page),
+ NR_GUP_PAGE_COUNT_OVERFLOWS, 1);
WARN_ONCE(1, "get_user_pages pin count overflowed");
return -EOVERFLOW;
}
@@ -184,6 +186,8 @@ static struct page *follow_page_pte(struct vm_area_struct
*vma,
page = ERR_PTR(ret);
goto out;
}
+ mod_node_page_state(page_pgdat(page),
+ NR_GUP_SLOW_PAGES_REQUESTED, 1);
}
if (flags & FOLL_TOUCH) {
if ((flags & FOLL_WRITE) &&
@@ -527,6 +531,8 @@ static int get_gate_page(struct mm_struct *mm, unsigned
long address,
ret = get_gup_pin_page(*page);
if (ret)
goto unmap;
+
+ mod_node_page_state(page_pgdat(*page), NR_GUP_SLOW_PAGES_REQUESTED, 1);
out:
ret = 0;
unmap:
@@ -1461,7 +1467,12 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
if (!page_cache_gup_pin_speculative(head))
goto pte_unmap;
+ mod_node_page_state(page_pgdat(head),
+ NR_GUP_FAST_PAGES_REQUESTED, 1);
+
if (unlikely(pte_val(pte) != pte_val(*ptep))) {
+ mod_node_page_state(page_pgdat(head),
+ NR_GUP_FAST_PAGE_BACKOFFS, 1);
put_user_page(head);
goto pte_unmap;
}
@@ -1522,6 +1533,9 @@ static int __gup_device_huge(unsigned long pfn, unsigned
long addr,
return 0;
}
+ mod_node_page_state(page_pgdat(page),
+ NR_GUP_FAST_PAGES_REQUESTED, 1);
+
(*nr)++;
pfn++;
} while (addr += PAGE_SIZE, addr != end);
@@ -1607,6 +1621,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned
long addr,
return 0;
}
+ mod_node_page_state(page_pgdat(head), NR_GUP_FAST_PAGES_REQUESTED, 1);
+
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
*nr -= refs;
put_user_page(head);
@@ -1644,6 +1660,8 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned
long addr,
return 0;
}
+ mod_node_page_state(page_pgdat(head), NR_GUP_FAST_PAGES_REQUESTED, 1);
+
if (unlikely(pud_val(orig) != pud_val(*pudp))) {
*nr -= refs;
put_user_page(head);
@@ -1680,6 +1698,8 @@ static int gup_huge_pgd(pgd_t orig,
[PATCH 3/6] mm: page_cache_add_speculative(): refactoring
From: John Hubbard
This combines the common elements of these routines:
page_cache_get_speculative()
page_cache_add_speculative()
This was anticipated by the original author, as shown by the comment
in commit ce0ad7f095258 ("powerpc/mm: Lockless get_user_pages_fast()
for 64-bit (v3)"):
"Same as above, but add instead of inc (could just be merged)"
An upcoming patch for get_user_pages() tracking will use these routines,
so let's remove the duplication now.
There is no intention to introduce any behavioral change, but there is a
small risk of that, due to slightly differing ways of expressing the
TINY_RCU and related configurations.
Cc: Nick Piggin
Cc: Dave Kleikamp
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
Signed-off-by: John Hubbard
---
include/linux/pagemap.h | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index e2d7039af6a3..5c8a9b59cbdc 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -164,8 +164,10 @@ void release_pages(struct page **pages, int nr);
* will find the page or it will not. Likewise, the old find_get_page could run
* either before the insertion or afterwards, depending on timing.
*/
-static inline int page_cache_get_speculative(struct page *page)
+static inline int __page_cache_add_speculative(struct page *page, int count)
{
+ VM_BUG_ON(in_interrupt());
+
#ifdef CONFIG_TINY_RCU
# ifdef CONFIG_PREEMPT_COUNT
VM_BUG_ON(!in_atomic() && !irqs_disabled());
@@ -180,10 +182,10 @@ static inline int page_cache_get_speculative(struct page
*page)
* SMP requires.
*/
VM_BUG_ON_PAGE(page_count(page) == 0, page);
- page_ref_inc(page);
+ page_ref_add(page, count);
#else
- if (unlikely(!get_page_unless_zero(page))) {
+ if (unlikely(!page_ref_add_unless(page, count, 0))) {
/*
* Either the page has been freed, or will be freed.
* In either case, retry here and the caller should
@@ -197,27 +199,14 @@ static inline int page_cache_get_speculative(struct page
*page)
return 1;
}
-/*
- * Same as above, but add instead of inc (could just be merged)
- */
-static inline int page_cache_add_speculative(struct page *page, int count)
+static inline int page_cache_get_speculative(struct page *page)
{
- VM_BUG_ON(in_interrupt());
-
-#if !defined(CONFIG_SMP) && defined(CONFIG_TREE_RCU)
-# ifdef CONFIG_PREEMPT_COUNT
- VM_BUG_ON(!in_atomic() && !irqs_disabled());
-# endif
- VM_BUG_ON_PAGE(page_count(page) == 0, page);
- page_ref_add(page, count);
-
-#else
- if (unlikely(!page_ref_add_unless(page, count, 0)))
- return 0;
-#endif
- VM_BUG_ON_PAGE(PageCompound(page) && page != compound_head(page), page);
+ return __page_cache_add_speculative(page, 1);
+}
- return 1;
+static inline int page_cache_add_speculative(struct page *page, int count)
+{
+ return __page_cache_add_speculative(page, count);
}
#ifdef CONFIG_NUMA
--
2.20.1
[PATCH 1/6] mm: introduce put_user_page*(), placeholder versions
From: John Hubbard
Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().
Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for release_pages(), and also as a replacement
for open-coded loops that release multiple pages.
These may be used for subsequent performance improvements,
via batching of pages to be released.
This is the first step of fixing a problem (also described in [1] and
[2]) with interactions between get_user_pages ("gup") and filesystems.
Problem description: let's start with a bug report. Below, is what happens
sometimes, under memory pressure, when a driver pins some pages via gup,
and then marks those pages dirty, and releases them. Note that the gup
documentation actually recommends that pattern. The problem is that the
filesystem may do a writeback while the pages were gup-pinned, and then the
filesystem believes that the pages are clean. So, when the driver later
marks the pages as dirty, that conflicts with the filesystem's page
tracking and results in a BUG(), like this one that I experienced:
kernel BUG at /build/linux-fQ94TU/linux-4.4.0/fs/ext4/inode.c:1899!
backtrace:
ext4_writepage
__writepage
write_cache_pages
ext4_writepages
do_writepages
__writeback_single_inode
writeback_sb_inodes
__writeback_inodes_wb
wb_writeback
wb_workfn
process_one_work
worker_thread
kthread
ret_from_fork
...which is due to the file system asserting that there are still buffer
heads attached:
({ \
BUG_ON(!PagePrivate(page)); \
((struct buffer_head *)page_private(page)); \
})
Dave Chinner's description of this is very clear:
"The fundamental issue is that ->page_mkwrite must be called on every
write access to a clean file backed page, not just the first one.
How long the GUP reference lasts is irrelevant, if the page is clean
and you need to dirty it, you must call ->page_mkwrite before it is
marked writeable and dirtied. Every. Time."
This is just one symptom of the larger design problem: filesystems do not
actually support get_user_pages() being called on their pages, and letting
hardware write directly to those pages--even though that patter has been
going on since about 2005 or so.
The steps are to fix it are:
1) (This patch): provide put_user_page*() routines, intended to be used
for releasing pages that were pinned via get_user_pages*().
2) Convert all of the call sites for get_user_pages*(), to
invoke put_user_page*(), instead of put_page(). This involves dozens of
call sites, and will take some time.
3) After (2) is complete, use get_user_pages*() and put_user_page*() to
implement tracking of these pages. This tracking will be separate from
the existing struct page refcounting.
4) Use the tracking and identification of these pages, to implement
special handling (especially in writeback paths) when the pages are
backed by a filesystem.
[1] https://lwn.net/Articles/774411/ : "DMA and get_user_pages()"
[2] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"
Cc: Al Viro
Cc: Christoph Hellwig
Cc: Christopher Lameter
Cc: Dan Williams
Cc: Dave Chinner
Cc: Jan Kara
Cc: Jason Gunthorpe
Cc: Jerome Glisse
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: Mike Rapoport
Cc: Ralph Campbell
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
include/linux/mm.h | 24 ++
mm/swap.c | 82 ++
2 files changed, 106 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb6408fe73..809b7397d41e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -993,6 +993,30 @@ static inline void put_page(struct page *page)
__put_page(page);
}
+/**
+ * put_user_page() - release a gup-pinned page
+ * @page:pointer to page to be released
+ *
+ * Pages that were pinned via get_user_pages*() must be released via
+ * either put_user_page(), or one of the put_user_pages*() routines
+ * below. This is so that eventually, pages that are pinned via
+ * get_user_pages*() can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special
+ * handling.
+ *
+ * put_user_page() and put_page() are not interchangeable, despite this early
+ * implementation that makes them look the same. put_user_page() calls must
+ * be perfectly matched up with get_user_page() calls.
+ */
+static inline void put_user_page(struct page *page)
+{
+ put_page(page);
+}
+
+void put_user_pages_dirty(struct page **pages, unsigned long npages);
+void put_user_pages_dirty_lock(struct page **pages, unsigned long
[PATCH 0/6] RFC v2: mm: gup/dma tracking
From: John Hubbard
Hi,
I'm calling this RFC v2, even though with all the discussion it actually
feels
like about v7 or so. But now that the dust has settled, it's time to show a
surprisingly small, cleaner approach. Jan and Jerome came up with a scheme
(discussed in more detail in "track gup-pinned pages" commit description)
that
does not require any additional struct page fields. This approach has the
additional advantage of being very lightweight and therefore fast, because
a) it mostly just does atomics,
b) unlike previous approaches, there is no need to remove and re-add to
LRUs.
c) it uses the same lock-free algorithms that get_user_pages already
relies upon.
This RFC shows the following:
1) A patch to get the call site conversion started:
mm: introduce put_user_page*(), placeholder versions
2) A sample call site conversion:
infiniband/mm: convert put_page() to put_user_page*()
...NOT shown: all of the other 100+ gup call site conversions. Again,
those are in various states of progress and disrepair, at [1].
3) Tracking, instrumentation, and documentation patches, once all the call
sites have been converted.
4) A small refactoring patch that I'm also going to submit separately, for
the page_cache_add_speculative() routine.
This seems to be working pretty well here. I've converted enough call sites
(there is git repo [1] with that, which gets rebased madly, but it's there if
you really want to try some early testing) to run things such as fio.
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numjobs=1
rw=read
iodepth=64
reader: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B,
ioengine=libaio, iodepth=64
fio-3.3
Starting 1 process
Jobs: 1 (f=1)
reader: (groupid=0, jobs=1): err= 0: pid=7011: Sun Feb 3 20:36:51 2019
read: IOPS=190k, BW=741MiB/s (778MB/s)(1024MiB/1381msec)
slat (nsec): min=2716, max=57255, avg=4048.14, stdev=1084.10
clat (usec): min=20, max=12485, avg=332.63, stdev=191.77
lat (usec): min=22, max=12498, avg=336.72, stdev=192.07
clat percentiles (usec):
| 1.00th=[ 322], 5.00th=[ 322], 10.00th=[ 322], 20.00th=[ 326],
| 30.00th=[ 326], 40.00th=[ 326], 50.00th=[ 326], 60.00th=[ 326],
| 70.00th=[ 326], 80.00th=[ 330], 90.00th=[ 330], 95.00th=[ 330],
| 99.00th=[ 478], 99.50th=[ 717], 99.90th=[ 1074], 99.95th=[ 1090],
| 99.99th=[12256]
bw ( KiB/s): min=730152, max=776512, per=99.22%, avg=753332.00,
stdev=32781.47, samples=2
iops: min=182538, max=194128, avg=188333.00, stdev=8195.37, samples=2
lat (usec) : 50=0.01%, 100=0.01%, 250=0.07%, 500=99.26%, 750=0.38%
lat (usec) : 1000=0.02%
lat (msec) : 2=0.24%, 20=0.02%
cpu : usr=15.07%, sys=84.13%, ctx=10, majf=0, minf=74
IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=741MiB/s (778MB/s), 741MiB/s-741MiB/s (778MB/s-778MB/s), io=1024MiB
(1074MB), run=1381-1381msec
Disk stats (read/write):
nvme0n1: ios=216966/0, merge=0/0, ticks=6112/0, in_queue=704, util=91.34%
A write up of the larger problem follows (co-written with Jérôme Glisse):
Overview
Some kernel components (file systems, device drivers) need to access
memory that is specified via process virtual address. For a long time, the
API to achieve that was get_user_pages ("GUP") and its variations. However,
GUP has critical limitations that have been overlooked; in particular, GUP
does not interact correctly with filesystems in all situations. That means
that file-backed memory + GUP is a recipe for potential problems, some of
which have already occurred in the field.
GUP was first introduced for Direct IO (O_DIRECT), allowing filesystem code
to get the struct page behind a virtual address and to let storage hardware
perform a direct copy to or from that page. This is a short-lived access
pattern, and as such, the window for a concurrent writeback of GUP'd page
was small enough that there were not (we think) any reported problems.
Also, userspace was expected to understand and accept that Direct IO was
not synchronized with memory-mapped access to that data, nor with any
process address space changes such as munmap(), mremap(), etc.
Over the years, more GUP uses have appeared (virtualization, device
drivers, RDMA) that can keep the pages they get via GUP for a long period
of time (seconds, minutes, hours, days, ...). This long-term pinning makes
an underlying design problem more obvious.
In fact, there are a
[PATCH 4/6] mm/gup: track gup-pinned pages
From: John Hubbard Now that all callers of get_user_pages*() have been updated to use put_user_page(), instead of put_page(), add tracking of such "gup-pinned" pages. The purpose of this tracking is to answer the question "has this page been pinned by a call to get_user_pages()?" In order to answer that, refcounting is required. get_user_pages() and all its variants increment a reference count, and put_user_page() and its variants decrement that reference count. If the net count is *effectively* non-zero (see below), then the page is considered gup-pinned. What to do in response to encountering such a page, is left to later patchsets. There is discussion about this in [1], and in an upcoming patch that adds: Documentation/vm/get_user_pages.rst So, this patch simply adds tracking of such pages. In order to achieve this without using up any more bits or fields in struct page, the page->_refcount field is overloaded. gup pins are incremented by adding a large chunk (1024) instead of 1. This provides a way to say, "either this page is gup-pinned, or you have a *lot* of references on it, and thus this is a false positive". False positives are generally OK, as long as they are expected to be rare: taking action for a page that looks gup-pinned, but is not, is not going to be a problem. It's false negatives (failing to detect a gup-pinned page) that would be a problem, and those won't happen with this approach. This takes advantage of two distinct, pre-existing lock-free algorithms: a) get_user_pages() and things such as page_mkclean(), both operate on page table entries, without taking locks. This relies partly on just letting the CPU hardware (which of course also never takes locks to use its own page tables) just take page faults if something has changed. b) page_cache_get_speculative(), called by get_user_pages(), is a way to avoid having pages get freed out from under get_user_pages() or other things that want to pin pages. As a result, performance is expected to be unchanged in any noticeable way, by this patch. In order to test this, a lot of get_user_pages() call sites have to be converted over to use put_user_page(), but I did that locally, and here is an fio run on an NVMe drive, using this for the fio configuration file: [reader] direct=1 ioengine=libaio blocksize=4096 size=1g numjobs=1 rw=read iodepth=64 reader: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64 fio-3.3 Starting 1 process Jobs: 1 (f=1) reader: (groupid=0, jobs=1): err= 0: pid=7011: Sun Feb 3 20:36:51 2019 read: IOPS=190k, BW=741MiB/s (778MB/s)(1024MiB/1381msec) slat (nsec): min=2716, max=57255, avg=4048.14, stdev=1084.10 clat (usec): min=20, max=12485, avg=332.63, stdev=191.77 lat (usec): min=22, max=12498, avg=336.72, stdev=192.07 clat percentiles (usec): | 1.00th=[ 322], 5.00th=[ 322], 10.00th=[ 322], 20.00th=[ 326], | 30.00th=[ 326], 40.00th=[ 326], 50.00th=[ 326], 60.00th=[ 326], | 70.00th=[ 326], 80.00th=[ 330], 90.00th=[ 330], 95.00th=[ 330], | 99.00th=[ 478], 99.50th=[ 717], 99.90th=[ 1074], 99.95th=[ 1090], | 99.99th=[12256] bw ( KiB/s): min=730152, max=776512, per=99.22%, avg=753332.00, stdev=32781.47, samples=2 iops: min=182538, max=194128, avg=188333.00, stdev=8195.37, samples=2 lat (usec) : 50=0.01%, 100=0.01%, 250=0.07%, 500=99.26%, 750=0.38% lat (usec) : 1000=0.02% lat (msec) : 2=0.24%, 20=0.02% cpu : usr=15.07%, sys=84.13%, ctx=10, majf=0, minf=74 IO depths: 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: bw=741MiB/s (778MB/s), 741MiB/s-741MiB/s (778MB/s-778MB/s), io=1024MiB (1074MB), run=1381-1381msec Disk stats (read/write): nvme0n1: ios=216966/0, merge=0/0, ticks=6112/0, in_queue=704, util=91.34% [1] https://lwn.net/Articles/753027/ "The trouble with get_user_pages()" Suggested-by: Jan Kara Suggested-by: Jérôme Glisse Cc: Christian Benvenuti Cc: Christoph Hellwig Cc: Christopher Lameter Cc: Dan Williams Cc: Dave Chinner Cc: Dennis Dalessandro Cc: Doug Ledford Cc: Jan Kara Cc: Jason Gunthorpe Cc: Jérôme Glisse Cc: Matthew Wilcox Cc: Michal Hocko Cc: Mike Rapoport Cc: Mike Marciniszyn Cc: Ralph Campbell Cc: Tom Talpey Signed-off-by: John Hubbard --- include/linux/mm.h | 81 + include/linux/pagemap.h | 5 +++ mm/gup.c| 60 ++ mm/swap.c |
[PATCH 6/6] mm/gup: Documentation/vm/get_user_pages.rst, MAINTAINERS
From: John Hubbard
1. Added Documentation/vm/get_user_pages.rst
2. Added a GET_USER_PAGES entry in MAINTAINERS
Cc: Dan Williams
Cc: Jan Kara
Signed-off-by: Jérôme Glisse
Signed-off-by: John Hubbard
---
Documentation/vm/get_user_pages.rst | 197
Documentation/vm/index.rst | 1 +
MAINTAINERS | 10 ++
3 files changed, 208 insertions(+)
create mode 100644 Documentation/vm/get_user_pages.rst
diff --git a/Documentation/vm/get_user_pages.rst
b/Documentation/vm/get_user_pages.rst
new file mode 100644
index ..8598f20afb09
--- /dev/null
+++ b/Documentation/vm/get_user_pages.rst
@@ -0,0 +1,197 @@
+.. _get_user_pages:
+
+==
+get_user_pages
+==
+
+.. contents:: :local:
+
+Overview
+
+
+Some kernel components (file systems, device drivers) need to access
+memory that is specified via process virtual address. For a long time, the
+API to achieve that was get_user_pages ("GUP") and its variations. However,
+GUP has critical limitations that have been overlooked; in particular, GUP
+does not interact correctly with filesystems in all situations. That means
+that file-backed memory + GUP is a recipe for potential problems, some of
+which have already occurred in the field.
+
+GUP was first introduced for Direct IO (O_DIRECT), allowing filesystem code
+to get the struct page behind a virtual address and to let storage hardware
+perform a direct copy to or from that page. This is a short-lived access
+pattern, and as such, the window for a concurrent writeback of GUP'd page
+was small enough that there were not (we think) any reported problems.
+Also, userspace was expected to understand and accept that Direct IO was
+not synchronized with memory-mapped access to that data, nor with any
+process address space changes such as munmap(), mremap(), etc.
+
+Over the years, more GUP uses have appeared (virtualization, device
+drivers, RDMA) that can keep the pages they get via GUP for a long period
+of time (seconds, minutes, hours, days, ...). This long-term pinning makes
+an underlying design problem more obvious.
+
+In fact, there are a number of key problems inherent to GUP:
+
+Interactions with file systems
+==
+
+File systems expect to be able to write back data, both to reclaim pages,
+and for data integrity. Allowing other hardware (NICs, GPUs, etc) to gain
+write access to the file memory pages means that such hardware can dirty the
+pages, without the filesystem being aware. This can, in some cases
+(depending on filesystem, filesystem options, block device, block device
+options, and other variables), lead to data corruption, and also to kernel
+bugs of the form:
+
+::
+
+kernel BUG at /build/linux-fQ94TU/linux-4.4.0/fs/ext4/inode.c:1899!
+backtrace:
+
+ ext4_writepage
+ __writepage
+ write_cache_pages
+ ext4_writepages
+ do_writepages
+ __writeback_single_inode
+ writeback_sb_inodes
+ __writeback_inodes_wb
+ wb_writeback
+ wb_workfn
+ process_one_work
+ worker_thread
+ kthread
+ ret_from_fork
+
+...which is due to the file system asserting that there are still buffer
+heads attached:
+
+::
+
+ /* If we *know* page->private refers to buffer_heads */
+ #define page_buffers(page) \
+({ \
+BUG_ON(!PagePrivate(page)); \
+((struct buffer_head *)page_private(page)); \
+})
+ #define page_has_buffers(page) PagePrivate(page)
+
+Dave Chinner's description of this is very clear:
+
+"The fundamental issue is that ->page_mkwrite must be called on every
+write access to a clean file backed page, not just the first one.
+How long the GUP reference lasts is irrelevant, if the page is clean
+and you need to dirty it, you must call ->page_mkwrite before it is
+marked writeable and dirtied. Every. Time."
+
+This is just one symptom of the larger design problem: filesystems do not
+actually support get_user_pages() being called on their pages, and letting
+hardware write directly to those pages--even though that pattern has been
+going on since about 2005 or so.
+
+Long term GUP
+=
+
+Long term GUP is an issue when FOLL_WRITE is specified to GUP (so, a
+writeable mapping is created), and the pages are file-backed. That can lead
+to filesystem corruption. What happens is that when a file-backed page is
+being written back, it is first mapped read-only in all of the CPU page
+tables; the file system then assumes that nobody can write to the page, and
+that the page content is therefore stable. Unfortunately, the GUP callers
+generally do not monitor changes to the CPU pages tables; they instead
+assume that the following pattern is safe (it's not):
+
+::
+
+get_user_pages()
+
+Hardware then keeps a
[PATCH 2/6] infiniband/mm: convert put_page() to put_user_page*()
From: John Hubbard
For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()
This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:
1) Provide put_user_page*() routines, intended to be used
for releasing pages that were pinned via get_user_pages*().
2) Convert all of the call sites for get_user_pages*(), to
invoke put_user_page*(), instead of put_page(). This involves dozens of
call sites, and will take some time.
3) After (2) is complete, use get_user_pages*() and put_user_page*() to
implement tracking of these pages. This tracking will be separate from
the existing struct page refcounting.
4) Use the tracking and identification of these pages, to implement
special handling (especially in writeback paths) when the pages are
backed by a filesystem. Again, [1] provides details as to why that is
desirable.
[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Christian Benvenuti
Reviewed-by: Jan Kara
Reviewed-by: Dennis Dalessandro
Acked-by: Jason Gunthorpe
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 7 ---
drivers/infiniband/core/umem_odp.c | 2 +-
drivers/infiniband/hw/hfi1/user_pages.c | 11 ---
drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +++---
drivers/infiniband/hw/qib/qib_user_pages.c | 11 ---
drivers/infiniband/hw/qib/qib_user_sdma.c | 6 +++---
drivers/infiniband/hw/usnic/usnic_uiom.c| 7 ---
7 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index c6144df47ea4..c2898bc7b3b2 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -58,9 +58,10 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
page = sg_page(sg);
- if (!PageDirty(page) && umem->writable && dirty)
- set_page_dirty_lock(page);
- put_page(page);
+ if (umem->writable && dirty)
+ put_user_pages_dirty_lock(, 1);
+ else
+ put_user_page(page);
}
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index acb882f279cb..d32757c1f77e 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -663,7 +663,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp,
u64 user_virt,
ret = -EFAULT;
break;
}
- put_page(local_page_list[j]);
+ put_user_page(local_page_list[j]);
continue;
}
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index e341e6dcc388..99ccc0483711 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -121,13 +121,10 @@ int hfi1_acquire_user_pages(struct mm_struct *mm,
unsigned long vaddr, size_t np
void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
size_t npages, bool dirty)
{
- size_t i;
-
- for (i = 0; i < npages; i++) {
- if (dirty)
- set_page_dirty_lock(p[i]);
- put_page(p[i]);
- }
+ if (dirty)
+ put_user_pages_dirty_lock(p, npages);
+ else
+ put_user_pages(p, npages);
if (mm) { /* during close after signal, mm can be NULL */
down_write(>mmap_sem);
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index 112d2f38e0de..99108f3dcf01 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -481,7 +481,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct
mthca_uar *uar,
ret = pci_map_sg(dev->pdev, _tab->page[i].mem, 1, PCI_DMA_TODEVICE);
if (ret < 0) {
- put_page(pages[0]);
+ put_user_page(pages[0]);
goto out;
}
@@ -489,7 +489,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct
mthca_uar *uar,
mthca_uarc_virt(dev, uar, i));
if (ret) {
pci_unmap_sg(dev->pdev, _tab->page[i].mem, 1,
PCI_DMA_TODEVICE);
- put_page(sg_page(_tab->page[i].mem));
+ put_user_page(sg_page(_tab->page[i].mem));
goto out;
}
@@ -555,7 +555,7 @@ void
Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell
Date: Mon, 4 Feb 2019 15:34:46 +1100
> From: Stephen Rothwell
> Date: Mon, 4 Feb 2019 15:24:11 +1100
> Subject: [PATCH] socket: fix for Add SO_TIMESTAMP[NS]_NEW
>
> Fixes: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
> Signed-off-by: Stephen Rothwell
Thanks for fixing this.
Applied.
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (sparc64
defconfig) failed like this:
/home/sfr/next/next/net/core/sock.c: In function 'sock_setsockopt':
/home/sfr/next/next/net/core/sock.c:1146:2: error: duplicate case value
case SO_BINDTOIFINDEX:
^~~~
/home/sfr/next/next/net/core/sock.c:891:2: note: previously used here
case SO_TIMESTAMP_NEW:
^~~~
/home/sfr/next/next/net/core/sock.c: In function 'sock_getsockopt':
/home/sfr/next/next/net/core/sock.c:1493:2: error: duplicate case value
case SO_BINDTOIFINDEX:
^~~~
/home/sfr/next/next/net/core/sock.c:1293:2: note: previously used here
case SO_TIMESTAMP_NEW:
^~~~
Caused by commit
887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
I applied the following fix patch (I just update the clashing id rather
than update them all, but the latter may be better).
From: Stephen Rothwell
Date: Mon, 4 Feb 2019 15:24:11 +1100
Subject: [PATCH] socket: fix for Add SO_TIMESTAMP[NS]_NEW
Fixes: 887feae36aee ("socket: Add SO_TIMESTAMP[NS]_NEW")
Signed-off-by: Stephen Rothwell
---
arch/sparc/include/uapi/asm/socket.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/include/uapi/asm/socket.h
b/arch/sparc/include/uapi/asm/socket.h
index 8c9f74a66b55..88fe4f978aca 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -108,7 +108,7 @@
#define SO_TIMESTAMPNS_OLD 0x0021
#define SO_TIMESTAMPING_OLD 0x0023
-#define SO_TIMESTAMP_NEW 0x0041
+#define SO_TIMESTAMP_NEW 0x0046
#define SO_TIMESTAMPNS_NEW 0x0042
#define SO_TIMESTAMPING_NEW 0x0043
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpfHLWJlX8vm.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the net-next tree
Hi Dave,
On Sun, 03 Feb 2019 20:26:06 -0800 (PST) David Miller
wrote:
>
> Thanks, I just pushed the following:
>
>
> [PATCH] net: Fix fall through warning in y2038 tstamp changes.
>
> net/core/sock.c: In function 'sock_setsockopt':
> net/core/sock.c:914:3: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>sock_set_flag(sk, SOCK_TSTAMP_NEW);
>^~
> net/core/sock.c:915:2: note: here
> case SO_TIMESTAMPING_OLD:
> ^~~~
>
> Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")
> Reported-by: Stephen Rothwell
> Signed-off-by: David S. Miller
> ---
> net/core/sock.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index a8904ae40713..71ded4d8025c 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -912,6 +912,7 @@ int sock_setsockopt(struct socket *sock, int level, int
> optname,
>
> case SO_TIMESTAMPING_NEW:
> sock_set_flag(sk, SOCK_TSTAMP_NEW);
> + /* fall through */
> case SO_TIMESTAMPING_OLD:
> if (val & ~SOF_TIMESTAMPING_MASK) {
> ret = -EINVAL;
Looks good, thanks.
--
Cheers,
Stephen Rothwell
pgp_naabTlZDH.pgp
Description: OpenPGP digital signature
Re: [PATCH] netdevice.h: Add __cold to netdev_ logging functions
From: Joe Perches Date: Sat, 02 Feb 2019 19:47:25 -0800 > Add __cold to the netdev_ logging functions similar to > the use of __cold in the generic printk function. > > Using __cold moves all the netdev_ logging functions > out-of-line possibly improving code locality and runtime > performance. > > Signed-off-by: Joe Perches Sure, let's give this a try. I'll push this out to net-next when my build testing completes. Thanks.
Re: linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell
Date: Mon, 4 Feb 2019 10:44:27 +1100
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> net/core/sock.c: In function 'sock_setsockopt':
> net/core/sock.c:914:3: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>sock_set_flag(sk, SOCK_TSTAMP_NEW);
>^~
> net/core/sock.c:915:2: note: here
> case SO_TIMESTAMPING_OLD:
> ^~~~
>
> Introduced by commit
>
> 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")
Thanks, I just pushed the following:
[PATCH] net: Fix fall through warning in y2038 tstamp changes.
net/core/sock.c: In function 'sock_setsockopt':
net/core/sock.c:914:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
sock_set_flag(sk, SOCK_TSTAMP_NEW);
^~
net/core/sock.c:915:2: note: here
case SO_TIMESTAMPING_OLD:
^~~~
Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")
Reported-by: Stephen Rothwell
Signed-off-by: David S. Miller
---
net/core/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index a8904ae40713..71ded4d8025c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -912,6 +912,7 @@ int sock_setsockopt(struct socket *sock, int level, int
optname,
case SO_TIMESTAMPING_NEW:
sock_set_flag(sk, SOCK_TSTAMP_NEW);
+ /* fall through */
case SO_TIMESTAMPING_OLD:
if (val & ~SOF_TIMESTAMPING_MASK) {
ret = -EINVAL;
--
2.20.1
Re: [PATCH] bpfilter: remove extra header search paths for bpfilter_umh
From: Masahiro Yamada Date: Thu, 31 Jan 2019 12:15:35 +0900 > Currently, the header search paths -Itools/include and > -Itools/include/uapi are not used. Let's drop the unused code. > > We can remove -I. too by fixing up one C file. > > Signed-off-by: Masahiro Yamada I guess I'm ok with this, applied to net-next. Thanks for explaining things.
[PATCH] Uprobes: Fix deadlock between delayed_uprobe_lock and fs_reclaim
There can be a deadlock between delayed_uprobe_lock and
fs_reclaim like:
CPU0 CPU1
lock(fs_reclaim);
lock(delayed_uprobe_lock);
lock(fs_reclaim);
lock(delayed_uprobe_lock);
Here CPU0 is a file system code path which results in
mmput()->__mmput()->uprobe_clear_state() with fs_reclaim
locked. And, CPU1 is a uprobe event creation path.
This was reported by syzbot at [1]. Though, the reproducer
is nither available by syzbot nor I can reproduce it locally.
Callchains from syzbot report:
-> #1 (fs_reclaim){+.+.}:
__fs_reclaim_acquire mm/page_alloc.c:3730 [inline]
fs_reclaim_acquire.part.97+0x24/0x30 mm/page_alloc.c:3741
fs_reclaim_acquire+0x14/0x20 mm/page_alloc.c:3742
slab_pre_alloc_hook mm/slab.h:418 [inline]
slab_alloc mm/slab.c:3378 [inline]
kmem_cache_alloc_trace+0x2d/0x750 mm/slab.c:3618
kmalloc include/linux/slab.h:546 [inline]
kzalloc include/linux/slab.h:741 [inline]
delayed_uprobe_add kernel/events/uprobes.c:313 [inline]
update_ref_ctr+0x36f/0x590 kernel/events/uprobes.c:447
uprobe_write_opcode+0x94b/0xc50 kernel/events/uprobes.c:496
set_swbp+0x2a/0x40
install_breakpoint.isra.24+0x161/0x840 kernel/events/uprobes.c:885
register_for_each_vma+0xa38/0xee0 kernel/events/uprobes.c:1041
uprobe_apply+0xee/0x140 kernel/events/uprobes.c:1192
uprobe_perf_open kernel/trace/trace_uprobe.c:1087 [inline]
trace_uprobe_register+0x771/0xcf0 kernel/trace/trace_uprobe.c:1227
perf_trace_event_open kernel/trace/trace_event_perf.c:181 [inline]
perf_trace_event_init+0x1a5/0x990 kernel/trace/trace_event_perf.c:203
perf_uprobe_init+0x1f1/0x280 kernel/trace/trace_event_perf.c:329
perf_uprobe_event_init+0x106/0x1a0 kernel/events/core.c:8503
perf_try_init_event+0x137/0x2f0 kernel/events/core.c:9770
perf_init_event kernel/events/core.c:9801 [inline]
perf_event_alloc.part.94+0x1d54/0x3740 kernel/events/core.c:10074
perf_event_alloc kernel/events/core.c:10430 [inline]
__do_sys_perf_event_open+0xada/0x3020 kernel/events/core.c:10531
__se_sys_perf_event_open kernel/events/core.c:10420 [inline]
__x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10420
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (delayed_uprobe_lock){+.+.}:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
__mutex_lock_common kernel/locking/mutex.c:925 [inline]
__mutex_lock+0x166/0x16f0 kernel/locking/mutex.c:1072
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
uprobe_clear_state+0xb4/0x390 kernel/events/uprobes.c:1511
__mmput kernel/fork.c:1041 [inline]
mmput+0x1bc/0x610 kernel/fork.c:1066
binder_alloc_free_page+0x5ab/0x1520 drivers/android/binder_alloc.c:983
__list_lru_walk_one+0x29d/0x8c0 mm/list_lru.c:234
list_lru_walk_one+0xa5/0xe0 mm/list_lru.c:278
list_lru_walk_node+0x43/0x280 mm/list_lru.c:307
list_lru_walk include/linux/list_lru.h:214 [inline]
binder_shrink_scan+0x164/0x220 drivers/android/binder_alloc.c:1019
do_shrink_slab+0x501/0xd30 mm/vmscan.c:557
shrink_slab+0x389/0x8c0 mm/vmscan.c:706
shrink_node+0x431/0x16b0 mm/vmscan.c:2758
shrink_zones mm/vmscan.c:2987 [inline]
do_try_to_free_pages+0x3e7/0x1290 mm/vmscan.c:3049
try_to_free_pages+0x4d0/0xb90 mm/vmscan.c:3264
__perform_reclaim mm/page_alloc.c:3773 [inline]
__alloc_pages_direct_reclaim mm/page_alloc.c:3795 [inline]
__alloc_pages_slowpath+0xa48/0x2de0 mm/page_alloc.c:4185
__alloc_pages_nodemask+0xad8/0xea0 mm/page_alloc.c:4393
__alloc_pages include/linux/gfp.h:473 [inline]
__alloc_pages_node include/linux/gfp.h:486 [inline]
khugepaged_alloc_page+0x95/0x190 mm/khugepaged.c:773
collapse_huge_page mm/khugepaged.c:963 [inline]
khugepaged_scan_pmd+0x1715/0x3d60 mm/khugepaged.c:1216
khugepaged_scan_mm_slot mm/khugepaged.c:1725 [inline]
khugepaged_do_scan mm/khugepaged.c:1806 [inline]
khugepaged+0xf20/0x1750 mm/khugepaged.c:1851
kthread+0x35a/0x440 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1876397.html
Reported-by: syzbot+1068f09c44d151250...@syzkaller.appspotmail.com
Suggested-by: Aneesh Kumar K.V
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 24
1 file changed, 24 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 8aef47ee7bfa..8be39a83d83a 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -95,6 +95,11 @@ struct delayed_uprobe {
struct mm_struct *mm;
};
+/*
+ * Any memory allocation happening within lock(delayed_uprobe_lock)
+ * must use memalloc_nofs_save()/memalloc_nofs_restore() to
Re: [PATCH] fs: add a comment explaining how MNT_NS_INTERNAL affects mnt_may_suid()
On Wed, Nov 21, 2018 at 8:59 PM Jann Horn wrote:
> commit 380cf5ba6b0a ("fs: Treat foreign mounts as nosuid"), in addition to
> the intended effect, also prevented suid execution of memfd files.
> (And I think that's a good change.)
Ping. Al, can you take this into your tree? fs/namespace.c is your stuff, right?
> Signed-off-by: Jann Horn
> ---
> fs/namespace.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index a7f91265ea67..e68488426e42 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3400,6 +3400,9 @@ bool mnt_may_suid(struct vfsmount *mnt)
> * prevents namespaces from trusting potentially unsafe
> * suid/sgid bits, file caps, or security labels that originate
> * in other namespaces.
> +*
> +* check_mnt() rejects MNT_NS_INTERNAL mounts; this means that suid
> +* execution is blocked for files on internal mounts, e.g. memfds.
> */
> return !(mnt->mnt_flags & MNT_NOSUID) && check_mnt(real_mount(mnt)) &&
>current_in_userns(mnt->mnt_sb->s_user_ns);
> --
> 2.20.0.rc0.387.gc7a69e6b6c-goog
>
Re: [PATCH] drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu
Alex,
can you get this into next and resend the pull?
I don't like adding warnings.
Dave.
On Fri, 1 Feb 2019 at 06:10, Kuehling, Felix wrote:
>
> Thank you, Nathan. I applied your patch to amd-staging-drm-next.
>
> Sorry for the late response. I'm catching up with my email backlog after
> a vacation.
>
> Regards,
>Felix
>
> On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: warning:
> > 'CONFIG_X86_64' is not defined, evaluates to 0 [-Wundef]
> > #if CONFIG_X86_64
> > ^
> > 1 warning generated.
> >
> > Fixes: d1c234e2cd10 ("drm/amdkfd: Allow building KFD on ARM64 (v2)")
> > Signed-off-by: Nathan Chancellor
> > ---
> >
> > Resending as I forgot to add the lists...
> >
> > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > index 5d85ff341385..2e7c44955f43 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> > @@ -863,7 +863,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id,
> > int *avail_size,
> > return 0;
> > }
> >
> > -#if CONFIG_X86_64
> > +#ifdef CONFIG_X86_64
> > static int kfd_fill_iolink_info_for_cpu(int numa_node_id, int *avail_size,
> > uint32_t *num_entries,
> > struct crat_subtype_iolink *sub_type_hdr)
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] media: videobuf2: Return error after allocation failure
On Mon, Feb 4, 2019 at 3:25 AM Nicolas Dufresne wrote:
>
> Le dimanche 03 février 2019 à 19:06 +0530, Souptick Joarder a écrit :
> > There is no point to continuing assignemnt after memory allocation
>
> assignemnt -> assignment.
Ah, type.
>
> > failed, rather throw error immediately.
> >
> > Signed-off-by: Souptick Joarder
> > ---
> > drivers/media/common/videobuf2/videobuf2-vmalloc.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> > b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> > index 6dfbd5b..d3f71e2 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> > @@ -46,16 +46,16 @@ static void *vb2_vmalloc_alloc(struct device *dev,
> > unsigned long attrs,
> >
> > buf->size = size;
> > buf->vaddr = vmalloc_user(buf->size);
> > - buf->dma_dir = dma_dir;
> > - buf->handler.refcount = >refcount;
> > - buf->handler.put = vb2_vmalloc_put;
> > - buf->handler.arg = buf;
> >
> > if (!buf->vaddr) {
> > pr_debug("vmalloc of size %ld failed\n", buf->size);
> > kfree(buf);
> > return ERR_PTR(-ENOMEM);
> > }
> > + buf->dma_dir = dma_dir;
> > + buf->handler.refcount = >refcount;
> > + buf->handler.put = vb2_vmalloc_put;
> > + buf->handler.arg = buf;
> >
> > refcount_set(>refcount, 1);
> > return buf;
>
[PATCH 1/3] kallsyms: add static qualifiers where missing
Fix the following sparse warnings:
scripts/kallsyms.c:65:5: warning: symbol 'token_profit' was not declared.
Should it be static?
scripts/kallsyms.c:68:15: warning: symbol 'best_table' was not declared. Should
it be static?
scripts/kallsyms.c:69:15: warning: symbol 'best_table_len' was not declared.
Should it be static?
Also, remove 'inline' from is_arm_mapping_symbol(). The compiler
will inline it anyway when it is appropriate to do so.
Signed-off-by: Masahiro Yamada
---
scripts/kallsyms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 77cebad..fc00bb0 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -62,11 +62,11 @@ static int all_symbols = 0;
static int absolute_percpu = 0;
static int base_relative = 0;
-int token_profit[0x1];
+static int token_profit[0x1];
/* the table that holds the result of the compression */
-unsigned char best_table[256][2];
-unsigned char best_table_len[256];
+static unsigned char best_table[256][2];
+static unsigned char best_table_len[256];
static void usage(void)
@@ -80,7 +80,7 @@ static void usage(void)
* This ignores the intensely annoying "mapping symbols" found
* in ARM ELF files: $a, $t and $d.
*/
-static inline int is_arm_mapping_symbol(const char *str)
+static int is_arm_mapping_symbol(const char *str)
{
return str[0] == '$' && strchr("axtd", str[1])
&& (str[2] == '\0' || str[2] == '.');
--
2.7.4
[PATCH 3/3] kallsyms: include instead of
is enough to include the definition of
BITS_PER_LONG.
Signed-off-by: Masahiro Yamada
---
scripts/kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index f1b5749..03ff265 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -331,7 +331,7 @@ static void write_src(void)
unsigned int *markers;
char buf[KSYM_NAME_LEN];
- printf("#include \n");
+ printf("#include \n");
printf("#if BITS_PER_LONG == 64\n");
printf("#define PTR .quad\n");
printf("#define ALGN .balign 8\n");
--
2.7.4
[PATCH 2/3] kallsyms: remove unneeded memset() calls
Global variables in the .bss section are zeroed out before the program
starts to run.
Signed-off-by: Masahiro Yamada
---
scripts/kallsyms.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index fc00bb0..f1b5749 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -596,9 +596,6 @@ static void insert_real_symbols_in_table(void)
{
unsigned int i, j, c;
- memset(best_table, 0, sizeof(best_table));
- memset(best_table_len, 0, sizeof(best_table_len));
-
for (i = 0; i < table_cnt; i++) {
for (j = 0; j < table[i].len; j++) {
c = table[i].sym[j];
--
2.7.4
Re: [PATCH] mm/slab: Increase width of first /proc/slabinfo column
On Thu, Jan 31, 2019 at 06:43:10PM -0800, Matthew Wilcox wrote: > On Fri, Feb 01, 2019 at 11:42:42AM +1100, Tobin C. Harding wrote: > > Currently when displaying /proc/slabinfo if any cache names are too long > > then the output columns are not aligned. We could do something fancy to > > get the maximum length of any cache name in the system or we could just > > increase the hardcoded width. Currently it is 17 characters. Monitors > > are wide these days so lets just increase it to 30 characters. > > I had a proposal some time ago to turn the slab name from being kmalloced > to being an inline 16 bytes (with some fun hacks for cgroups). I think > that's a better approach than permitting such long names. For example, > ext4_allocation_context could be shortened to ext4_alloc_ctx without > losing any expressivity. > > Let me know if you can't find that and I'll try to dig it up. Hi Willy, I haven't managed to find the patch, I grep'ed LKML using a bunch of search terms via the google group linux.kernel. Then I tried a bunch of different search strings in google prefixed with `site:kernel.org`. All to no avail. I have an idea how to fix it without making life less convenient for developers *or* for users, I know we don't discuss changes without a patch so I'll hack it up. I'm sure your solution contains things I don't understand yet (read: the cgroups bit) so I'd love to bring your patch back to life but am happy to work on another solution as well in the name of education. thanks, Tobin.
[PATCH v2 3/3] slub: Correct grammar/punctuation in comments
Currently there are a few minor grammatical errors in the comments.
While we are at it we can fix punctuation to be correct and uniform
also.
Correct grammar/punctuation in comments.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index a3f1fc7e52a6..d2153789bd9f 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -81,12 +81,12 @@ struct kmem_cache_order_objects {
*/
struct kmem_cache {
struct kmem_cache_cpu __percpu *cpu_slab;
- /* Used for retriving partial slabs etc */
+ /* Used for retrieving partial slabs, etc. */
slab_flags_t flags;
unsigned long min_partial;
- unsigned int size; /* The size of an object including meta data */
- unsigned int object_size;/* The size of an object without meta data */
- unsigned int offset;/* Free pointer offset. */
+ unsigned int size; /* The size of an object including metadata */
+ unsigned int object_size;/* The size of an object without metadata */
+ unsigned int offset;/* Free pointer offset */
#ifdef CONFIG_SLUB_CPU_PARTIAL
/* Number of per cpu partial objects to keep around */
unsigned int cpu_partial;
--
2.20.1
[PATCH v2 1/3] slub: Capitialize comment string
SLUB include file has particularly clean comments, one comment string is
holding us back.
Capitialize comment string.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 3a1a1dbc6f49..541b082ffcaf 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -110,7 +110,7 @@ struct kmem_cache {
#endif
#ifdef CONFIG_MEMCG
struct memcg_cache_params memcg_params;
- /* for propagation, maximum size of a stored attr */
+ /* For propagation, maximum size of a stored attr */
unsigned int max_attr_size;
#ifdef CONFIG_SYSFS
struct kset *memcg_kset;
--
2.20.1
[PATCH v2 2/3] slub: Use C89 comment style
SLUB include file uses a c99 comment style. In line with the rest of
the kernel lets use c89 comment style.
Use C89 comment style.
Signed-off-by: Tobin C. Harding
---
include/linux/slub_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 541b082ffcaf..a3f1fc7e52a6 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -151,7 +151,7 @@ struct kmem_cache {
#else
#define slub_cpu_partial(s)(0)
#define slub_set_cpu_partial(s, n)
-#endif // CONFIG_SLUB_CPU_PARTIAL
+#endif /* CONFIG_SLUB_CPU_PARTIAL */
#ifdef CONFIG_SYSFS
#define SLAB_SUPPORTS_SYSFS
--
2.20.1
[PATCH v2 0/3] slub: Do trivial comments fixes
Hi, Here is v2 of the comments fixes [to single SLUB header file]. thanks, Tobin. Changes since v1: - Re-order patches (put the easy acceptable ones from v1 first). - Do grammar/punctuation fixes thoroughly (thanks William). - Send the set to Andrew instead of Christopher since we are going in through his tree. Tobin C. Harding (3): slub: Capitialize comment string slub: Use C89 comment style slub: Correct grammar/punctuation in comments include/linux/slub_def.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 2.20.1
Re: Userspace regression with 6baca7601bde ("scsi: target: drop unused pi_prot_format attribute storage")
Hi Laura, Thanks for the report... On Sun, 3 Feb 2019 17:56:00 +0100, Laura Abbott wrote: > Fedora got a bug report of a new permission denied error with 5.0-rc2: > > > File "/usr/lib/python3.7/site-packages/rtslib_fb/utils.py", line 100, in > > fread > > with open(path, 'r') as file_fd: > > PermissionError: [Errno 13] Permission denied: > > '/sys/kernel/config/target/core/fileio_28/xxx/attrib/pi_prot_format' > > This looks like an intentional behavior change with > > commit 6baca7601bdee2e57f20c45d63eb53b89b33e816 > Author: David Disseldorp > Date: Fri Nov 23 18:36:11 2018 +0100 > > scsi: target: drop unused pi_prot_format attribute storage > > On write, the pi_prot_format configfs attribute invokes the device > format_prot() callback if present. Read dumps the contents of > se_dev_attrib.pi_prot_format which is always zero. Make the configfs > attribute write-only, and drop the always zero > se_dev_attrib.pi_prot_format > storage. > > Signed-off-by: David Disseldorp > Reviewed-by: Christoph Hellwig > Signed-off-by: Martin K. Petersen > > > Unfortunately, existing code that's opening with read permissions is now > broken. > Can this be reverted? Full bug at > https://bugzilla.redhat.com/show_bug.cgi?id=1667505 Lee (cc'ed) pinged me a couple of days ago about the same issue. My preference would be to add back a dummy read handler without the corresponding (unused) se_dev_attrib.pi_prot_format member. I'll prepare something tomorrow with this, but if it's urgent then I'd also be okay with a straight revert. Cheers, David
[PATCH v2 2/3] dt-bindings: iio/adc: Add bindings for Ingenic JZ47xx SoCs ADC.
Add device tree bindings for the ADC controller on JZ47xx SoCs, used by the ingenic-adc driver. Signed-off-by: Artur Rojek --- Changes: v2: no change include/dt-bindings/iio/adc/ingenic,adc.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 include/dt-bindings/iio/adc/ingenic,adc.h diff --git a/include/dt-bindings/iio/adc/ingenic,adc.h b/include/dt-bindings/iio/adc/ingenic,adc.h new file mode 100644 index ..82706b2706ac --- /dev/null +++ b/include/dt-bindings/iio/adc/ingenic,adc.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DT_BINDINGS_IIO_ADC_INGENIC_ADC_H +#define _DT_BINDINGS_IIO_ADC_INGENIC_ADC_H + +/* ADC channel idx. */ +#define INGENIC_ADC_AUX0 +#define INGENIC_ADC_BATTERY1 + +#endif -- 2.20.1
[PATCH v2 3/3] IIO: add Ingenic JZ47xx ADC driver.
Add an IIO driver for the ADC hardware present on Ingenic JZ47xx SoCs.
Signed-off-by: Artur Rojek
---
Changes:
v2: - prefix all platform defines with JZ_ADC_*,
- replace spinlock with a mutex,
- change devm_add_action to devm_add_action_or_reset,
- add a function wrapper for clk_unprepare,
- change iio_dev->name from "adc" to "jz-adc",
- simplify error handling code for devm_iio_device_register
drivers/iio/adc/Kconfig | 9 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ingenic-adc.c | 363 ++
3 files changed, 373 insertions(+)
create mode 100644 drivers/iio/adc/ingenic-adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7a3ca4ec0cb7..f9f349a22b04 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -367,6 +367,15 @@ config INA2XX_ADC
Say yes here to build support for TI INA2xx family of Power Monitors.
This driver is mutually exclusive with the HWMON version.
+config INGENIC_ADC
+ tristate "Ingenic JZ47xx SoCs ADC driver"
+ depends on MIPS || COMPILE_TEST
+ help
+ Say yes here to build support for the Ingenic JZ47xx SoCs ADC unit.
+
+ This driver can also be built as a module. If so, the module will be
+ called ingenic_adc.
+
config IMX7D_ADC
tristate "Freescale IMX7D ADC driver"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 07df37f621bd..0a7acab33b91 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_HI8435) += hi8435.o
obj-$(CONFIG_HX711) += hx711.o
obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
+obj-$(CONFIG_INGENIC_ADC) += ingenic-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
diff --git a/drivers/iio/adc/ingenic-adc.c b/drivers/iio/adc/ingenic-adc.c
new file mode 100644
index ..1f436df1fd45
--- /dev/null
+++ b/drivers/iio/adc/ingenic-adc.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ADC driver for the Ingenic JZ47xx SoCs
+ * Copyright (c) 2019 Artur Rojek
+ *
+ * based on drivers/mfd/jz4740-adc.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define JZ_ADC_REG_ENABLE 0x00
+#define JZ_ADC_REG_CFG 0x04
+#define JZ_ADC_REG_CTRL0x08
+#define JZ_ADC_REG_STATUS 0x0c
+#define JZ_ADC_REG_ADTCH 0x18
+#define JZ_ADC_REG_ADBDAT 0x1c
+#define JZ_ADC_REG_ADSDAT 0x20
+
+#define JZ_ADC_REG_CFG_BAT_MD BIT(4)
+
+#define JZ_ADC_AUX_VREF3300
+#define JZ_ADC_AUX_VREF_BITS 12
+#define JZ_ADC_BATTERY_LOW_VREF2500
+#define JZ_ADC_BATTERY_LOW_VREF_BITS 12
+#define JZ4725B_ADC_BATTERY_HIGH_VREF 7500
+#define JZ4725B_ADC_BATTERY_HIGH_VREF_BITS 10
+#define JZ4740_ADC_BATTERY_HIGH_VREF (7500 * 0.986)
+#define JZ4740_ADC_BATTERY_HIGH_VREF_BITS 12
+
+struct ingenic_adc_soc_data {
+ unsigned int battery_high_vref;
+ unsigned int battery_high_vref_bits;
+ const int *battery_raw_avail;
+ size_t battery_raw_avail_size;
+ const int *battery_scale_avail;
+ size_t battery_scale_avail_size;
+};
+
+struct ingenic_adc {
+ void __iomem *base;
+ struct clk *clk;
+ struct mutex lock;
+ const struct ingenic_adc_soc_data *soc_data;
+ bool low_vref_mode;
+};
+
+static void ingenic_adc_set_config(struct ingenic_adc *adc,
+ uint32_t mask,
+ uint32_t val)
+{
+ uint32_t cfg;
+
+ clk_enable(adc->clk);
+ mutex_lock(>lock);
+
+ cfg = readl(adc->base + JZ_ADC_REG_CFG) & ~mask;
+ cfg |= val;
+ writel(cfg, adc->base + JZ_ADC_REG_CFG);
+
+ mutex_unlock(>lock);
+ clk_disable(adc->clk);
+}
+
+static void ingenic_adc_enable(struct ingenic_adc *adc,
+ int engine,
+ bool enabled)
+{
+ u8 val;
+
+ mutex_lock(>lock);
+ val = readb(adc->base + JZ_ADC_REG_ENABLE);
+
+ if (enabled)
+ val |= BIT(engine);
+ else
+ val &= ~BIT(engine);
+
+ writeb(val, adc->base + JZ_ADC_REG_ENABLE);
+ mutex_unlock(>lock);
+}
+
+static int ingenic_adc_capture(struct ingenic_adc *adc,
+ int engine)
+{
+ u8 val;
+ int ret;
+
+ ingenic_adc_enable(adc, engine, true);
+ ret = readb_poll_timeout(adc->base + JZ_ADC_REG_ENABLE, val,
+!(val & BIT(engine)), 250, 1000);
+ if (ret)
+ ingenic_adc_enable(adc, engine, false);
+
+ return ret;
+}
+
[PATCH v2 1/3] dt-bindings: iio/adc: Add docs for Ingenic JZ47xx SoCs ADC.
Add documentation for the ADC controller on JZ47xx SoCs,
used by the ingenic-adc driver.
Signed-off-by: Artur Rojek
---
Changes:
v2: change a typo ',' into ';' in battery example
.../bindings/iio/adc/ingenic,adc.txt | 48 +++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt
b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt
new file mode 100644
index ..f01159f20d87
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt
@@ -0,0 +1,48 @@
+* Ingenic JZ47xx ADC controller IIO bindings
+
+Required properties:
+
+- compatible: Should be one of:
+ * ingenic,jz4725b-adc
+ * ingenic,jz4740-adc
+- reg: ADC controller registers location and length.
+- clocks: phandle to the SoC's ADC clock.
+- clock-names: Must be set to "adc".
+- #io-channel-cells: Must be set to <1> to indicate channels are selected
+ by index.
+
+ADC clients must use the format described in iio-bindings.txt, giving
+a phandle and IIO specifier pair ("io-channels") to the ADC controller.
+
+Example:
+
+#include
+
+adc: adc@1007 {
+ compatible = "ingenic,jz4740-adc";
+ #io-channel-cells = <1>;
+
+ reg = <0x1007 0x30>;
+
+ clocks = < JZ4740_CLK_ADC>;
+ clock-names = "adc";
+
+ interrupt-parent = <>;
+ interrupts = <18>;
+};
+
+adc-keys {
+ ...
+ compatible = "adc-keys";
+ io-channels = < INGENIC_ADC_AUX>;
+ io-channel-names = "buttons";
+ ...
+};
+
+battery {
+ ...
+ compatible = "ingenic,jz4740-battery";
+ io-channels = < INGENIC_ADC_BATTERY>;
+ io-channel-names = "battery";
+ ...
+};
--
2.20.1
linux-next: build failure after merge of the drm-tegra tree
Hi Thierry,
After merging the drm-tegra tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/host1x/cdma.c: In function 'host1x_cdma_wait_pushbuffer_space':
drivers/gpu/host1x/cdma.c:279:13: error: 'struct host1x_cdma' has no member
named 'sem'
down(>sem);
^~
Caused by commit
abb289796799 ("gpu: host1x: Use completion instead of semaphore")
interacting with commit
db5652be58a9 ("gpu: host1x: Introduce support for wide opcodes")
I have used the drm-tegra tree from next-20190201 for today.
--
Cheers,
Stephen Rothwell
pgp5NLEIfrY_f.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the crypto tree
Hi Herbert,
After merging the crypto tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/crypto/qat/qat_common/adf_transport.c: In function 'adf_init_etr_data':
drivers/crypto/qat/qat_common/adf_transport.c:501:1: warning: label
'err_bank_debug' defined but not used [-Wunused-label]
err_bank_debug:
^~
Introduced by commit
f0fcf9ade46a ("crypto: qat - no need to check return value of debugfs_create
functions")
--
Cheers,
Stephen Rothwell
pgpCUD5vkjmbN.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
net/core/sock.c: In function 'sock_setsockopt':
net/core/sock.c:914:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
sock_set_flag(sk, SOCK_TSTAMP_NEW);
^~
net/core/sock.c:915:2: note: here
case SO_TIMESTAMPING_OLD:
^~~~
Introduced by commit
9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW")
I get this warning because I am building with -Wimplicit-fallthrough
in attempt to catch new additions early. The gcc warning can be turned
off by adding a /* fall through */ comment at the point the fall through
happens (assuming that the fall through is intentional).
--
Cheers,
Stephen Rothwell
pgpJETXRNn1Gx.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm/slab: Increase width of first /proc/slabinfo column
On Fri, Feb 01, 2019 at 07:27:24PM -0800, Joe Perches wrote: > On Fri, 2019-02-01 at 11:42 +1100, Tobin C. Harding wrote: > > Increase the width of the first column (cache name) in the output of > > /proc/slabinfo from 17 to 30 characters. > > Do you care if this breaks any parsing of /proc/slabinfo? > > I don't but someone might. Thanks for looking at the patch Joe, Christoph pointed this out also. Solution is going to take a different approach and not touch the column width in /proc/slabinfo for the record, although it does not really matter now, I think that anyone parsing /proc/slabinfo would be using whitespace because the name field is already variable length. Anyways, new patch to come. thanks, Tobin.
Re: Applied "regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for AXP803" to the regulator tree
Hey Mark,
Could you please apply it into your for-5.0 branch? It's a fix for a
regression and without this patch axp803 is broken in 5.0.
Regards,
Vasily
On Mon, Jan 28, 2019 at 4:35 AM Mark Brown wrote:
>
> The patch
>
>regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for AXP803
>
> has been applied to the regulator tree at
>
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From 252d1c20551b745f33a490892335d2b09f5d48a7 Mon Sep 17 00:00:00 2001
> From: Vasily Khoruzhick
> Date: Fri, 25 Jan 2019 22:18:09 -0800
> Subject: [PATCH] regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for
> AXP803
>
> Looks like refactoring didn't go well and left ALDO2, DLDO2 and ELDO3
> definitions broken for AXP803 - now they are using register address
> instead of mask. Fix it by using mask where necessary.
>
> Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
> Signed-off-by: Vasily Khoruzhick
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Mark Brown
> ---
> drivers/regulator/axp20x-regulator.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 0dfa4ea6bbdf..087cadb96fab 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -723,7 +723,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_ALDO1_V_OUT, AXP22X_ALDO1_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO1_MASK),
> AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
> -AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT,
> +AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO2_MASK),
> AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
> AXP22X_ALDO3_V_OUT, AXP22X_ALDO3_V_OUT_MASK,
> @@ -733,7 +733,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO1_MASK),
> AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin",
> axp803_dldo2_ranges, AXP803_DLDO2_NUM_VOLTAGES,
> - AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT,
> + AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO2_MASK),
> AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
> AXP22X_DLDO3_V_OUT, AXP22X_DLDO3_V_OUT_MASK,
> @@ -748,7 +748,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_ELDO2_V_OUT, AXP22X_ELDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO2_MASK),
> AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
> -AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT,
> +AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO3_MASK),
> AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
> AXP803_FLDO1_V_OUT, AXP803_FLDO1_V_OUT_MASK,
> --
> 2.20.1
>
Re: [PATCH] tpm/st33zp24: Fix name collision with TPM_BUFSIZE
Hi Jarkko,
On Fri, 2019-02-01 at 19:41 +0200, Jarkko Sakkinen wrote:
> Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
> ST33ZP24_BUFSIZE as it collides with TPM_BUFSIZE defined in
> drivers/char/tpm/tpm.h.
>
> Cc: sta...@vger.kernel.org
> Fixes: bf38b8710892 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2
> layers (core + phy)")
> Signed-off-by: Jarkko Sakkinen
FYI, I'm seeing a similar redefined TPM_BUFSIZE in tpm_i2c_infineon.c.
Mimi
> ---
> drivers/char/tpm/st33zp24/i2c.c | 2 +-
> drivers/char/tpm/st33zp24/spi.c | 2 +-
> drivers/char/tpm/st33zp24/st33zp24.h | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/tpm/st33zp24/i2c.c b/drivers/char/tpm/st33zp24/i2c.c
> index be5d1abd3e8e..8390c5b54c3b 100644
> --- a/drivers/char/tpm/st33zp24/i2c.c
> +++ b/drivers/char/tpm/st33zp24/i2c.c
> @@ -33,7 +33,7 @@
>
> struct st33zp24_i2c_phy {
> struct i2c_client *client;
> - u8 buf[TPM_BUFSIZE + 1];
> + u8 buf[ST33ZP24_BUFSIZE + 1];
> int io_lpcpd;
> };
>
> diff --git a/drivers/char/tpm/st33zp24/spi.c b/drivers/char/tpm/st33zp24/spi.c
> index d7909ab287a8..ff019a1e3c68 100644
> --- a/drivers/char/tpm/st33zp24/spi.c
> +++ b/drivers/char/tpm/st33zp24/spi.c
> @@ -63,7 +63,7 @@
> * some latency byte before the answer is available (max 15).
> * We have 2048 + 1024 + 15.
> */
> -#define ST33ZP24_SPI_BUFFER_SIZE (TPM_BUFSIZE + (TPM_BUFSIZE / 2) +\
> +#define ST33ZP24_SPI_BUFFER_SIZE (ST33ZP24_BUFSIZE + (ST33ZP24_BUFSIZE / 2)
> +\
> MAX_SPI_LATENCY)
>
>
> diff --git a/drivers/char/tpm/st33zp24/st33zp24.h
> b/drivers/char/tpm/st33zp24/st33zp24.h
> index 6f4a4198af6a..20da0a84988d 100644
> --- a/drivers/char/tpm/st33zp24/st33zp24.h
> +++ b/drivers/char/tpm/st33zp24/st33zp24.h
> @@ -18,8 +18,8 @@
> #ifndef __LOCAL_ST33ZP24_H__
> #define __LOCAL_ST33ZP24_H__
>
> -#define TPM_WRITE_DIRECTION 0x80
> -#define TPM_BUFSIZE 2048
> +#define TPM_WRITE_DIRECTION 0x80
> +#define ST33ZP24_BUFSIZE 2048
>
> struct st33zp24_dev {
> struct tpm_chip *chip;
Re: [PATCH ghak105 V3] audit: remove audit_context when CONFIG_ AUDIT and not AUDITSYSCALL
On Fri, Feb 1, 2019 at 10:45 PM Richard Guy Briggs wrote: > > Remove audit_context from struct task_struct and struct audit_buffer > when CONFIG_AUDIT is enabled but CONFIG_AUDITSYSCALL is not. > > Also, audit_log_name() (and supporting inode and fcaps functions) should > have been put back in auditsc.c when soft and hard link logging was > normalized since it is only used by syscall auditing. > > See github issue https://github.com/linux-audit/audit-kernel/issues/105 > > Signed-off-by: Richard Guy Briggs > --- > Tested with CONFIG_AUDITSYSCALL automatically set "y" and manually set > "n". Passes all audit-testsuite with the former and the expected subset > that don't depend on syscall auditing for the latter. > > changelog v2: > - guard audit_context by CONFIG_AUDITSYSCALL in task_struct > - rebase/resolve merge conflicts on upstreamed ghak103 v1.1/1 > > changelog v3: > - re-instate audit_context in audit_buffer (though not needed) > - rebase/resolve merge conflicts on upstreamed ghak100 v2.2/2 > > include/linux/sched.h | 4 +- > kernel/audit.c| 157 - > kernel/audit.h| 9 --- > kernel/auditsc.c | 158 > ++ > 4 files changed, 161 insertions(+), 167 deletions(-) Merged into audit/next, thanks. -- paul moore www.paul-moore.com
linux-next: build warning after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:14,
from include/linux/fs_context.h:15,
from fs/fs_parser.c:13:
fs/fs_parser.c: In function 'fs_validate_description':
include/linux/kern_levels.h:5:18: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^~
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:303:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
fs/fs_parser.c:413:6: note: in expansion of macro 'pr_err'
pr_err("VALIDATE %s: e[%lu] enum val for %s\n",
^~
fs/fs_parser.c:413:31: note: format string is defined here
pr_err("VALIDATE %s: e[%lu] enum val for %s\n",
~~^
%u
Introduced by commit
f512b838c104 ("vfs: Add configuration parser helpers")
--
Cheers,
Stephen Rothwell
pgpfGin2N0KVM.pgp
Description: OpenPGP digital signature
Re: [PATCHv3 net] sctp: check and update stream->out_curr when allocating stream_out
From: Xin Long
Date: Mon, 4 Feb 2019 03:27:58 +0800
> Now when using stream reconfig to add out streams, stream->out
> will get re-allocated, and all old streams' information will
> be copied to the new ones and the old ones will be freed.
>
> So without stream->out_curr updated, next time when trying to
> send from stream->out_curr stream, a panic would be caused.
>
> This patch is to check and update stream->out_curr when
> allocating stream_out.
>
> v1->v2:
> - define fa_index() to get elem index from stream->out_curr.
> v2->v3:
> - repost with no change.
>
> Fixes: 5e32a431 ("sctp: introduce stream scheduler foundations")
> Reported-by: Ying Xu
> Reported-by: syzbot+e33a3a138267ca119...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
Applied and queued up for -stable.
Thanks!
Re: [PATCH] selftests: add TPM 2.0 tests
Hi Jarkko, > Added the tests that I've been using for testing TPM 2.0 functionality > for long time but have out-of-tree so far residing in > https://github.com/jsakkine-intel/tpm2-scripts > Cc: Tadeusz Struk > Signed-off-by: Jarkko Sakkinen > Acked-By: Joey Pabalinas Reviewed-by: Petr Vorel > +++ b/tools/testing/selftests/tpm2/Makefile > @@ -0,0 +1,3 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) > + > +TEST_PROGS := test_smoke.sh test_space.sh Maybe include lib.mk, to avoid make No targets error? (well, it's reported for more tests) include ../lib.mk make[1]: Entering directory '/home/pevik/install/src/linux.git/tools/testing/selftests/tpm2' make[1]: *** No targets. Stop. Kind regards, Petr
RE: [PATCH V2 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
From: lantianyu1...@gmail.com Sent: Saturday,
February 2, 2019 5:15 AM
I have a couple more comments
>
> +config HYPERV_IOMMU
> + bool "Hyper-V IRQ Remapping Support"
> + depends on HYPERV
> + select IOMMU_API
> + help
> + Hyper-V stub IOMMU driver provides IRQ Remapping capability
> + to run Linux guest with X2APIC mode on Hyper-V.
> +
> +
I'm a little concerned about the terminology here. The comments and
commit messages for these patches all say that Hyper-V guests don't
have interrupt remapping support. And we don't really *need* interrupt
remapping support because all the interrupts that should be nicely spread
out across all vCPUs (i.e., the MSI interrupts for PCI pass-thru devices) are
handled via a hypercall in pci-hyperv.c, and not via the virtual IOAPIC. So
we have this stub IOMMU driver that doesn't actually do interrupt remapping.
It just prevents assigning the very small number of non-performance sensitive
IOAPIC interrupts to a CPU with an APIC ID above 255.
With that background, describing this feature as "Hyper-V IRQ Remapping
Support" seems incorrect, and similarly in the "help" description. Finding
good terminology for this situation is hard. But how about narrowing the
focus to x2APIC handling:
bool "Hyper-V x2APIC IRQ Handling"
...
help
Stub IOMMU driver to handle IRQs as to allow Hyper-V Linux
guests to run with x2APIC mode enabled
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs,
> + void *arg)
> +{
> + struct irq_alloc_info *info = arg;
> + struct irq_data *irq_data;
> + struct irq_desc *desc;
> + int ret = 0;
> +
> + if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> + return -EINVAL;
> +
> + ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + irq_data = irq_domain_get_irq_data(domain, virq);
> + if (!irq_data) {
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> + return -EINVAL;
> + }
> +
> + irq_data->chip = _ir_chip;
> +
> + /*
> + * IOAPIC entry pointer is saved in chip_data to allow
> + * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
> + * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
> + * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
> + */
> + irq_data->chip_data = info->ioapic_entry;
> +
> + /*
> + * Hypver-V IO APIC irq affinity should be in the scope of
> + * ioapic_max_cpumask because no irq remapping support.
> + */
> + desc = irq_data_to_desc(irq_data);
> + cpumask_and(desc->irq_common_data.affinity,
> + desc->irq_common_data.affinity,
> + _max_cpumask);
The intent of this cpumask_and() call is to ensure that IOAPIC interrupts
are initially assigned to a CPU with APIC ID < 256. But do we know that
the initial value of desc->irq_common_data.affinity is such that the result
of the cpumask_and() will not be the empty set? My impression is that
these local IOAPIC interrupts are assigned an initial affinity mask with all
CPUs set, in which case this will work just fine. But I'm not sure if that
is guaranteed.
An alternative would be to set the affinity to ioapic_max_cpumask and
overwrite whatever might have been previously specified. But I don't know
if that's really better.
> +
> + return 0;
> +}
Re: [PATCHv3 net] sctp: check and update stream->out_curr when allocating stream_out
On Mon, Feb 04, 2019 at 03:27:58AM +0800, Xin Long wrote:
> Now when using stream reconfig to add out streams, stream->out
> will get re-allocated, and all old streams' information will
> be copied to the new ones and the old ones will be freed.
>
> So without stream->out_curr updated, next time when trying to
> send from stream->out_curr stream, a panic would be caused.
>
> This patch is to check and update stream->out_curr when
> allocating stream_out.
>
> v1->v2:
> - define fa_index() to get elem index from stream->out_curr.
> v2->v3:
> - repost with no change.
>
> Fixes: 5e32a431 ("sctp: introduce stream scheduler foundations")
> Reported-by: Ying Xu
> Reported-by: syzbot+e33a3a138267ca119...@syzkaller.appspotmail.com
> Signed-off-by: Xin Long
> ---
> net/sctp/stream.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 80e0ae5..f246331 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -84,6 +84,19 @@ static void fa_zero(struct flex_array *fa, size_t index,
> size_t count)
> }
> }
>
> +static size_t fa_index(struct flex_array *fa, void *elem, size_t count)
> +{
> + size_t index = 0;
> +
> + while (count--) {
> + if (elem == flex_array_get(fa, index))
> + break;
> + index++;
> + }
> +
> + return index;
> +}
> +
> /* Migrates chunks from stream queues to new stream queues if needed,
> * but not across associations. Also, removes those chunks to streams
> * higher than the new max.
> @@ -147,6 +160,13 @@ static int sctp_stream_alloc_out(struct sctp_stream
> *stream, __u16 outcnt,
>
> if (stream->out) {
> fa_copy(out, stream->out, 0, min(outcnt, stream->outcnt));
> + if (stream->out_curr) {
> + size_t index = fa_index(stream->out, stream->out_curr,
> + stream->outcnt);
> +
> + BUG_ON(index == stream->outcnt);
> + stream->out_curr = flex_array_get(out, index);
> + }
> fa_free(stream->out);
> }
>
> --
> 2.1.0
>
>
Acked-by: Neil Horman
Re: [PATCH 3/3] selftests/ima: kexec_file_load syscall test
Hi Mimi,
> The kernel can be configured to verify PE signed kernel images, IMA
> kernel image signatures, both types of signatures, or none. This test
> verifies only properly signed kernel images are loaded into memory,
> based on the kernel configuration and runtime policies.
> Signed-off-by: Mimi Zohar
Reviewed-by: Petr Vorel
...
> +++ b/tools/testing/selftests/ima/test_kexec_file_load.sh
> @@ -0,0 +1,250 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +# Loading a kernel image via the kexec_file_load syscall can verify either
> +# the IMA signature stored in the security.ima xattr or the PE signature,
> +# both signatures depending on the IMA policy, or none.
> +#
> +# To determine whether the kernel image is signed, this test depends
> +# on pesign and getfattr. This test also requires the kernel to be
> +# built with CONFIG_IKCONFIG enabled and either CONFIG_IKCONFIG_PROC
> +# enabled or access to the extract-ikconfig script.
> +
> +VERBOSE=1
Maybe allow to disable verbose without source change?
VERBOSE="${VERBOSE:-1}"
> +EXTRACT_IKCONFIG=$(ls /lib/modules/`uname
> -r`/source/scripts/extract-ikconfig)
> +IKCONFIG=/tmp/config-`uname -r`
> +PROC_CONFIG="/proc/config.gz"
> +KERNEL_IMAGE="/boot/vmlinuz-`uname -r`"
> +PESIGN=/usr/bin/pesign
> +GETFATTR=/usr/bin/getfattr
> +
> +TEST="$0"
> +. ./common_lib.sh
> +
> +# Kselftest framework requirement - SKIP code is 4.
> +ksft_skip=4
> +
> +kconfig_enabled()
> +{
> + RC=0
> + egrep -q $1 $IKCONFIG
> + if [ $? -eq 0 ]; then
> + RC=1
> + fi
> + return $RC
> +}
This would be enough (grep with -e returns only 0 or 1):
kconfig_enabled()
{
grep -E -q $1 $IKCONFIG
}
> +
> +# policy rule format: action func= [appraise_type=]
> +check_ima_policy()
> +{
> + IMA_POLICY=/sys/kernel/security/ima/policy
> +
> + RC=0
> + if [ $# -eq 3 ]; then
> + grep -e $2 $IMA_POLICY | grep -e "^$1.*$3" 2>&1 >/dev/null
> + else
> + grep -e $2 $IMA_POLICY | grep -e "^$1" 2>&1 >/dev/null
> + fi
> + if [ $? -eq 0 ]; then
> + RC=1
> + fi
> + return $RC
> +}
This would be enough and more descriptive:
check_ima_policy()
{
local action="$1"
local keyword="$2"
local type="$3"
[ -n "$type" ] && type="appraise_type=$type"
grep -q "^$action.*func=$keyword.*$type" /sys/kernel/security/ima/policy
}
> +
> +check_kconfig_options()
> +{
> + # Attempt to get the kernel config first via proc, and then by
> + # extracting it from the kernel image using scripts/extract-ikconfig.
> + if [ ! -f $PROC_CONFIG ]; then
> + modprobe configs 2>/dev/null
> + fi
> + if [ -f $PROC_CONFIG ]; then
> + cat $PROC_CONFIG > $IKCONFIG
> + fi
> +
> + if [ ! -f $IKCONFIG ]; then
> + if [ ! -f $EXTRACT_IKCONFIG ]; then
> + echo "$TEST: requires access to extract-ikconfig" >&2
> + exit $ksft_skip
> + fi
> +
> + $EXTRACT_IKCONFIG $KERNEL_IMAGE > $IKCONFIG
> + kconfig_enabled "CONFIG_IKCONFIG=y"
> + if [ $? -eq 0 ]; then
> + echo "$TEST: requires the kernel to be built with
> CONFIG_IKCONFIG" >&2
> + exit $ksft_skip
> + fi
> + fi
> +
> + kconfig_enabled "CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y"
> + pe_sig_required=$?
> + if [ $VERBOSE -ne 0 ] && [ $pe_sig_required -eq 1 ]; then
> + echo "$TEST: [INFO] PE signed kernel image required"
> + fi
Checks for $VERBOSE here and in other kconfig_enabled usages bellow are a bit
redundant. And you check for assigned variable now and then later on,
you use these variables as global (and reset $ima_sig_required in
check_runtime().
How about using functions instead:
log_info()
{
echo "$TEST: [INFO] $1"
}
(Reducing some duplicity, IMHO helper functions in shell library used in all
selftest tests would be useful)
kconfig_enabled()
{
local config="$1"
local msg="$2"
local ret
grep -E -q $config $IKCONFIG
ret=$?
[ $VERBOSE -ne 0 ] && [ $ret -eq 1 ] && log_info "$msg"
return $ret
}
ima_sig_enabled()
{
kconfig_enabled "CONFIG_KEXEC_BZIMAGE_VERIFY_SIG=y" \
"PE signed kernel image required"
}
ima_sig_enabled()
{
kconfig_enabled "CONFIG_IMA_APPRAISE_REQUIRE_KEXEC_SIGS=y" \
"IMA kernel image signature required"
}
Warning is printed each time, but that's deliberate.
If it's not wanted, it can be moved into setup.
...
> +check_kconfig_options
> +check_for_apps
> +check_runtime
> +check_for_sigs
> +kexec_file_load_test
> +rc=$?
> +exit $rc
These two are redundant.
Kind regards,
Petr
Linux 5.0-rc5
I'm happy to report that things seem to be calming down nicely, and
rc5 is noticeably smaller than previous rc's. Let's hope the trend
continues.
About a third of the changes are to drivers (networking, rdma, scsi,
block, misc), with the rest being spread out all over (tooling,
networking, filesystems, arch updates, core kernel..)
Nothing looks particularly worrisome, so assuming the trend holds, we
look to be on track for a fairly normal release cycle despite the
early hiccups due to the holidays.
Go out there and test in between the commercial breaks,
Linus
---
Abel Vesa (1):
clk: imx: Fix fractional clock set rate computation
Al Viro (1):
btrfs: fix potential oops in device_list_add
Alexandre Ghiti (1):
riscv: Adjust mmap base address at a third of task size
Alexei Naberezhnov (1):
md/raid5: fix 'out of memory' during raid cache recovery
Alexey Dobriyan (1):
proc: fix /proc/net/* after setns(2)
Alexey Khoroshilov (1):
net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
Alistair Francis (1):
RISC-V: defconfig: Enable Generic PCIE by default
Anders Roxell (2):
netfilter: ipt_CLUSTERIP: fix warning unused variable cn
kasan: mark file common so ftrace doesn't trace it
Andi Kleen (1):
perf script: Fix crash with printing mixed trace point and other events
Andrea Arcangeli (1):
mm/hugetlb.c: teach follow_hugetlb_page() to handle FOLL_NOWAIT
Andreas Gruenbacher (1):
gfs2: Revert "Fix loop in gfs2_rbm_find"
Andreas Schwab (2):
RISC-V: fix bad use of of_node_put
tty/serial: use uart_console_write in the RISC-V SBL early console
Andrei Vagin (1):
kernel/exit.c: release ptraced tasks before zap_pid_ns_processes
Andrew Lunn (2):
net: dsa: mv88e6xxx: Fix serdes irq setup going recursive
gpio: vf610: Mask all GPIO interrupts
Antony Pavlov (2):
RISC-V: asm/page.h: fix spelling mistake "CONFIG_64BITS" -> "CONFIG_64BIT"
RISC-V: Kconfig: fix spelling mistake "traget" -> "target"
Ard Biesheuvel (1):
arm64: kaslr: ensure randomized quantities are clean also when
kaslr is off
Arnaldo Carvalho de Melo (1):
perf python: Remove -fstack-clash-protection when building with
some clang versions
Artemy Kovalyov (1):
RDMA/umem: Add missing initialization of owning_mm
Aurelien Aptel (1):
CIFS: fix use-after-free of the lease keys
Axel Lin (1):
gpio: altera-a10sr: Set proper output level for direction_output
Aya Levin (1):
net/mlx5e: Allow MAC invalidation while spoofchk is ON
Bartosz Golaszewski (1):
gpiolib: fix line event timestamps for nested irqs
Baruch Siach (1):
Revert "PCI: armada8k: Add support for gpio controlled reset signal"
Benedict Wong (1):
xfrm: Make set-mark default behavior backward compatible
Bernard Pidoux (1):
net/rose: fix NULL ax25_cb kernel panic
Bodong Wang (1):
Revert "net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager"
Borislav Petkov (1):
MAINTAINERS: Add Andy and Darren as arch/x86/platform/ reviewers
Brian Welty (1):
IB/{hfi1, qib}: Fix WC.byte_len calculation for UD_SEND_WITH_IMM
Catalin Marinas (1):
arm64: Do not issue IPIs for user executable ptes
Chaotian Jing (1):
mmc: mediatek: fix incorrect register setting of hs400_cmd_int_delay
Christoph Hellwig (1):
iomap: fix a use after free in iomap_dio_rw
Colin Ian King (2):
selftests: cpu-hotplug: fix case where CPUs offline > CPUs present
x86/fault: Fix sign-extend unintended sign extension
Cong Wang (1):
netrom: switch to sock timer API
Corentin Labbe (2):
xtensa: Fix typo use space=>user space
xtensa: rename BUILTIN_DTB to BUILTIN_DTB_SOURCE
Dan Carpenter (4):
clk: ti: Fix error handling in ti_clk_parse_divider_data()
scsi: bnx2fc: Fix error handling in probe()
scsi: 53c700: pass correct "dev" to dma_alloc_attrs()
lib/test_kmod.c: potential double free in error handling
Dave Watson (2):
net: tls: Save iv in tls_rec for async crypto requests
net: tls: Fix deadlock in free_resources tx
David Hildenbrand (1):
mm: migrate: don't rely on __PageMovable() of newpage after unlocking it
David Sterba (1):
btrfs: clean up pending block groups when transaction commit aborts
Derek Basehore (1):
clk: Remove global clk traversal on fetch parent index
Doug Smythies (1):
cpuidle: poll_state: Fix default time limit
Douglas Gilbert (1):
scsi: scsi_debug: fix write_same with virtual_gb problem
Eric W. Biederman (1):
btrfs: On error always free subvol_name in btrfs_mount
Fathi Boudra (2):
selftests: net: use LDLIBS instead of LDFLAGS
selftests: timers: use LDLIBS instead of LDFLAGS
Feras Daoud (1):
IB/ipoib: Fix for use-after-free in ipoib_cm_tx_start
Fernando Fernandez Mancera (1):
netfilter: nfnetlink_osf: add missing fmatch check
Filipe Manana (1):
Re: [PATCH] media: videobuf2: Return error after allocation failure
Le dimanche 03 février 2019 à 19:06 +0530, Souptick Joarder a écrit :
> There is no point to continuing assignemnt after memory allocation
assignemnt -> assignment.
> failed, rather throw error immediately.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/media/common/videobuf2/videobuf2-vmalloc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 6dfbd5b..d3f71e2 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -46,16 +46,16 @@ static void *vb2_vmalloc_alloc(struct device *dev,
> unsigned long attrs,
>
> buf->size = size;
> buf->vaddr = vmalloc_user(buf->size);
> - buf->dma_dir = dma_dir;
> - buf->handler.refcount = >refcount;
> - buf->handler.put = vb2_vmalloc_put;
> - buf->handler.arg = buf;
>
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
> kfree(buf);
> return ERR_PTR(-ENOMEM);
> }
> + buf->dma_dir = dma_dir;
> + buf->handler.refcount = >refcount;
> + buf->handler.put = vb2_vmalloc_put;
> + buf->handler.arg = buf;
>
> refcount_set(>refcount, 1);
> return buf;
RE: [PATCH V2 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
From: lantianyu1...@gmail.com Sent: Saturday,
February 2, 2019 5:15 AM
>
> +/*
> + * According 82093AA IO-APIC spec , IO APIC has a 24-entry Interrupt
> + * Redirection Table.
> + */
> +#define IOAPIC_REMAPPING_ENTRY 24
The other unstated assumption here is that Hyper-v guest VMs
have only a single IOAPIC, regardless of the size of the VM.
Perhaps that should be stated in the comment explaining why
there are 24 entries?
> +
> +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> +static struct irq_domain *ioapic_ir_domain;
> +
> +static int hyperv_ir_set_affinity(struct irq_data *data,
> + const struct cpumask *mask, bool force)
> +{
> + struct irq_data *parent = data->parent_data;
> + struct irq_cfg *cfg = irqd_cfg(data);
> + struct IO_APIC_route_entry *entry;
> + cpumask_t cpumask;
> + int ret;
> +
> + cpumask_andnot(, mask, _max_cpumask);
> +
> + /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> + if (!cpumask_empty())
> + return -EINVAL;
The above two cpumask functions can be combined in a single
call to cpumask_subset(). This has the nice property that determining
whether the cpus in "mask" are a subset of the cpus in "ioapic_max_cpumask"
is exactly what this code is trying to do. :-) And it gets rid of the local
cpumask variable and the associated compiler warnings about stack frame
size.
> +
> + ret = parent->chip->irq_set_affinity(parent, mask, force);
> + if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> + return ret;
> +
> + entry = data->chip_data;
> + entry->dest = cfg->dest_apicid;
> + entry->vector = cfg->vector;
> + send_cleanup_vector(cfg);
> +
> + return 0;
> +}
> +
> +static struct irq_chip hyperv_ir_chip = {
> + .name = "HYPERV-IR",
> + .irq_ack= apic_ack_irq,
> + .irq_set_affinity = hyperv_ir_set_affinity,
> +};
> +
> +static int hyperv_irq_remapping_alloc(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs,
> + void *arg)
> +{
> + struct irq_alloc_info *info = arg;
> + struct irq_data *irq_data;
> + struct irq_desc *desc;
> + int ret = 0;
> +
> + if (!info || info->type != X86_IRQ_ALLOC_TYPE_IOAPIC || nr_irqs > 1)
> + return -EINVAL;
> +
> + ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
> + if (ret < 0)
> + return ret;
> +
> + irq_data = irq_domain_get_irq_data(domain, virq);
> + if (!irq_data) {
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> + return -EINVAL;
> + }
> +
> + irq_data->chip = _ir_chip;
> +
> + /*
> + * IOAPIC entry pointer is saved in chip_data to allow
> + * hyperv_irq_remappng_activate()/hyperv_ir_set_affinity() to set
> + * vector and dest_apicid. cfg->vector and cfg->dest_apicid are
> + * ignorred when IRQ remapping is enabled. See ioapic_configure_entry().
Spelling: "ignored".
I saw Vitaly previous comments, and I still don't understand this comment. :-(
Is IRQ remapping considered to be enabled by this IOMMU driver, such that
cfg->vector and cfg->dest_apicid are ignored? Or is the "when IRQ remapping
is enabled" a statement about some future enhancement?
> + */
> + irq_data->chip_data = info->ioapic_entry;
> +
> + /*
> + * Hypver-V IO APIC irq affinity should be in the scope of
> + * ioapic_max_cpumask because no irq remapping support.
> + */
> + desc = irq_data_to_desc(irq_data);
> + cpumask_and(desc->irq_common_data.affinity,
> + desc->irq_common_data.affinity,
> + _max_cpumask);
> +
> + return 0;
> +}
> +
> +static void hyperv_irq_remapping_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + irq_domain_free_irqs_common(domain, virq, nr_irqs);
> +}
> +
> +static int hyperv_irq_remappng_activate(struct irq_domain *domain,
> + struct irq_data *irq_data, bool reserve)
> +{
> + struct irq_cfg *cfg = irqd_cfg(irq_data);
> + struct IO_APIC_route_entry *entry = irq_data->chip_data;
> +
> + entry->dest = cfg->dest_apicid;
> + entry->vector = cfg->vector;
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops hyperv_ir_domain_ops = {
> + .alloc = hyperv_irq_remapping_alloc,
> + .free = hyperv_irq_remapping_free,
> + .activate = hyperv_irq_remappng_activate,
> +};
> +
> +static int __init hyperv_prepare_irq_remapping(void)
> +{
> + struct fwnode_handle *fn;
> + u32 apic_id;
> + int i;
> +
> + if (x86_hyper_type != X86_HYPER_MS_HYPERV ||
The function hypervisor_is_type() exists for doing the above test.
See include/asm/hypervisor.h
> + !x2apic_supported())
> + return -ENODEV;
> +
> + fn =
Re: [PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak
On Sun, Feb 03, 2019 at 08:05:53PM +0100, Jiri Kosina wrote: > On Sun, 3 Feb 2019, Ben Hutchings wrote: > > > 3.16.63-rc1 review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Jiri Kosina > > > > commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream. > > You really want the whole IBPB+STIBP revamp from upstream, otherwise > you're going to get noticeable performance penalties on some workloads > with some microcodes. Yes, we would need the opt-in/opt-out support too. Please don't merge it just as is. -Andi
RE: [PATCH V2 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available
From: lantianyu1...@gmail.com Sent: Saturday, February 2, 2019 5:15 AM > > Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, > set x2apic destination mode to physcial mode when x2apic is available > and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have > 8-bit APIC id. > > Signed-off-by: Lan Tianyu > --- > Change since v1: >- Remove redundant extern for x2apic_phys > --- > arch/x86/kernel/cpu/mshyperv.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > index e81a2db..4bd6d90 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -328,6 +328,16 @@ static void __init ms_hyperv_init_platform(void) > # ifdef CONFIG_SMP > smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu; > # endif > + > +/* > + * Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic, > + * set x2apic destination mode to physcial mode when x2apic is available > + * and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs > + * have 8-bit APIC id. > + */ Per comment from Dan Carpenter on v1 of this patch, the above comment block should be indented one tab to line up with the "if" statement below. Michael > + if (IS_ENABLED(CONFIG_HYPERV_IOMMU) && x2apic_supported()) > + x2apic_phys = 1; > + > #endif > } > > -- > 2.7.4
Re: [PATCH 2/3] scripts/ima: define a set of common functions
Hi Mimi,
> Define and move get_secureboot_mode() to a common file for use by other
> tests.
> Signed-off-by: Mimi Zohar
Reviewed-by: Petr Vorel
> ---
> tools/testing/selftests/ima/common_lib.sh | 20
> tools/testing/selftests/ima/test_kexec_load.sh | 17 +++--
> 2 files changed, 23 insertions(+), 14 deletions(-)
> create mode 100755 tools/testing/selftests/ima/common_lib.sh
> diff --git a/tools/testing/selftests/ima/common_lib.sh
> b/tools/testing/selftests/ima/common_lib.sh
> new file mode 100755
> index ..ae097a634da5
> --- /dev/null
> +++ b/tools/testing/selftests/ima/common_lib.sh
> @@ -0,0 +1,20 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
# SPDX-License-Identifier: GPL-2.0-or-later
> +
> +get_secureboot_mode()
> +{
> + EFIVARFS="/sys/firmware/efi/efivars"
local efivarfs="/sys/firmware/efi/efivars"
local file
It's a good practise to use local keyword and lower case the name of the
variable for variables used only locally (if you treat $EFIVARFS as constant,
I'd move it outside of get_secureboot_mode()).
I personally try to avoid using global variables (except constant like).
> + # Make sure that efivars is mounted in the normal location
> + if ! grep -q "^\S\+ $EFIVARFS efivarfs" /proc/mounts; then
> + echo "$TEST: efivars is not mounted on $EFIVARFS" >&2
> + exit $ksft_skip
> + fi
There could be helper function printing error and exit in selftest library.
> + # Get secureboot mode
> + file="$EFIVARFS/SecureBoot-*"
file="$efivarfs/SecureBoot-*"
...
> KERNEL_IMAGE="/boot/vmlinuz-`uname -r`"
Another candidate for helper for potential selftest library.
Kind regards,
Petr
Re: [PATCH 1/2] drm/vkms: Bugfix extra vblank frame
On 01/30, Shayenne Moura wrote: > kms_flip tests are breaking on vkms when simulate vblank because vblank > event sequence count returns one extra frame after arm vblank event to > make a page flip. > > When vblank interrupt happens, userspace processes the vblank event and > issues the next page flip command. Kernel calls queue_work to call > commit_planes and arm the new page flip. The next vblank picks up the > newly armed vblank event and vblank interrupt happens again. > > The arm and vblank event are asynchronous, then, on the next vblank, we > receive x+2 from `get_vblank_timestamp`, instead x+1, although timestamp > and vblank seqno matches. > > Function `get_vblank_timestamp` is reached by 2 ways: > > - from `drm_mode_page_flip_ioctl`: driver is doing one atomic operation > to synchronize planes in the same output. There is no vblank simulation, > the `drm_crtc_arm_vblank_event` function adds 1 on vblank count, and the > variable in_vblank_irq is false > - from `vkms_vblank_simulate`: since the driver is doing a vblank > simulation, > the variable in_vblank_irq is true. > > Fix this problem subtracting one vblank period from vblank_time when > `get_vblank_timestamp` is called from trace `drm_mode_page_flip_ioctl`, > i.e., is not a real vblank interrupt, and getting the timestamp and vblank > seqno when it is a real vblank interrupt. > > The reason for all this is that get_vblank_timestamp always supplies the > timestamp for the next vblank event. The hrtimer is the vblank simulator, > and it needs the correct previous value to present the next vblank. Since > this is how hw timestamp registers work and what the vblank core expects. > > Signed-off-by: Shayenne Moura > Signed-off-by: Daniel Vetter > > --- > drivers/gpu/drm/vkms/vkms_crtc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c > b/drivers/gpu/drm/vkms/vkms_crtc.c > index d44bfc392491..23146ff2a25b 100644 > --- a/drivers/gpu/drm/vkms/vkms_crtc.c > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c > @@ -87,6 +87,9 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev, > unsigned int pipe, > > *vblank_time = output->vblank_hrtimer.node.expires; > > + if (!in_vblank_irq) > + *vblank_time -= output->period_ns; > + > return true; > } > > -- > 2.17.1 > Reviewed-by: Rodrigo Siqueira -- Rodrigo Siqueira https://siqueira.tech Graduate Student Department of Computer Science University of São Paulo signature.asc Description: PGP signature
Re: [PATCH 2/2] drm: vkms: Bugfix racing hrtimer vblank handle
On 01/30, Shayenne Moura wrote:
> When the vblank irq happens, kernel time subsystem executes
> `vkms_vblank_simulate`. In parallel or not, it prepares all stuff
> necessary to the next vblank with arm, and it must flush these
> stuff before the next vblank irq. However, vblank counter is ahead
> when arm is executed in parallel with handle vblank.
>
> CPU 0:CPU 1:
> | |
> atomic_commit_tail is ongoing |
> | |
> |hrtimer: vkms_vblank_simulate()
> | |
> |drm_crtc_handle_vblank()
> | |
> drm_crtc_arm_vblank() |
> | |
> ->get_vblank_timestamp() |
> | |
> |hrtimer_forward_now()
>
> Then, we should guarantee that the vblank interval time is correct
> (not changed) before finish the vblank handle.
>
> Fix the bug including the call to `hrtimer_forward_now()` in the same
> lock of `drm_crtc_handle_vblank()` to ensure that the timestamp update
> is correct when finish the vblank handle.
>
> Signed-off-by: Shayenne Moura
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 23146ff2a25b..5a095610726b 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -10,13 +10,17 @@
> #include
> #include
>
> -static void _vblank_handle(struct vkms_output *output)
> +static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> {
> + struct vkms_output *output = container_of(timer, struct vkms_output,
> + vblank_hrtimer);
> struct drm_crtc *crtc = >crtc;
> struct vkms_crtc_state *state = to_vkms_crtc_state(crtc->state);
> + int ret_overrun;
> bool ret;
>
> spin_lock(>lock);
> +
> ret = drm_crtc_handle_vblank(crtc);
> if (!ret)
> DRM_ERROR("vkms failure on handling vblank");
> @@ -37,19 +41,9 @@ static void _vblank_handle(struct vkms_output *output)
> DRM_WARN("failed to queue vkms_crc_work_handle");
> }
>
> - spin_unlock(>lock);
> -}
> -
> -static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer)
> -{
> - struct vkms_output *output = container_of(timer, struct vkms_output,
> - vblank_hrtimer);
> - int ret_overrun;
> -
> - _vblank_handle(output);
> -
> ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> output->period_ns);
> + spin_unlock(>lock);
>
> return HRTIMER_RESTART;
> }
> --
> 2.17.1
>
Reviewed-by: Rodrigo Siqueira
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
Re: [PATCH 0/2] drm/vkms: Bugfix for igt-tests
On 01/30, Shayenne Moura wrote: > This patchset contains patches to fix the extra frame bug on kms_flip > igt-test. First patch solves the extra vblank frame that breaks many > tests on kms_flip and second patch solves the race condition caused > by the solution added in the first one. > > Shayenne Moura (2): > drm/vkms: Bugfix extra vblank frame > drm/vkms: Bugfix racing hrtimer vblank handle > > drivers/gpu/drm/vkms/vkms_crtc.c | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) > > -- > 2.17.1 > Hi, Thanks for the patchset :) The patchset worked like a charm; it fixes many of the tests in the kms_flip. \o/ I'll apply it. Thanks! Reviewed-by: Rodrigo Siqueira -- Rodrigo Siqueira https://siqueira.tech Graduate Student Department of Computer Science University of São Paulo signature.asc Description: PGP signature
Re: [PATCH 1/3] selftest/ima: cleanup the kexec selftest
Hi Mimi, > Remove the few bashisms in the script and use the complete option name > for clarity. > Signed-off-by: Mimi Zohar Reviewed-by: Petr Vorel > --- > tools/testing/selftests/ima/test_kexec_load.sh | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > diff --git a/tools/testing/selftests/ima/test_kexec_load.sh > b/tools/testing/selftests/ima/test_kexec_load.sh > index 1c10093fb526..74423c4229e2 100755 > --- a/tools/testing/selftests/ima/test_kexec_load.sh > +++ b/tools/testing/selftests/ima/test_kexec_load.sh > @@ -1,7 +1,7 @@ > #!/bin/sh > # SPDX-License-Identifier: GPL-2.0+ # SPDX-License-Identifier: GPL-2.0-or-later According to [1] GPL-2.0+ has been deprecated (but who cares). ... > - if [ "$secureboot" == "1" ]; then > +kexec --load $KERNEL_IMAGE 2>&1 /dev/null kexec --load $KERNEL_IMAGE 2>&1 >/dev/null missing redirection. > +if [ $? -eq 0 ]; then > + kexec --unload > + if [ $secureboot -eq 1 ]; then > echo "$TEST: kexec_load succeeded [FAIL]" > rc=1 > else > echo "$TEST: kexec_load succeeded [PASS]" > fi It'd be nice, if selftest has some main library with helpers (like LTP has [2]), to have unified output and reduce duplicity. Kind regards, Petr [1] https://spdx.org/licenses/ [2] https://github.com/linux-test-project/ltp/blob/master/testcases/lib/tst_test.sh
Re: [PATCH v2 00/15] Habana Labs kernel driver
On Sun, Feb 3, 2019 at 1:50 PM Mike Rapoport wrote: > > Hi Oded, > > On Thu, Jan 31, 2019 at 12:06:02AM +0200, Oded Gabbay wrote: > > Hello, > > This is v2 of the Habana Labs kernel driver patch-set. It contains fixes > > for almost everything that was brought up in the review of v1. > > > > In addition to local changes in each patch that are detailed in each > > patch's commit message, the global/major changes are: > > > > - Rebased on v5.0-rc4 > > - Removed all bitfields from interface files to H/W and F/W > > - Use __le16/32/64 instead of __u16/32/64 in F/W or H/W structures > > For v2 I had comments only for "[PATCH v2 07/15] habanalabs: add h/w queues > module". > > There are still several over-exited printk calls with three exclamation > marks. ;-) > > I've also spotted several places where checkpatch.pl may complain, but I > was to lazy to actually check it. > > > Link to v1 cover letter: https://lwn.net/Articles/777342/ > > > > I would appricate any feedback, question and/or review. > > > > Thanks, > > Oded > > > > p.s. for those who prefer to clone the tree instead of looking at the > > emails, you can grab a copy from our company's page in GitHub: > > > > https://github.com/HabanaAI/linux/releases/tag/hl_patchset_v2_20190130 > > > > Oded Gabbay (14): > > habanalabs: add skeleton driver > > habanalabs: add Goya registers header files > > This one is 4.3M which is 6 times the entire habanalabs driver without > those headers. > Any chance some of it can be dropped? Hi Mike, Managed to remove about 30 files (~1.5MB) from this patch. The patch now is around 2.9MB Unfortunately, I don't see how I can reduce it much more without seriously reducing the readability and maintainability of the driver. Oded > > > habanalabs: add basic Goya support > > habanalabs: add context and ASID modules > > habanalabs: add command buffer module > > habanalabs: add basic Goya h/w initialization > > habanalabs: add h/w queues module > > habanalabs: add event queue and interrupts > > habanalabs: add sysfs and hwmon support > > habanalabs: add device reset support > > habanalabs: add command submission module > > habanalabs: implement INFO IOCTL > > habanalabs: add debugfs support > > Update MAINTAINERS and CREDITS with habanalabs info > > > > Omer Shpigelman (1): > > habanalabs: add virtual memory and MMU modules > > > > CREDITS |2 +- > > .../ABI/testing/debugfs-driver-habanalabs | 127 + > > .../ABI/testing/sysfs-driver-habanalabs | 190 + > > MAINTAINERS |9 + > > drivers/misc/Kconfig |1 + > > drivers/misc/Makefile |1 + > > drivers/misc/habanalabs/Kconfig | 22 + > > drivers/misc/habanalabs/Makefile | 15 + > > drivers/misc/habanalabs/asid.c| 58 + > > drivers/misc/habanalabs/command_buffer.c | 432 + > > drivers/misc/habanalabs/command_submission.c | 787 ++ > > drivers/misc/habanalabs/context.c | 216 + > > drivers/misc/habanalabs/debugfs.c | 1071 ++ > > drivers/misc/habanalabs/device.c | 1110 ++ > > drivers/misc/habanalabs/goya/Makefile |4 + > > drivers/misc/habanalabs/goya/goya.c | 5338 ++ > > drivers/misc/habanalabs/goya/goyaP.h | 193 + > > drivers/misc/habanalabs/goya/goya_hwmgr.c | 306 + > > drivers/misc/habanalabs/goya/goya_security.c | 2999 ++ > > drivers/misc/habanalabs/habanalabs.h | 1448 +++ > > drivers/misc/habanalabs/habanalabs_drv.c | 469 + > > drivers/misc/habanalabs/habanalabs_ioctl.c| 234 + > > drivers/misc/habanalabs/hw_queue.c| 654 ++ > > drivers/misc/habanalabs/hwmon.c | 449 + > > drivers/misc/habanalabs/include/armcp_if.h| 335 + > > .../include/goya/asic_reg/cpu_ca53_cfg_regs.h | 213 + > > .../include/goya/asic_reg/cpu_if_regs.h | 110 + > > .../include/goya/asic_reg/cpu_pll_regs.h | 186 + > > .../include/goya/asic_reg/ddr_mc_ch0_regs.h | 1158 +++ > > .../include/goya/asic_reg/ddr_mc_ch1_regs.h | 1158 +++ > > .../include/goya/asic_reg/ddr_misc_ch0_regs.h | 156 + > > .../include/goya/asic_reg/ddr_misc_ch1_regs.h | 156 + > > .../include/goya/asic_reg/dma_ch_0_regs.h | 512 + > > .../include/goya/asic_reg/dma_ch_1_regs.h | 512 + > > .../include/goya/asic_reg/dma_ch_2_regs.h | 512 + > > .../include/goya/asic_reg/dma_ch_3_regs.h | 512 + > > .../include/goya/asic_reg/dma_ch_4_regs.h | 512 + > > .../include/goya/asic_reg/dma_macro_regs.h| 242 + > > .../include/goya/asic_reg/dma_nrtr_regs.h | 380 + > > .../include/goya/asic_reg/dma_qm_0_regs.h | 543 + > > .../include/goya/asic_reg/dma_qm_1_regs.h | 543 + > > .../include/goya/asic_reg/dma_qm_2_regs.h | 543 + > > .../include/goya/asic_reg/dma_qm_3_regs.h | 543 + > >
[PATCH] ARM: dts: exynos: Fix spelling mistake of EXYNOS5420
The SoC name EXYNOS5420 was misspelled. Signed-off-by: Benjamin Drung --- arch/arm/boot/dts/exynos5420.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi index aaff15880761..5fb2326875dc 100644 --- a/arch/arm/boot/dts/exynos5420.dtsi +++ b/arch/arm/boot/dts/exynos5420.dtsi @@ -5,7 +5,7 @@ * Copyright (c) 2013 Samsung Electronics Co., Ltd. * http://www.samsung.com * - * SAMSUNG EXYNOS54200 SoC device nodes are listed in this file. + * SAMSUNG EXYNOS5420 SoC device nodes are listed in this file. * EXYNOS5420 based board files can include this file and provide * values for board specfic bindings. */ -- 2.19.1
[PATCH 1/1] doc: kernel-parameters.txt: fix documentation of elevator parameter
Legacy IO schedulers (cfq, deadline and noop) were removed in
f382fb0bcef4.
The documentation for deadline was retained because it carries over to
mq-deadline as well, but location of the doc file was changed over time.
The old iosched algorithms were removed from elevator= kernel parameter
and mq-deadline, kyber and bfq were added with a reference to their
documentation.
Fixes: f382fb0bcef4 ("block: remove legacy IO schedulers")
Signed-off-by: Otto Sabart
---
Documentation/admin-guide/kernel-parameters.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index b799bcf67d7b..2238fb3c7dcf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1182,9 +1182,10 @@
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elevator= [IOSCHED]
- Format: {"cfq" | "deadline" | "noop"}
- See Documentation/block/cfq-iosched.txt and
- Documentation/block/deadline-iosched.txt for details.
+ Format: { "mq-deadline" | "kyber" | "bfq" }
+ See Documentation/block/deadline-iosched.txt,
+ Documentation/block/kyber-iosched.txt and
+ Documentation/block/bfq-iosched.txt for details.
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
Specifies physical address of start of kernel core
--
2.17.2
signature.asc
Description: PGP signature
[PATCH 1/3] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
coefficients, so rename them to indicate that. And add some comments
to make clear these are BT.601 coefficients encoding between YUV limited
range and RGB full range. No functional changes.
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 594c3cbc8291..35ae86ff0585 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -183,11 +183,13 @@ struct ic_csc_params {
};
/*
+ * BT.601 encoding from RGB full range to YUV limited range:
+ *
* Y = R * .299 + G * .587 + B * .114;
* U = R * -.169 + G * -.332 + B * .500 + 128.;
* V = R * .500 + G * -.419 + B * -.0813 + 128.;
*/
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 = {
.coeff = {
{ 77, 150, 29 },
{ 469, 427, 128 },
@@ -208,11 +210,13 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
};
/*
+ * Inverse BT.601 encoding from YUV limited range to RGB full range:
+ *
* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
* G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
* B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
*/
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601 = {
.coeff = {
{ 149, 0, 204 },
{ 149, 462, 408 },
@@ -238,9 +242,9 @@ static int init_csc(struct ipu_ic *ic,
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb;
+ params = _csc_ycbcr2rgb_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr;
+ params = _csc_rgb2ycbcr_bt601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
params = _csc_rgb2rgb;
else {
--
2.17.1
[PATCH 2/3] gpu: ipu-v3: ipu-ic: Add support for BT.709 encoding
Pass v4l2 encoding enum to the ipu_ic task init functions, and add
support for the BT.709 encoding and inverse encoding matrices.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
drivers/gpu/ipu-v3/ipu-ic.c | 67 ++---
drivers/gpu/ipu-v3/ipu-image-convert.c | 1 +
drivers/staging/media/imx/imx-ic-prpencvf.c | 4 +-
include/video/imx-ipu-v3.h | 5 +-
4 files changed, 67 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 35ae86ff0585..63362b4fff81 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -199,6 +199,23 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 =
{
.scale = 1,
};
+/*
+ * BT.709 encoding from RGB full range to YUV limited range:
+ *
+ * Y = R * .2126 + G * .7152 + B * .0722;
+ * U = R * -.1146 + G * -.3854 + B * .5000 + 128.;
+ * V = R * .5000 + G * -.4542 + B * -.0458 + 128.;
+ */
+static const struct ic_csc_params ic_csc_rgb2ycbcr_bt709 = {
+ .coeff = {
+ { 54, 183, 18 },
+ { 483, 413, 128 },
+ { 128, 396, 500 },
+ },
+ .offset = { 0, 512, 512 },
+ .scale = 1,
+};
+
/* transparent RGB->RGB matrix for graphics combining */
static const struct ic_csc_params ic_csc_rgb2rgb = {
.coeff = {
@@ -226,12 +243,31 @@ static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601
= {
.scale = 2,
};
+/*
+ * Inverse BT.709 encoding from YUV limited range to RGB full range:
+ *
+ * R = (1. * (Y - 16)) + (1.5748 * (Cr - 128));
+ * G = (1. * (Y - 16)) - (0.1873 * (Cb - 128)) - (0.4681 * (Cr - 128));
+ * B = (1. * (Y - 16)) + (1.8556 * (Cb - 128);
+ */
+static const struct ic_csc_params ic_csc_ycbcr2rgb_bt709 = {
+ .coeff = {
+ { 128, 0, 202 },
+ { 128, 488, 452 },
+ { 128, 238, 0 },
+ },
+ .offset = { -435, 136, -507 },
+ .scale = 2,
+};
+
static int init_csc(struct ipu_ic *ic,
enum ipu_color_space inf,
enum ipu_color_space outf,
+ enum v4l2_ycbcr_encoding encoding,
int csc_index)
{
struct ipu_ic_priv *priv = ic->priv;
+ const struct ic_csc_params *params_rgb2yuv, *params_yuv2rgb;
const struct ic_csc_params *params;
u32 __iomem *base;
const u16 (*c)[3];
@@ -241,10 +277,24 @@ static int init_csc(struct ipu_ic *ic,
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
+ switch (encoding) {
+ case V4L2_YCBCR_ENC_601:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt601;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt601;
+ break;
+ case V4L2_YCBCR_ENC_709:
+ params_rgb2yuv = _csc_rgb2ycbcr_bt709;
+ params_yuv2rgb = _csc_ycbcr2rgb_bt709;
+ break;
+ default:
+ dev_err(priv->ipu->dev, "Unsupported YCbCr encoding\n");
+ return -EINVAL;
+ }
+
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
- params = _csc_ycbcr2rgb_bt601;
+ params = params_yuv2rgb;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
- params = _csc_rgb2ycbcr_bt601;
+ params = params_rgb2yuv;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
params = _csc_rgb2rgb;
else {
@@ -391,6 +441,7 @@ EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
int ipu_ic_task_graphics_init(struct ipu_ic *ic,
enum ipu_color_space in_g_cs,
+ enum v4l2_ycbcr_encoding encoding,
bool galpha_en, u32 galpha,
bool colorkey_en, u32 colorkey)
{
@@ -409,7 +460,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
if (!(ic_conf & ic->bit->ic_conf_csc1_en)) {
/* need transparent CSC1 conversion */
ret = init_csc(ic, IPUV3_COLORSPACE_RGB,
- IPUV3_COLORSPACE_RGB, 0);
+ IPUV3_COLORSPACE_RGB, encoding, 0);
if (ret)
goto unlock;
}
@@ -417,7 +468,7 @@ int ipu_ic_task_graphics_init(struct ipu_ic *ic,
ic->g_in_cs = in_g_cs;
if (ic->g_in_cs != ic->out_cs) {
- ret = init_csc(ic, ic->g_in_cs, ic->out_cs, 1);
+ ret = init_csc(ic, ic->g_in_cs, ic->out_cs, encoding, 1);
if (ret)
goto unlock;
}
@@ -451,6 +502,7 @@ int ipu_ic_task_init_rsc(struct ipu_ic *ic,
int out_width, int out_height,
enum ipu_color_space in_cs,
enum ipu_color_space out_cs,
+enum v4l2_ycbcr_encoding encoding,
[PATCH 3/3] media: imx: Allow BT.709 encoding for IC routes
The IC now supports BT.709 Y'CbCr encoding, in addition to existing BT.601 encoding, so allow both, for pipelines that route through the IC. Reported-by: Tim Harvey Signed-off-by: Steve Longerbeam --- drivers/staging/media/imx/imx-media-utils.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/imx/imx-media-utils.c b/drivers/staging/media/imx/imx-media-utils.c index 5f110d90a4ef..3512f09fb226 100644 --- a/drivers/staging/media/imx/imx-media-utils.c +++ b/drivers/staging/media/imx/imx-media-utils.c @@ -571,7 +571,9 @@ void imx_media_fill_default_mbus_fields(struct v4l2_mbus_framefmt *tryfmt, tryfmt->quantization = is_rgb ? V4L2_QUANTIZATION_FULL_RANGE : V4L2_QUANTIZATION_LIM_RANGE; - tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_601; + if (tryfmt->ycbcr_enc != V4L2_YCBCR_ENC_601 && + tryfmt->ycbcr_enc != V4L2_YCBCR_ENC_709) + tryfmt->ycbcr_enc = V4L2_YCBCR_ENC_601; } } EXPORT_SYMBOL_GPL(imx_media_fill_default_mbus_fields); -- 2.17.1
[PATCH] acpi/nfit: Require opt-in for read-only label configurations
Recent fixes to command handling enabled Linux to read label
configurations that it could not before. Unfortunately that means that
configurations that were operating in label-less mode will be broken as
the kernel ignores the existing namespace configuration and tries to
honor the new found labels.
Fortunately this seems limited to a case where Linux can quirk the
behavior and maintain the existing label-less semantics by default.
When the platform does not emit an _LSW method, disable all label access
methods. Provide a 'force_labels' module parameter to allow read-only
label operation.
Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection")
Reported-by: Dexuan Cui
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 811c399a3a76..5b5e802de7b8 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -56,6 +56,10 @@ static bool no_init_ars;
module_param(no_init_ars, bool, 0644);
MODULE_PARM_DESC(no_init_ars, "Skip ARS run at nfit init time");
+static bool force_labels;
+module_param(force_labels, bool, 0444);
+MODULE_PARM_DESC(force_labels, "Opt-in to labels despite missing methods");
+
LIST_HEAD(acpi_descs);
DEFINE_MUTEX(acpi_desc_lock);
@@ -1916,6 +1920,19 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc
*acpi_desc,
dev_dbg(dev, "%s: has _LSW\n",
dev_name(_dimm->dev));
set_bit(NFIT_MEM_LSW, _mem->flags);
}
+
+ /*
+* Quirk read-only label configurations to preserve
+* access to label-less namespaces by default.
+*/
+ if (!test_bit(NFIT_MEM_LSW, _mem->flags)
+ && !force_labels) {
+ dev_dbg(dev, "%s: No _LSW, disable labels\n",
+ dev_name(_dimm->dev));
+ clear_bit(NFIT_MEM_LSR, _mem->flags);
+ } else
+ dev_dbg(dev, "%s: Force enable labels\n",
+ dev_name(_dimm->dev));
}
populate_shutdown_status(nfit_mem);
