Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > Adding support to specify 'block' bool in struct perf_event_attr NAK for having _Bool in structures.
Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping
Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
>
> Signed-off-by: Jérôme Glisse
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: Stéphane Marchesin
> Cc: sta...@vger.kernel.org
Well NAK, you are now taking the RCU lock twice and dropping the RCU and
still accessing fobj has a huge potential for accessing freed up memory.
The only correct thing I can see here is to grab a reference to the
fence before printing any info on it,
Christian.
> ---
> drivers/dma-buf/dma-buf.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..f6f4de42ac49 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s,
> void *unused)
> fobj = rcu_dereference(robj->fence);
> shared_count = fobj ? fobj->shared_count : 0;
> fence = rcu_dereference(robj->fence_excl);
> + fence = dma_fence_get_rcu(fence);
> if (!read_seqcount_retry(&robj->seq, seq))
> break;
> rcu_read_unlock();
> }
> -
> - if (fence)
> + if (fence) {
> seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
> fence->ops->get_driver_name(fence),
> fence->ops->get_timeline_name(fence),
> dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + }
> +
> + rcu_read_lock();
> for (i = 0; i < shared_count; i++) {
> fence = rcu_dereference(fobj->shared[i]);
> if (!dma_fence_get_rcu(fence))
> continue;
> + rcu_read_unlock();
> seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
> fence->ops->get_driver_name(fence),
> fence->ops->get_timeline_name(fence),
> dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + rcu_read_lock();
> }
> rcu_read_unlock();
>
[PATCH] radix tree: Don't return internal entries on lookup
Commit 66ee620f06f9 ("idr: Permit any valid kernel pointer to
be stored") changed the radix tree lookup so that it stops when
reaching the bottom of the tree. But radix_tree_descend() may have
changed the node variable to point to an internal entry which then
gets returned to the caller and bad things may happen.
For example, the OCXL driver can easily crash when running tests
that cause radix_tree_lookup() to return RADIX_TREE_RETRY at some
point instead of NULL or a valid pointer, as shown below:
Unable to handle kernel paging request for data at address 0x0406
Faulting instruction address: 0xc06f6ca0
Oops: Kernel access of bad area, sig: 7 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Modules linked in:
CPU: 10 PID: 0 Comm: swapper/10 Not tainted 4.20.0-rc5-fxb-dirty #1
NIP: c06f6ca0 LR: c06f6c90 CTR: c06f6b80
REGS: c007bff23a80 TRAP: 0300 Not tainted (4.20.0-rc5-fxb-dirty)
MSR: 90009033 CR: 48004422 XER: 2004
CFAR: c0aebbe4 DAR: 0406 DSISR: 0008 IRQMASK: 1
GPR00: c00712ff0a38 c007bff23d10 c1025a00 0406
GPR04: c007182f8d70
GPR08: 0406 c007182f8d98 004d0008 fffd
GPR12: 0040 c007bfff4200 c47d7f90 0a205200
GPR16: 0001 0008 c0044480
GPR20: c1060174 0001 0002 0001
GPR24: 0097 c0002d613000 7fff9223 12b4
GPR28: c0002d80 4d000800 c00712ff0a00
NIP [c06f6ca0] xsl_fault_handler+0x120/0x310
LR [c06f6c90] xsl_fault_handler+0x110/0x310
Call Trace:
[c007bff23d10] [c06f6d7c] xsl_fault_handler+0x1fc/0x310 (unreliable)
[c007bff23da0] [c0164e8c] __handle_irq_event_percpu+0x9c/0x2f0
[c007bff23e60] [c0165124] handle_irq_event_percpu+0x44/0xc0
[c007bff23ea0] [c0165204] handle_irq_event+0x64/0xb0
[c007bff23ed0] [c016af68] handle_fasteoi_irq+0xd8/0x230
[c007bff23f00] [c016356c] generic_handle_irq+0x4c/0x70
[c007bff23f20] [c001a394] __do_irq+0xa4/0x210
[c007bff23f90] [c002e3f4] call_do_irq+0x14/0x24
[c47d7a30] [c001a59c] do_IRQ+0x9c/0x130
[c47d7a80] [c0009ce4] h_virt_irq_common+0x124/0x130
--- interrupt: ea1 at snooze_loop+0x138/0x280
LR = snooze_loop+0x260/0x280
[c47d7d80] [c10600b0] cpu_idle_force_poll+0x0/0x8 (unreliable)
[c47d7dc0] [c0904b98] cpuidle_enter_state+0xa8/0x4c0
[c47d7e30] [c012c3dc] call_cpuidle+0x4c/0x80
[c47d7e50] [c012c98c] do_idle+0x2cc/0x370
[c47d7ec0] [c012cc88] cpu_startup_entry+0x38/0x40
[c47d7ef0] [c0046b54] start_secondary+0x664/0x670
[c47d7f90] [c000ac70] start_secondary_prolog+0x10/0x14
Instruction dump:
418201c8 7ba93e24 7fa4eb78 387f0030 fbc10080 7f9c4a14 83dc003c 483f4fed
6000 7c681b79 41820058 57cac03e 53ca421e 53ca463e 7d4707b4
---[ end trace d17a5522f20aacd2 ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!
Code is:
static irqreturn_t xsl_fault_handler(int irq, void *data)
{
...
rcu_read_lock();
pe_data = radix_tree_lookup(&spa->pe_tree, pe_handle);
if (!pe_data) {
...
}
WARN_ON(pe_data->mm->context.id != pid);
pe_data is equal to R3 which is the return value of radix_tree_lookup(),
ie, 0x406 == RADIX_TREE_RETRY.
Fix this by not breaking out of the loop if the node points to an internal
entry.
Fixes: 66ee620f06f9 ("idr: Permit any valid kernel pointer to be stored")
Signed-off-by: Greg Kurz
---
lib/radix-tree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 1106bb6aa01e..462a71962a0e 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -789,7 +789,7 @@ void *__radix_tree_lookup(const struct radix_tree_root
*root,
parent = entry_to_node(node);
offset = radix_tree_descend(parent, &node, index);
slot = parent->slots + offset;
- if (parent->shift == 0)
+ if (!radix_tree_is_internal_node(node) && parent->shift == 0)
break;
}
Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote:
> +static void trace_block_syscall(struct pt_regs *regs, bool enter)
> +{
> + current->perf_blocked = true;
> +
> + do {
> + schedule_timeout(100 * HZ);
> + current->perf_blocked_cnt = 0;
> +
> + if (enter) {
> + /* perf syscalls:* enter */
> + perf_trace_syscall_enter(regs);
> +
> + /* perf raw_syscalls:* enter */
> + perf_trace_sys_enter(&event_sys_enter, regs,
> regs->orig_ax);
> + } else {
> + /* perf syscalls:* enter */
> + perf_trace_syscall_exit(regs);
> +
> + /* perf raw_syscalls:* enter */
> + perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);
> + }
> + } while (current->perf_blocked_cnt);
> +
> + current->perf_blocked = false;
> +}
I don't understand this.. why are we using schedule_timeout() and all
that?
Re: [PATCH] PCI: controller: dwc: Make PCI_IMX6 depend on PCIEPORTBUS
Hi Andrey,
Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
Andrey Smirnov writes:
> Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n
> produces a system where built-in PCIE bridge (16c3:abcd) isn't bound
> to pcieport driver. This, in turn, results in a PCIE bus that is
> capable of enumerating attached PCIE device, but lacks functional
> interrupt support.
Robert, does that fix your issue?
> Signed-off-by: Andrey Smirnov
> ---
>
> Assuming this is a reasonable dependency, shold this be done to more
> than just i.MX6 driver?
>
> drivers/pci/controller/dwc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/controller/dwc/Kconfig
> b/drivers/pci/controller/dwc/Kconfig
> index 2b139acccf32..44ededbeab85 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -92,6 +92,7 @@ config PCI_IMX6
> bool "Freescale i.MX6 PCIe controller"
> depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
> depends on PCI_MSI_IRQ_DOMAIN
> + depends on PCIEPORTBUS
This effectively disables PCIe in imx_v6_v7_defconfig, since
CONFIG_PCIEPORTBUS is not enabled there. Maybe do 'select' instead?
> Select PCIE_DW_HOST
>
> config PCIE_SPEAR13XX
baruch
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/614800.html
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Re: [PATCH v14 03/11] livepatch: Consolidate klp_free functions
On Wed 2018-12-05 14:02:20, Joe Lawrence wrote:
> On Thu, Nov 29, 2018 at 10:44:23AM +0100, Petr Mladek wrote:
> > The code for freeing livepatch structures is a bit scattered and tricky:
> >
> > [ ... snip ... ]
> >
> > +static int klp_init_patch(struct klp_patch *patch)
> > +{
> > + struct klp_object *obj;
> > + int ret;
> > +
> > + mutex_lock(&klp_mutex);
> > +
> > + ret = klp_init_patch_before_free(patch);
> > if (ret) {
> > mutex_unlock(&klp_mutex);
> > return ret;
> > }
> >
>
> I believe klp_init_patch_before_free() accumulates more responsibilities
> later in the patchset, but I'll ask here: does it really need the
> klp_mutex since it looks to be operating only on the klp_patch, its
> objects and functions?
I do not have a strong opinion about it.
On one hand, we are manipulating all the structures and should prevent
any parallel use. On the other hand, the rest of the code will not
touch the patch until it is added into klp_patches list or until
the sysfs interface is created.
If you think that it might cause false expectations and confusions
then I could move it out of the lock.
Well, in the final version we need to call klp_check_patch_conflict()
under the mutex.
Best Regards,
Petr
Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote:
> @@ -10461,6 +10484,19 @@ SYSCALL_DEFINE5(perf_event_open,
> return -EINVAL;
> }
>
> + if (attr.block) {
> + /*
> + * Allow only syscall tracepoints, check for syscall class
> + * is made in the tracepoint event_init callback.
> + */
> + if (attr.type != PERF_TYPE_TRACEPOINT)
> + return -EINVAL;
> +
> + /* Allow to block only if we attach to a process. */
> + if (pid == -1)
> + return -EINVAL;
> + }
> +
> /* Only privileged users can get physical addresses */
> if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
> perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
That's fairly horrible and will, when copied, lead to a giant mess.
Please see the whole exclusion patch set here:
https://lkml.kernel.org/r/1543230756-15319-1-git-send-email-andrew.mur...@arm.com
PERF_PMU_CAP_BLOCK sounds like something you'd want here.
Re: [PATCH v6 4/7] tpm: modify tpm_pcr_read() definition to pass a TPM hash algorithm
On 12/05/2018 05:10 AM, Jarkko Sakkinen wrote:
On Tue, Dec 04, 2018 at 09:21:35AM +0100, Roberto Sassu wrote:
Currently the TPM driver allows other kernel subsystems to read only the
SHA1 PCR bank. This patch modifies the parameters of tpm_pcr_read() and
tpm2_pcr_read() to pass a tpm_digest structure, which contains the desired
hash algorithm. Also, since commit 125a22105410 ("tpm: React correctly to
RC_TESTING from TPM 2.0 self tests") removed the call to tpm2_pcr_read(),
the new parameter is expected to be always not NULL.
Due to the API change, IMA functions have been modified.
Signed-off-by: Roberto Sassu
Acked-by: Mimi Zohar
Reviewed-by: Jarkko Sakkinen
Mimi, Nayna, can you help with testing this (because of the IMA change)?
Sure, I will try to do by end of my day tomorrow,
Thanks & Regards,
- Nayna
/Jarkko
linux-next: Tree for Dec 6
Hi all,
Changes since 20181205:
New trees: thunderbolt, thunderbolt-next
The rdma tree still had its build failure so I used the version from
next-20181203.
The drm-misc tree gained a build failure so I used the version from
next-20181205.
The char-misc tree gained a conflict against the mmc tree.
The device-mapper tree gained a build failure so I reverted its changes
for today.
The akpm-current tree still had its build failure for which I added a
fix patch and gained conflicts against the powerpc tree.
The akpm tree gained a conflict against the btrfs-kdave tree.
Non-merge commits (relative to Linus' tree): 6703
7132 files changed, 321132 insertions(+), 184362 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 288 trees (counting Linus' and 68 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 (d08970904582 Merge tag 'for-4.20-rc5-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux)
Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs)
Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2)
Merging arc-current/for-curr (10d443431dc2 ARC: io.h: Implement
reads{x}()/writes{x}())
Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential
uninitialized return)
Merging arm64-fixes/for-next/fixes (ea2412dc21cc ACPI/IORT: Fix
iort_get_platform_device_domain() uninitialized pointer value)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (bf3d6afbb234 powerpc: Look for "stdout-path" when
setting up legacy consoles)
Merging sparc/master (f3f950dba37b Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (64d47902fea3 Merge tag 'mac80211-for-davem-2018-12-05' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211)
Merging bpf/master (a92a72a24d48 Merge branch 'bpf-verifier-resilience')
Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on
acquire)
Merging netfilter/master (4c05ec47384a netfilter: nf_tables: fix suspicious RCU
usage in nft_chain_stats_replace())
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates
of non-anonymous set)
Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4)
Merging mac80211/master (312ca38ddda6 cfg80211: Fix busy loop regression in
ieee80211_ie_split_ric())
Merging rdma-fixes/for-rc (37b06e507897 IB/mlx5: Fix implicit ODP interrupted
page fault)
Merging sound-current/for-linus (b72f936f6b32 ALSA: hda/realtek: Fix mic issue
on Acer AIO Veriton Z4860G/Z6860G)
Merging sound-asoc-fixes/for-linus (cc5dcb7578f8 Merge branch 'asoc-4.20' into
asoc-linus)
Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3)
Merging regulator-fixes/for-linus (0b35c52dfacf Merge branch 'regulator-4.20'
into regulator-linus)
Merging spi-fixes/for-linus (92e932e6ff58 Merge branch 'spi-4.20' into
spi-linus)
Merging pci-current/for-linus (b07b864ee423 Revert "PCI/ASPM: Do not initialize
link state when aspm_disabled is set")
Merging driver-core.current/driver-core-linus (2595646791c3 Linux 4.20-rc5)
Merging tty.current/tty-linus (100bc3e2bebf tty: serial: 8250_mtk: always
resume the device in probe.)
Re: [PATCH v3] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)
On Wed, 5 Dec 2018 21:12:46 -0200
Fabio Estevam wrote:
> Hi Lukasz/Rob,
>
> On Tue, Oct 9, 2018 at 7:50 AM Lukasz Majewski wrote:
>
> > +&dspi3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_dspi3>;
> > + bus-num = <3>;
> > + status = "okay";
> > + spi-slave;
> > +
> > + slave@0 {
> > + compatible = "lwn,bk4";
> > + spi-max-frequency = <3000>;
> > + reg = <0>;
> > + };
> > +};
>
> This is causing the following dtc warning in linux-next:
>
> DTC arch/arm/boot/dts/vf610-bk4.dtb
> arch/arm/boot/dts/vfxxx.dtsi:550.24-563.6: Warning (spi_bus_bridge):
> /soc/aips-bus@4008/spi@400ad000: incorrect #address-cells for SPI
> bus
> also defined at arch/arm/boot/dts/vf610-bk4.dts:106.8-118.3
> arch/arm/boot/dts/vf610-bk4.dtb: Warning (spi_bus_reg): Failed
> prerequisite 'spi_bus_bridge'
>
> If spi-slave property is removed the warning is gone.
The spi-slave has been added according to review suggestion:
https://lkml.org/lkml/2018/9/26/836
That is the way to handle "slave" SPI operation mode across the kernel.
At the time of development - I've checked my NXP related patches with
W=1 passed to make. No warnings observed then.
>
> Looking at drivers/spi/spi-fsl-dspi.c I don't see the "spi-slave"
> property being handled there.
>
> Any ideas on how to fix this?
The *.dts file for Vybrid was sent and work on in parallel with the SPI
slave code implementation for Vybrid:
https://patchwork.kernel.org/patch/10680431/
Unfortunately, for the above patch I did not received any feedback
since mid September.
>
> Thanks
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpcDdBjnOZbe.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
On Thu, Dec 06, 2018 at 09:10:28AM +0100, Peter Zijlstra wrote:
> On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote:
> > +static void trace_block_syscall(struct pt_regs *regs, bool enter)
> > +{
> > + current->perf_blocked = true;
> > +
> > + do {
> > + schedule_timeout(100 * HZ);
> > + current->perf_blocked_cnt = 0;
> > +
> > + if (enter) {
> > + /* perf syscalls:* enter */
> > + perf_trace_syscall_enter(regs);
> > +
> > + /* perf raw_syscalls:* enter */
> > + perf_trace_sys_enter(&event_sys_enter, regs,
> > regs->orig_ax);
> > + } else {
> > + /* perf syscalls:* enter */
> > + perf_trace_syscall_exit(regs);
> > +
> > + /* perf raw_syscalls:* enter */
> > + perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);
> > + }
> > + } while (current->perf_blocked_cnt);
> > +
> > + current->perf_blocked = false;
> > +}
>
> I don't understand this.. why are we using schedule_timeout() and all
> that?
the idea is to block the process and try to deliver the event later
the ring buffer space is freed by user space process moving the tail
pointer, so I can't see doing this other way than polling
jirka
Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi All, On 2018-12-05 17:11, Anand Moon wrote: > Hi Krzysztof, > > Thanks for your review. > . > On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski wrote: >> On Tue, 4 Dec 2018 at 20:40, Anand Moon wrote: >>> Add suspend-to-mem node to regulator core to be enabled or disabled >>> during system suspend and also support changing the regulator operating >>> mode during runtime and when the system enter sleep mode. >>> >>> Signed-off-by: Anand Moon >>> --- >>> Tested on Odroid U3+ >>> ... > Well I have tested this patch as following > with only one issue, before enable suspend number of On-line cpu is 4 > after resume number of On-line cpu is 1. This seems to be a regression in v4.20-rc1, not related to dts changes at all. I'm investigating this now... > ... Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH v14 05/11] livepatch: Simplify API by removing registration step
On Wed 2018-12-05 14:32:53, Joe Lawrence wrote: > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > > index 972520144713..e01dfa3b58d2 100644 > > --- a/kernel/livepatch/core.c > > +++ b/kernel/livepatch/core.c > > @@ -45,7 +45,7 @@ > > */ > > DEFINE_MUTEX(klp_mutex); > > > > -/* Registered patches */ > > +/* Actively used patches. */ > > LIST_HEAD(klp_patches); > > By itself, this comment makes me wonder if there are un-active and/or > un-used patches that I need to worry about. After this patchset, > klp_patches will include patches that have been enabled and those that > have been replaced, but the replacement transition is still in progress. > > If that sounds accurate, how about adding to the comment: > > /* Actively used patches: enabled or replaced and awaiting transition */ The replaced patches are not in the list. This is why I used the word "actively". /* * Actively used patches: enabled or in transition. Note that replaced * or disabled patches are not listed even though the related kernel * module still can be loaded. */ Best Regards, Petr
Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline
On Thu 06-12-18 11:07:33, Pingfan Liu wrote:
> On Wed, Dec 5, 2018 at 5:40 PM Vlastimil Babka wrote:
> >
> > On 12/5/18 10:29 AM, Pingfan Liu wrote:
> > >> [0.007418] Early memory node ranges
> > >> [0.007419] node 1: [mem 0x1000-0x0008efff]
> > >> [0.007420] node 1: [mem 0x0009-0x0009]
> > >> [0.007422] node 1: [mem 0x0010-0x5c3d6fff]
> > >> [0.007422] node 1: [mem 0x643df000-0x68ff7fff]
> > >> [0.007423] node 1: [mem 0x6c528000-0x6fff]
> > >> [0.007424] node 1: [mem 0x0001-0x00047fff]
> > >> [0.007425] node 5: [mem 0x00048000-0x00087eff]
> > >>
> > >> There is clearly no node2. Where did the driver get the node2 from?
> >
> > I don't understand these tables too much, but it seems the other nodes
> > exist without them:
> >
> > [0.007393] SRAT: PXM 2 -> APIC 0x20 -> Node 2
> >
> > Maybe the nodes are hotplugable or something?
> >
> I also not sure about it, and just have a hurry look at acpi spec. I
> will reply it on another email, and Cced some acpi guys about it
>
> > > Since using nr_cpus=4 , the node2 is not be instanced by x86 initalizing
> > > code.
> >
> > Indeed, nr_cpus seems to restrict what nodes we allocate and populate
> > zonelists for.
>
> Yes, in init_cpu_to_node(), since nr_cpus limits the possible cpu,
> which affects the loop for_each_possible_cpu(cpu) and skip the node2
> in this case.
THanks for pointing this out. It made my life easier. So It think the
bug is that we call init_memory_less_node from this path. I suspect
numa_register_memblks is the right place to do this. So I admit I
am not 100% sure but could you give this a try please?
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 1308f5408bf7..4575ae4d5449 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -527,6 +527,19 @@ static void __init numa_clear_kernel_node_hotplug(void)
}
}
+static void __init init_memory_less_node(int nid)
+{
+ unsigned long zones_size[MAX_NR_ZONES] = {0};
+ unsigned long zholes_size[MAX_NR_ZONES] = {0};
+
+ free_area_init_node(nid, zones_size, 0, zholes_size);
+
+ /*
+* All zonelists will be built later in start_kernel() after per cpu
+* areas are initialized.
+*/
+}
+
static int __init numa_register_memblks(struct numa_meminfo *mi)
{
unsigned long uninitialized_var(pfn_align);
@@ -592,6 +605,8 @@ static int __init numa_register_memblks(struct numa_meminfo
*mi)
continue;
alloc_node_data(nid);
+ if (!end)
+ init_memory_less_node(nid);
}
/* Dump memblock with node info and return. */
@@ -721,21 +736,6 @@ void __init x86_numa_init(void)
numa_init(dummy_numa_init);
}
-static void __init init_memory_less_node(int nid)
-{
- unsigned long zones_size[MAX_NR_ZONES] = {0};
- unsigned long zholes_size[MAX_NR_ZONES] = {0};
-
- /* Allocate and initialize node data. Memory-less node is now online.*/
- alloc_node_data(nid);
- free_area_init_node(nid, zones_size, 0, zholes_size);
-
- /*
-* All zonelists will be built later in start_kernel() after per cpu
-* areas are initialized.
-*/
-}
-
/*
* Setup early cpu_to_node.
*
@@ -763,9 +763,6 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
- if (!node_online(node))
- init_memory_less_node(node);
-
numa_set_node(cpu, node);
}
}
--
Michal Hocko
SUSE Labs
Re: [PATCH] CIFS: Avoid returning EBUSY to upper layer VFS
Tentatively pushed to cifs-2.6.git for-next
On Wed, Dec 5, 2018 at 10:52 PM Long Li wrote:
>
> From: Long Li
>
> EBUSY is not handled by VFS, and will be passed to user-mode. This is not
> correct as we need to wait for more credits.
>
> This patch also fixes a bug where rsize or wsize is used uninitialized when
> the call to server->ops->wait_mtu_credits() fails.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Long Li
> ---
> fs/cifs/file.c | 31 ++-
> 1 file changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
> index 74c33d5..c9bc56b 100644
> --- a/fs/cifs/file.c
> +++ b/fs/cifs/file.c
> @@ -2541,14 +2541,13 @@ static int
> cifs_resend_wdata(struct cifs_writedata *wdata, struct list_head *wdata_list,
> struct cifs_aio_ctx *ctx)
> {
> - int wait_retry = 0;
> unsigned int wsize, credits;
> int rc;
> struct TCP_Server_Info *server =
> tlink_tcon(wdata->cfile->tlink)->ses->server;
>
> /*
> -* Try to resend this wdata, waiting for credits up to 3 seconds.
> +* Wait for credits to resend this wdata.
> * Note: we are attempting to resend the whole wdata not in segments
> */
> do {
> @@ -2556,19 +2555,13 @@ cifs_resend_wdata(struct cifs_writedata *wdata,
> struct list_head *wdata_list,
> server, wdata->bytes, &wsize, &credits);
>
> if (rc)
> - break;
> + goto out;
>
> if (wsize < wdata->bytes) {
> add_credits_and_wake_if(server, credits, 0);
> msleep(1000);
> - wait_retry++;
> }
> - } while (wsize < wdata->bytes && wait_retry < 3);
> -
> - if (wsize < wdata->bytes) {
> - rc = -EBUSY;
> - goto out;
> - }
> + } while (wsize < wdata->bytes);
>
> rc = -EAGAIN;
> while (rc == -EAGAIN) {
> @@ -3234,14 +3227,13 @@ static int cifs_resend_rdata(struct cifs_readdata
> *rdata,
> struct list_head *rdata_list,
> struct cifs_aio_ctx *ctx)
> {
> - int wait_retry = 0;
> unsigned int rsize, credits;
> int rc;
> struct TCP_Server_Info *server =
> tlink_tcon(rdata->cfile->tlink)->ses->server;
>
> /*
> -* Try to resend this rdata, waiting for credits up to 3 seconds.
> +* Wait for credits to resend this rdata.
> * Note: we are attempting to resend the whole rdata not in segments
> */
> do {
> @@ -3249,24 +3241,13 @@ static int cifs_resend_rdata(struct cifs_readdata
> *rdata,
> &rsize, &credits);
>
> if (rc)
> - break;
> + goto out;
>
> if (rsize < rdata->bytes) {
> add_credits_and_wake_if(server, credits, 0);
> msleep(1000);
> - wait_retry++;
> }
> - } while (rsize < rdata->bytes && wait_retry < 3);
> -
> - /*
> -* If we can't find enough credits to send this rdata
> -* release the rdata and return failure, this will pass
> -* whatever I/O amount we have finished to VFS.
> -*/
> - if (rsize < rdata->bytes) {
> - rc = -EBUSY;
> - goto out;
> - }
> + } while (rsize < rdata->bytes);
>
> rc = -EAGAIN;
> while (rc == -EAGAIN) {
> --
> 2.7.4
>
--
Thanks,
Steve
Re: [PATCH 10/14] dt-bindings: pinctrl: milbeaut: Add Milbeaut M10V pinctrl description
Hi,
Thank you for your comments.
On 2018/12/05 8:11, Rob Herring wrote:
On Mon, Nov 19, 2018 at 10:02:12AM +0900, Sugaya Taichi wrote:
Add DT bindings document for Milbeaut M10V pinctrl.
Signed-off-by: Sugaya Taichi
---
.../pinctrl/socionext,milbeaut-pinctrl.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/socionext,milbeaut-pinctrl.txt
diff --git
a/Documentation/devicetree/bindings/pinctrl/socionext,milbeaut-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/socionext,milbeaut-pinctrl.txt
new file mode 100644
index 000..7469189
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/socionext,milbeaut-pinctrl.txt
@@ -0,0 +1,33 @@
+Milbeaut SoCs pin controller
+
+Required properties:
+- compatible: should be one of the following:
+"socionext,milbeaut-m10v-pinctrl" - for m10v SoC
+- reg: offset and length of the register set.
+- reg-names: should be "pinctrl", "exiu".
+- gpio-cells; should be 2.
#gpio-cells
gpio-controller?
Ah yes. I forgot to add it.
Add it.
+- interrupt-cells: should be 2.
#interrupt-cells
interrupt-controller?
Add it also.
Thanks,
Sugaya Taichi
+- clocks: phandle to the input clock.
+- interrupts: three interrupts specifer.
+- interrupt-names: corresponds "interrupts" factor.
+
+Example:
+ pinctrl: pinctrl@1d022000 {
+ compatible = "socionext,milbeaut-m10v-pinctrl";
+ reg = <0x1d022000 0x1000>,
+ <0x1c26f000 0x1000>;
+ reg-names = "pinctrl", "exiu";
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&dummy_clk>;
+ interrupts = <0 54 4>, <0 55 4>, <0 56 4>, <0 57 4>,
+ <0 58 4>, <0 59 4>, <0 60 4>, <0 61 4>,
+ <0 62 4>, <0 63 4>, <0 64 4>, <0 65 4>,
+ <0 66 4>, <0 67 4>, <0 68 4>, <0 69 4>;
+ interrupt-names = "pin-48", "pin-49", "pin-50", "pin-51",
+ "pin-52", "pin-53", "pin-54", "pin-55",
+ "pin-56", "pin-57", "pin-58", "pin-59",
+ "pin-60", "pin-61", "pin-62", "pin-63";
+ }
--
1.9.1
RE: [LINUX PATCH v12 2/2] memory: pl353: Add driver for arm pl353 static memory controller
Hi Michal,
Ok, will update and will send new patch.
Thanks,
Naga Sureshkumar Relli
> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Wednesday, December 5, 2018 8:17 PM
> To: Naga Sureshkumar Relli ; mma...@broadcom.com;
> f.faine...@gmail.com; la...@linux-mips.org; tred...@nvidia.com;
> dig...@gmail.com; d-
> gerl...@ti.com
> Cc: linus.wall...@linaro.org; Michal Simek ; linux-
> ker...@vger.kernel.org
> Subject: Re: [LINUX PATCH v12 2/2] memory: pl353: Add driver for arm pl353
> static
> memory controller
>
> On 29. 11. 18 13:57, Naga Sureshkumar Relli wrote:
> > Add driver for arm pl353 static memory controller. This controller is
> > used in Xilinx Zynq SoC for interfacing the NAND and NOR/SRAM memory
> > devices.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> >
> > Reviewed-by: Linus Walleij
> > ---
> > drivers/memory/Kconfig | 9 +
> > drivers/memory/Makefile| 1 +
> > drivers/memory/pl353-smc.c | 468
> > +
> > include/linux/pl353-smc.h | 30 +++
> > 4 files changed, 508 insertions(+)
> > create mode 100644 drivers/memory/pl353-smc.c create mode 100644
> > include/linux/pl353-smc.h
> >
>
> Missing changelog which was there in v11
> https://lore.kernel.org/patchwork/patch/961604/
>
> > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > 63389f0..2d91b00 100644
> > --- a/drivers/memory/Kconfig
> > +++ b/drivers/memory/Kconfig
> > @@ -145,6 +145,15 @@ config DA8XX_DDRCTL
> > Texas Instruments da8xx SoCs. It's used to tweak various memory
> > controller configuration options.
> >
> > +config PL353_SMC
> > + tristate "ARM PL35X Static Memory Controller(SMC) driver"
> > + default y
> > + depends on ARM
> > + depends on ARM_AMBA
> > + help
> > + This driver is for the ARM PL351/PL353 Static Memory
> > + Controller(SMC) module.
> > +
> > source "drivers/memory/samsung/Kconfig"
> > source "drivers/memory/tegra/Kconfig"
> >
> > diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index
> > a01ab3e..90161de 100644
> > --- a/drivers/memory/Makefile
> > +++ b/drivers/memory/Makefile
> > @@ -19,6 +19,7 @@ obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o
> > obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc.o
> > obj-$(CONFIG_MTK_SMI) += mtk-smi.o
> > obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
> > +obj-$(CONFIG_PL353_SMC)+= pl353-smc.o
> >
> > obj-$(CONFIG_SAMSUNG_MC) += samsung/
> > obj-$(CONFIG_TEGRA_MC) += tegra/
> > diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c
> > new file mode 100644 index 000..6738a84
> > --- /dev/null
> > +++ b/drivers/memory/pl353-smc.c
> > @@ -0,0 +1,468 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * ARM PL353 SMC driver
> > + *
> > + * Copyright (C) 2012 - 2018 Xilinx, Inc
> > + * Author: Punnaiah Choudary Kalluri
> > + * Author: Naga Sureshkumar Relli
> > + *
>
> remove line above.
>
> and then fix these two
>
> CHECK: Please use a blank line after function/struct/union/enum declarations
> #359: FILE: drivers/memory/pl353-smc.c:299:
> +}
> +static struct amba_driver pl353_smc_driver;
>
> CHECK: Alignment should match open parenthesis
> #369: FILE: drivers/memory/pl353-smc.c:309:
> +void pl353_smc_init_nand_interface(struct amba_device *adev,
> + struct device_node *nand_node)
>
> total: 0 errors, 2 warnings, 2 checks, 520 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
>
> and also
> this doesn't right too.
>
> drivers/memory/pl353-smc.c:308:6: warning: symbol
> 'pl353_smc_init_nand_interface' was
> not declared. Should it be static?
> CC drivers/memory/pl353-smc.o
> drivers/memory/pl353-smc.c:308:6: warning: no previous prototype for
> ‘pl353_smc_init_nand_interface’ [-Wmissing-prototypes] void
> pl353_smc_init_nand_interface(struct amba_device *adev,
> ^
> drivers/memory/pl353-smc.c:439:34: warning: ‘pl353_smc_of_match’ defined but
> not used
> [-Wunused-const-variable=] static const struct of_device_id
> pl353_smc_of_match[] = {
>
> Thanks,
> Michal
RE: [LINUX PATCH v12 1/2] dt-bindings: memory: Add pl353 smc controller devicetree binding information
Hi Michal,
> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Wednesday, December 5, 2018 8:13 PM
> To: Naga Sureshkumar Relli ; mma...@broadcom.com;
> f.faine...@gmail.com; la...@linux-mips.org; tred...@nvidia.com;
> dig...@gmail.com; d-
> gerl...@ti.com
> Cc: linus.wall...@linaro.org; Michal Simek ; linux-
> ker...@vger.kernel.org
> Subject: Re: [LINUX PATCH v12 1/2] dt-bindings: memory: Add pl353 smc
> controller
> devicetree binding information
>
> On 29. 11. 18 13:57, Naga Sureshkumar Relli wrote:
> > Add pl353 static memory controller devicetree binding information.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> >
> > Reviewed-by: Linus Walleij
> > ---
> > .../bindings/memory-controllers/pl353-smc.txt | 47
> ++
> > 1 file changed, 47 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > new file mode 100644
> > index 000..d56615f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > +++ xt
> > @@ -0,0 +1,47 @@
> > +Device tree bindings for ARM PL353 static memory controller
> > +
> > +PL353 static memory controller supports two kinds of memory
> > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > +The actual devices are instantiated from the child nodes of pl353 smc node.
> > +
> > +Required properties:
> > +- compatible : Should be "arm,pl353-smc-r2p1",
> > "arm,primecell".
> > +- reg : Controller registers map and length.
> > +- clock-names : List of input clock names - "memclk",
> > "apb_pclk"
> > + (See clock bindings for details).
> > +- clocks : Clock phandles (see clock bindings for details).
> > +- address-cells: Must be 2.
> > +- size-cells : Must be 1.
> > +
> > +Child nodes:
> > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > +drivers are supported as child nodes.
> > +
> > +for NAND partition information please refer the below file
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + smcc: memory-controller@e000e000
> > + compatible = "arm,pl353-smc-r2p1", "arm,primecell";
> > + clock-names = "memclk", "apb_pclk";
> > + clocks = <&clkc 11>, <&clkc 44>;
> > + reg = <0xe000e000 0x1000>;
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0xe100 0x100 //Nand CS Region
> > + 0x1 0x0 0xe200 0x200 //SRAM/NOR CS
> Region
> > + 0x2 0x0 0xe400 0x200>; //SRAM/NOR CS
> Region
> > + nand_0: flash@e100 {
> > + compatible = "arm,pl353-nand-r2p1"
> > + reg = <0 0 0x100>;
> > + (...)
> > + };
> > + nor0: flash@e200 {
> > + compatible = "cfi-flash";
> > + reg = <1 0 0x200>;
> > + };
> > + nor1: flash@e400 {
> > + compatible = "cfi-flash";
> > + reg = <2 0 0x200>;
> > + };
> > + };
> >
>
> v11 was sent long time ago and also reviewed by Linus here
> https://lore.kernel.org/patchwork/patch/961603/
>
> I can't see changelog which you have in v11. And also recorded changes if any.
Ok, will add changelog and will send new patch.
Thanks,
Naga Sureshkumar Relli
> Then this driver will go through arm-soc tree via me.
>
> Thanks,
> Michal
Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
On Thu 06-12-18 05:21:38, Naoya Horiguchi wrote: > On Wed, Dec 05, 2018 at 05:57:16PM +0100, Michal Hocko wrote: > > On Wed 05-12-18 13:29:18, Michal Hocko wrote: > > [...] > > > After some more thinking I am not really sure the above reasoning is > > > still true with the current upstream kernel. Maybe I just managed to > > > confuse myself so please hold off on this patch for now. Testing by > > > Oscar has shown this patch is helping but the changelog might need to be > > > updated. > > > > OK, so Oscar has nailed it down and it seems that 4.4 kernel we have > > been debugging on behaves slightly different. The underlying problem is > > the same though. So I have reworded the changelog and added "just in > > case" PageLRU handling. Naoya, maybe you have an argument that would > > make this void for current upstream kernels. > > The following commit (not in 4.4.x stable tree) might explain the > difference you experienced: > > commit 286c469a988fbaf68e3a97ddf1e6c245c1446968 > Author: Naoya Horiguchi > Date: Wed May 3 14:56:22 2017 -0700 > > mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page > > This commit adds shake_page() for mlocked pages to make sure that the target > page is flushed out from LRU cache. Without this shake_page(), subsequent > delete_from_lru_cache() (from me_pagecache_clean()) fails to isolate it and > the page will finally return back to LRU list. So this scenario leads to > "hwpoisoned by still linked to LRU list" page. OK, I see. So does that mean that the LRU handling is no longer needed and there is a guanratee that all kernels with the above commit cannot ever get an LRU page? -- Michal Hocko SUSE Labs
Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints
On Thu, Dec 06, 2018 at 09:10:28AM +0100, Peter Zijlstra wrote:
> On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote:
> > +static void trace_block_syscall(struct pt_regs *regs, bool enter)
> > +{
> > + current->perf_blocked = true;
> > +
> > + do {
> > + schedule_timeout(100 * HZ);
> > + current->perf_blocked_cnt = 0;
> > +
> > + if (enter) {
> > + /* perf syscalls:* enter */
> > + perf_trace_syscall_enter(regs);
> > +
> > + /* perf raw_syscalls:* enter */
> > + perf_trace_sys_enter(&event_sys_enter, regs,
> > regs->orig_ax);
> > + } else {
> > + /* perf syscalls:* enter */
> > + perf_trace_syscall_exit(regs);
> > +
> > + /* perf raw_syscalls:* enter */
> > + perf_trace_sys_exit(&event_sys_exit, regs, regs->ax);
> > + }
> > + } while (current->perf_blocked_cnt);
> > +
> > + current->perf_blocked = false;
> > +}
>
> I don't understand this.. why are we using schedule_timeout() and all
> that?
Urgh.. in fact, the more I look at this the more I hate it.
We want to block in __perf_output_begin(), but we cannot because both
tracepoints and perf will have preemptability disabled down there.
So what we do is fail the event, fake the lost count and go all the way
up that callstack, detect the failure and then poll-wait and retry.
And only do this for a few special events... *yuck*
[PATCH v3] ARM: smp: add support for per-task stack canaries
On ARM, we currently only change the value of the stack canary when
switching tasks if the kernel was built for UP. On SMP kernels, this
is impossible since the stack canary value is obtained via a global
symbol reference, which means
a) all running tasks on all CPUs must use the same value
b) we can only modify the value when no kernel stack frames are live
on any CPU, which is effectively never.
So instead, use a GCC plugin to add a RTL pass that replaces each
reference to the address of the __stack_chk_guard symbol with an
expression that produces the address of the 'stack_canary' field
that is added to struct thread_info. This way, each task will use
its own randomized value.
Cc: Russell King
Cc: Kees Cook
Cc: Emese Revfy
Cc: Arnd Bergmann
Cc: Laura Abbott
Cc: kernel-harden...@lists.openwall.com
Acked-by: Nicolas Pitre
Signed-off-by: Ard Biesheuvel
---
v3:
- enable the feature automatically if CONFIG_STACKPROTECTOR and
CONFIG_GCC_PLUGINS are both enabled
- move the stack canary to the front of struct thread_info so it shares
a cacheline with the flags, preempt_count and task pointer members
- fix incorrect reference to task_struct::stack_canary in previous
version
arch/arm/Kconfig | 15 +++
arch/arm/Makefile | 12 +++
arch/arm/boot/compressed/Makefile | 1 +
arch/arm/include/asm/stackprotector.h | 12 ++-
arch/arm/include/asm/thread_info.h| 3 +
arch/arm/kernel/asm-offsets.c | 4 +
arch/arm/kernel/process.c | 6 +-
scripts/Makefile.gcc-plugins | 6 ++
scripts/gcc-plugins/Kconfig | 4 +
scripts/gcc-plugins/arm_ssp_per_task_plugin.c | 103
10 files changed, 163 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 91be74d8df65..5c0305585a0a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1810,6 +1810,21 @@ config XEN
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+config STACKPROTECTOR_PER_TASK
+ bool "Use a unique stack canary value for each task"
+ depends on GCC_PLUGINS && STACKPROTECTOR && SMP && !XIP_DEFLATED_DATA
+ select GCC_PLUGIN_ARM_SSP_PER_TASK
+ default y
+ help
+ Due to the fact that GCC uses an ordinary symbol reference from
+ which to load the value of the stack canary, this value can only
+ change at reboot time on SMP systems, and all tasks running in the
+ kernel's address space are forced to use the same canary value for
+ the entire duration that the system is up.
+
+ Enable this option to switch to a different method that uses a
+ different canary value for each task.
+
endmenu
menu "Boot options"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 05a91d8b89f3..0436002d5091 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -303,6 +303,18 @@ else
KBUILD_IMAGE := $(boot)/zImage
endif
+ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
+prepare: stack_protector_prepare
+stack_protector_prepare: prepare0
+ $(eval KBUILD_CFLAGS += \
+ -fplugin-arg-arm_ssp_per_task_plugin-tso=$(shell\
+ awk '{if ($$2 == "THREAD_SZ_ORDER") print $$3;}'\
+ include/generated/asm-offsets.h)\
+ -fplugin-arg-arm_ssp_per_task_plugin-offset=$(shell \
+ awk '{if ($$2 == "TI_STACK_CANARY") print $$3;}'\
+ include/generated/asm-offsets.h))
+endif
+
all: $(notdir $(KBUILD_IMAGE))
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 1f5a5ffe7fcf..01bf2585a0fa 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -101,6 +101,7 @@ clean-files += piggy_data lib1funcs.S ashldi3.S bswapsdi2.S
\
$(libfdt) $(libfdt_hdrs) hyp-stub.S
KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
+KBUILD_CFLAGS += $(DISABLE_ARM_SSP_PER_TASK_PLUGIN)
ifeq ($(CONFIG_FUNCTION_TRACER),y)
ORIG_CFLAGS := $(KBUILD_CFLAGS)
diff --git a/arch/arm/include/asm/stackprotector.h
b/arch/arm/include/asm/stackprotector.h
index ef5f7b69443e..72a20c3a0a90 100644
--- a/arch/arm/include/asm/stackprotector.h
+++ b/arch/arm/include/asm/stackprotector.h
@@ -6,8 +6,10 @@
* the stack frame and verifying that it hasn't been overwritten when
* returning from the function. The pattern is called stack canary
* and gcc expects it to be defined by a global variable called
- * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
- * we cannot have a different canary value per task.
+ * "__stack_chk_guard" on ARM. This prevents SMP systems from using a
+ * different value for each task unless we enable a GCC plugin that
+ * replaces these symbol references with references to each task's own
+ * value.
*/
Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
On 06.12.18 00:03, Peter Hutterer wrote: ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. Signed-off-by: Peter Hutterer Reviewed-by: Martin Kepplinger smime.p7s Description: S/MIME cryptographic signature
[PATCH v4] ftrace: support early boot function tracing
Hi Steven,
Thanks for the feedbacks, I've applied your suggestion on this patch version.
Previous changes:
-
PATCH v1: Initial patch
PATCH v2:
Removed arch specific code and use the default clock.
Add more code re-usability
Add HAVE_EARLY_BOOT_FTRACE config option, which will be disabled by default
PATCH v3:
Write early boot temporary buffer to a sub-buffer instead of the global one.
Improve Kconfig help text.
PATCH v4 starts here :
--
The very early tracing will start from the beginning of start_kernel()
and will stop at ftrace_init()
start_kernel()
{
ftrace_early_init() <--- start early boot function tracing
...
(calls)
...
ftrace_init() <--- stop early bootfunction tracing
early_trace_init();
...
}
The events are placed in a temporary buffer, which will be copied to
the trace buffer after memory setup.
Dynamic tracing is not implemented with live patching, we use
ftrace_filter and ftrace_notrace to find which functions to be
filtered (traced / not traced), then during the callback from
mcount hook, we do binary search lookup to decide which function
to be save or not.
Signed-off-by: Abderrahmane Benbachir
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Mathieu Desnoyers
Cc: linux-kernel@vger.kernel.org
---
arch/x86/Kconfig| 1 +
arch/x86/kernel/ftrace_32.S | 45 --
arch/x86/kernel/ftrace_64.S | 14 ++
include/linux/ftrace.h | 18 ++-
init/main.c | 1 +
kernel/trace/Kconfig| 51 +++
kernel/trace/ftrace.c | 294 +++-
kernel/trace/trace.c| 41 +
8 files changed, 453 insertions(+), 12 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8689e794a43c..f4f754d4aa7a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -152,6 +152,7 @@ config X86
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+ select HAVE_EARLY_BOOT_FTRACE
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
select HAVE_IDE
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 4c8440de3355..a247cbf4c529 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -31,12 +31,8 @@ EXPORT_SYMBOL(mcount)
# define MCOUNT_FRAME 0 /* using frame = false */
#endif
-ENTRY(function_hook)
- ret
-END(function_hook)
-
-ENTRY(ftrace_caller)
+.macro save_mcount_regs
#ifdef USING_FRAME_POINTER
# ifdef CC_USING_FENTRY
/*
@@ -73,11 +69,9 @@ ENTRY(ftrace_caller)
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
+ .endm
-.globl ftrace_call
-ftrace_call:
- callftrace_stub
-
+.macro restore_mcount_regs
addl$4, %esp/* skip NULL pointer */
popl%edx
popl%ecx
@@ -90,6 +84,39 @@ ftrace_call:
addl$4, %esp/* skip parent ip */
# endif
#endif
+ .endm
+
+ENTRY(function_hook)
+#ifdef CONFIG_EARLY_BOOT_FUNCTION_TRACER
+ cmpl$__PAGE_OFFSET, %esp
+ jb early_boot_stub /* Paging not enabled yet? */
+
+ cmpl$ftrace_stub, ftrace_early_boot_trace_function
+ jnz early_boot_trace
+
+early_boot_stub:
+ ret
+
+early_boot_trace:
+ save_mcount_regs
+ call*ftrace_early_boot_trace_function
+ restore_mcount_regs
+
+ jmp early_boot_stub
+#else
+ ret
+#endif
+END(function_hook)
+
+ENTRY(ftrace_caller)
+ save_mcount_regs
+
+.globl ftrace_call
+ftrace_call:
+ callftrace_stub
+
+ restore_mcount_regs
+
.Lftrace_ret:
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
.globl ftrace_graph_call
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 91b2cff4b79a..81736c6e2f9b 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -151,7 +151,21 @@ EXPORT_SYMBOL(mcount)
#ifdef CONFIG_DYNAMIC_FTRACE
ENTRY(function_hook)
+# ifdef CONFIG_EARLY_BOOT_FUNCTION_TRACER
+ cmpq $ftrace_stub, ftrace_early_boot_trace_function
+ jnz early_boot_trace
+
+early_boot_stub:
retq
+
+early_boot_trace:
+ save_mcount_regs
+ call *ftrace_early_boot_trace_function
+ restore_mcount_regs
+ jmp early_boot_stub
+# else
+ retq
+# endif
ENDPROC(function_hook)
ENTRY(ftrace_caller)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index dd16e8218db3..ad68298ca3e0 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -239,6 +239,18 @@ static inline void ftrace_free_init_mem(void) { }
static inline void ftrace_free_mem(struct module *mod, void *start, void *end)
{ }
#endif /* CONFIG_FUNCTION_TRACER */
+#ifdef CONFIG_EARLY_BOOT_FUNCTION_TRACER
+extern void __init ftrace_early_boot_init(char *command_line);
+extern void __init ftrace_early_boot_shutdown(void);
Re: Future of dosfstools project (FAT)
On Thursday 06 December 2018 01:53:02 Andreas Bombe wrote: > Pali Rohár schrieb am Mi., 14. Nov. 2018 um > 12:33 Uhr: > > > And... has somebody else time to look at those pending patches and do > > some initial review? I would really appreciate if somebody look and > > comment them. > > > > There are 14 open pull requests: > > https://github.com/dosfstools/dosfstools/pulls > > > I'll spend time on this again. It would help if you could make a list of > higher priority PRs you would like see being looked at first. So.. here is some list: https://github.com/dosfstools/dosfstools/pull/92 https://github.com/dosfstools/dosfstools/pull/93 https://github.com/dosfstools/dosfstools/pull/94 https://github.com/dosfstools/dosfstools/pull/101 https://github.com/dosfstools/dosfstools/pull/104 https://github.com/dosfstools/dosfstools/pull/84 -- Pali Rohár pali.ro...@gmail.com
Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
This commit adds shake_page() for mlocked pages to make sure that the target page is flushed out from LRU cache. Without this shake_page(), subsequent delete_from_lru_cache() (from me_pagecache_clean()) fails to isolate it and the page will finally return back to LRU list. So this scenario leads to "hwpoisoned by still linked to LRU list" page. OK, I see. So does that mean that the LRU handling is no longer needed and there is a guanratee that all kernels with the above commit cannot ever get an LRU page? For the sake of completeness: I made a quick test reverting 286c469a988 on upstream kernel. As expected, the poisoned page is in LRU when it hits do_migrate_range, and so, the migration path is taken and I see the exact failure I saw on. 4.4 Oscar Salvador --- Suse L3
Re: [PATCH 0/2] Fix return code and improve feature check for synthetic uevents
Dňa 5. 12. 2018 o 17:30 Greg KH napísal(a): > On Wed, Dec 05, 2018 at 12:27:43PM +0100, Peter Rajnoha wrote: >> Two small patches to aid handling of synthetic uevents back in userspace: >> >> - Return error code back to userspace on /sys/.../uevent file write >> failure so userspace knows and it can act accordingly. >> >> - Add new 'kernel/uevent_features' sysfs file to make it possible for >> userspace to check that the extended synthetic uevent arguments are >> supported without relying on kernel version check only. >> >> Peter Rajnoha (2): >> kobject: return error code if writing /sys/.../uevent fails >> kobject: add kernel/uevent_features sysfs file > > Did you send this series twice? Which one should I pay attention to? > > confused, > > greg k-h > They're same, I just sent it again because I forgot to add the LKML list with the first one. So please take the latter one with that list on CC. Sorry for the confusion. -- Peter
Re: [PATCH 2/2] x86/speculation: switch_to_cond_stibp on is the likely case
On Wed, Dec 05, 2018 at 02:49:28PM -0500, Waiman Long wrote:
> Since conditional STIBP is the default, it should be treated as
> the likely case. Changes the use of static_branch_unlikely() to
> static_branch_likely() for switch_to_cond_stibp.
So now you're making kernels on 'fixed' or unaffected hardware slower.
> Signed-off-by: Waiman Long
> ---
> arch/x86/kernel/cpu/bugs.c | 2 +-
> arch/x86/kernel/process.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index a68b32c..bd9 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -153,7 +153,7 @@ void __init check_bugs(void)
> hostval |= ssbd_tif_to_spec_ctrl(ti->flags);
>
> /* Conditional STIBP enabled? */
> - if (static_branch_unlikely(&switch_to_cond_stibp))
> + if (static_branch_likely(&switch_to_cond_stibp))
> hostval |= stibp_tif_to_spec_ctrl(ti->flags);
>
> if (hostval != guestval) {
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 7d31192..39a21ae 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -434,7 +434,7 @@ static __always_inline void
> __speculation_ctrl_update(unsigned long tifp,
>* otherwise avoid the MSR write.
>*/
> if (IS_ENABLED(CONFIG_SMP) &&
> - static_branch_unlikely(&switch_to_cond_stibp)) {
> + static_branch_likely(&switch_to_cond_stibp)) {
> updmsr |= !!(tif_diff & _TIF_SPEC_IB);
> msr |= stibp_tif_to_spec_ctrl(tifn);
> }
> --
> 1.8.3.1
>
Re: [PATCH 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
> Kailang 於 2018年12月5日 週三 下午4:36寫道： > > > > Hi Jian-Hong, > > > > Could you test to change the model to ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC? > > > > .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to > > ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC We do not have ASUS X542UN in hand right now, but we have ASUS X542UQ which goes with the same quirk as X542UN. I tested with ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC, and it also works. So, I am going to send new patch set using ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC for ALC294. Thanks, Jian-Hong Pan
[PATCH v2] clk: npcm7xx: get fixed clocks from DT
The npcm7xx clock module includes 4 PLLs and then a tree of muxes and dividers.
All muxes and dividers are preset before Linux boots. The presetting can change
according to the board.
Linux drivers need to know what the frequencies are, but they cannot change it,
so this whole driver is intended as read only mechanism for clocks.
Before this change PLLs input clk value was defined inside the driver.
With this fix clock will be on the DT.
Signed-off-by: Tali Perry
Signed-off-by: Wei Yongjun
---
drivers/clk/clk-npcm7xx.c | 39 ++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-npcm7xx.c b/drivers/clk/clk-npcm7xx.c
index 27a86b7a34db..4bd2e40997d4 100644
--- a/drivers/clk/clk-npcm7xx.c
+++ b/drivers/clk/clk-npcm7xx.c
@@ -8,13 +8,19 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
+#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
@@ -544,6 +550,7 @@ static void __init npcm7xx_clk_init(struct device_node
*clk_np)
void __iomem *clk_base;
struct resource res;
struct clk_hw *hw;
+ struct clk *clk;
int ret;
int i;
@@ -568,6 +575,31 @@ static void __init npcm7xx_clk_init(struct device_node
*clk_np)
for (i = 0; i < NPCM7XX_NUM_CLOCKS; i++)
npcm7xx_clk_data->hws[i] = ERR_PTR(-EPROBE_DEFER);
+ /* Read fixed clocks. These 3 clocks must be defined in DT */
+ clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_REFCLK);
+ if (IS_ERR(clk)) {
+ pr_err("failed to find external REFCLK on device tree,
err=%ld\n",
+ PTR_ERR(clk));
+ clk_put(clk);
+ goto npcm7xx_init_fail_no_clk_on_dt;
+ }
+
+ clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_SYSBYPCK);
+ if (IS_ERR(clk)) {
+ pr_err("failed to find external SYSBYPCK on device tree,
err=%ld\n",
+ PTR_ERR(clk));
+ clk_put(clk);
+ goto npcm7xx_init_fail_no_clk_on_dt;
+ }
+
+ clk = of_clk_get_by_name(clk_np, NPCM7XX_CLK_S_MCBYPCK);
+ if (IS_ERR(clk)) {
+ pr_err("failed to find external MCBYPCK on device tree,
err=%ld\n",
+ PTR_ERR(clk));
+ clk_put(clk);
+ goto npcm7xx_init_fail_no_clk_on_dt;
+ }
+
/* Register plls */
for (i = 0; i < ARRAY_SIZE(npcm7xx_plls); i++) {
const struct npcm7xx_clk_pll_data *pll_data = &npcm7xx_plls[i];
@@ -646,11 +678,16 @@ static void __init npcm7xx_clk_init(struct device_node
*clk_np)
return;
+npcm7xx_init_fail_no_clk_on_dt:
+ pr_err("see Documentation/devicetree/bindings/clock/");
+ pr_err("nuvoton,npcm750-clk.txt for details\n");
npcm7xx_init_fail:
- kfree(npcm7xx_clk_data->hws);
+ if (npcm7xx_clk_data->num)
+ kfree(npcm7xx_clk_data->hws);
npcm7xx_init_np_err:
iounmap(clk_base);
npcm7xx_init_error:
of_node_put(clk_np);
+ pr_err("clk setup fail\n");
}
CLK_OF_DECLARE(npcm7xx_clk_init, "nuvoton,npcm750-clk", npcm7xx_clk_init);
--
2.14.1
[PATCH] mm: thp: fix soft dirty for migration when split
When splitting a huge migrating PMD, we'll transfer the soft dirty bit from the huge page to the small pages. However we're possibly using a wrong data since when fetching the bit we're using pmd_soft_dirty() upon a migration entry. Fix it up. CC: Andrea Arcangeli CC: Andrew Morton CC: "Kirill A. Shutemov" CC: Matthew Wilcox CC: Michal Hocko CC: Dave Jiang CC: "Aneesh Kumar K.V" CC: Souptick Joarder CC: Konstantin Khlebnikov CC: linux...@kvack.org CC: linux-kernel@vger.kernel.org Signed-off-by: Peter Xu --- I noticed this during code reading. Only compile tested. I'm sending a patch directly for review comments since it's relatively straightforward and not easy to test. Please have a look, thanks. --- mm/huge_memory.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index f2d19e4fe854..fb0787c3dd3b 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2161,7 +2161,10 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, SetPageDirty(page); write = pmd_write(old_pmd); young = pmd_young(old_pmd); - soft_dirty = pmd_soft_dirty(old_pmd); + if (unlikely(pmd_migration)) + soft_dirty = pmd_swp_soft_dirty(old_pmd); + else + soft_dirty = pmd_soft_dirty(old_pmd); /* * Withdraw the table only after we mark the pmd entry invalid. -- 2.17.1
[PATCH v2 0/3] Add ALC294 quirks for ASUS laptops
Add Realtek ALC294 quirks for ASUS X542UN, UX533FD, UX433FN and UX333FA laptops. Chris Chiu (1): ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN Jian-Hong Pan (2): ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294 ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294 sound/pci/hda/patch_realtek.c | 44 +++ 1 file changed, 44 insertions(+) -- 2.11.0
[PATCH v2 3/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX433FN/UX333FA with ALC294
The ASUS UX433FN and UX333FA with ALC294 cannot detect the headset MIC
and output through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Add UX333FA support. ASUS UX533FD, UX433FN and UX333FA use the same quirk
now.
sound/pci/hda/patch_realtek.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1525bcdf96e8..97d1a4aaeccd 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7192,6 +7192,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
{0x14, 0x90170110},
{0x1b, 0x90a70130},
{0x21, 0x04211020}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS",
ALC294_FIXUP_ASUS_SPK_NOISE,
+ {0x12, 0x90a60130},
+ {0x17, 0x90170110},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
Re: [PATCH v14 04/11] livepatch: Refuse to unload only livepatches available during a forced transition
On Mon 2018-12-03 16:29:32, Miroslav Benes wrote: > You probably forgot to replace the subject with Josh's proposal. > > > module_put() is currently never called in klp_complete_transition() when > > klp_force is set. As a result, we might keep the reference count even when > > klp_enable_patch() fails and klp_cancel_transition() is called. > > Correct. > > > This might make an assumption that a module might get blocked in some > > strange init state. Fortunately, it is not the case. The reference count > > is ignored when mod->init fails and erroneous modules are always removed. > > I do not understand the paragraph and its connection to the problem (and I > don't > remember if I understood it previously or not and forgot to mention it). It was one example of the confusion. I wonder if the following text is more clear: One might wonder if the reference could block the module in MODULE_STATE_COMING or MODULE_STATE_GOING infinitely. Fortunately, it is not the case. The reference count is ignored when mod->init fails and erroneous modules are always removed. Or I could remove the paragraph as you suggested below. Best Regards, Petr
[PATCH v2 2/3] ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294
The ASUS UX533FD with ALC294 cannot detect the headset MIC and output
through the internal speaker and the headphone until
ALC294_FIXUP_ASUS_SPK_NOISE quirk applied.
Signed-off-by: Daniel Drake
Signed-off-by: Jian-Hong Pan
---
v2:
- Modify the HDA verbs for UX333FA support
- Make a new ALC294_FIXUP_ASUS_HEADSET_MIC quirk for ALC294 chain
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
sound/pci/hda/patch_realtek.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d32e50b1ed60..1525bcdf96e8 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5518,6 +5518,8 @@ enum {
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
ALC294_FIXUP_ASUS_MIC,
+ ALC294_FIXUP_ASUS_HEADSET_MIC,
+ ALC294_FIXUP_ASUS_SPK_NOISE,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6414,6 +6416,28 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC294_FIXUP_ASUS_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1113c }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
+ [ALC294_FIXUP_ASUS_SPK_NOISE] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Set EAPD high */
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x10 },
+ { 0x20, 0x4c4, 0x20 },
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x40 },
+ { 0x20, 0x488, 0x00 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC294_FIXUP_ASUS_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6556,6 +6580,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x12e0, "ASUS X541SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x13b0, "ASUS Z550SA", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E",
ALC269VB_FIXUP_ASUS_ZENBOOK),
+ SND_PCI_QUIRK(0x1043, 0x14a1, "ASUS UX533FD",
ALC294_FIXUP_ASUS_SPK_NOISE),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A",
ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
--
2.11.0
[PATCH v2 1/3] ALSA: hda/realtek: ALC294 mic and headset-mode fixups for ASUS X542UN
From: Chris Chiu
The known ALC256_FIXUP_ASUS_MIC fixup can fix the headphone jack
sensing and enable use of the internal microphone on this laptop
X542UN. However, it's ALC294 so create a new fixup named
ALC294_FIXUP_ASUS_MIC to avoid confusion.
Signed-off-by: Jian-Hong Pan
Signed-off-by: Daniel Drake
Signed-off-by: Chris Chiu
---
v2:
- .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE ==> change to
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
sound/pci/hda/patch_realtek.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb40624fb6d5..d32e50b1ed60 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5517,6 +5517,7 @@ enum {
ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
ALC295_FIXUP_HP_AUTO_MUTE,
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE,
+ ALC294_FIXUP_ASUS_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6403,6 +6404,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MIC
},
+ [ALC294_FIXUP_ASUS_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x13, 0x90a60160 }, /* use as internal mic */
+ { 0x19, 0x04a11120 }, /* use as headset mic, without
its own jack detect */
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7152,6 +7163,10 @@ static const struct snd_hda_pin_quirk
alc269_pin_fixup_tbl[] = {
SND_HDA_PIN_QUIRK(0x10ec0293, 0x1028, "Dell",
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC292_STANDARD_PINS,
{0x13, 0x90a60140}),
+ SND_HDA_PIN_QUIRK(0x10ec0294, 0x1043, "ASUS", ALC294_FIXUP_ASUS_MIC,
+ {0x14, 0x90170110},
+ {0x1b, 0x90a70130},
+ {0x21, 0x04211020}),
SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell",
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC295_STANDARD_PINS,
{0x17, 0x21014020},
--
2.11.0
Re: [PATCH] proc/sysctl: fix return error for proc_doulongvec_minmax
On Thu, Dec 06, 2018 at 03:36:15PM +0800, Cheng Lin wrote:
> If the number of input parameters is less than the total
> parameters, an EINVAL error will be returned.
>
> e.g.
> We use proc_doulongvec_minmax to pass up to two parameters
> with kern_table.
>
> {
> .procname = "monitor_signals",
> .data = &monitor_sigs,
> .maxlen = 2*sizeof(unsigned long),
> .mode = 0644,
> .proc_handler = proc_doulongvec_minmax,
> },
>
> Reproduce:
> When passing two parameters, it's work normal. But passing
> only one parameter, an error "Invalid argument"(EINVAL) is
> returned.
>
> [root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
> [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
> 1 2
> [root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
> -bash: echo: write error: Invalid argument
> [root@cl150 ~]# echo $?
> 1
> [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
> 3 2
> [root@cl150 ~]#
>
> The following is the result after apply this patch. No error
> is returned when the number of input parameters is less than
> the total parameters.
>
> [root@cl150 ~]# echo 1 2 > /proc/sys/kernel/monitor_signals
> [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
> 1 2
> [root@cl150 ~]# echo 3 > /proc/sys/kernel/monitor_signals
> [root@cl150 ~]# echo $?
> 0
> [root@cl150 ~]# cat /proc/sys/kernel/monitor_signals
> 3 2
> [root@cl150 ~]#
>
> There are three processing functions dealing with digital parameters,
> __do_proc_dointvec/__do_proc_douintvec/__do_proc_doulongvec_minmax.
>
> This patch deals with __do_proc_doulongvec_minmax, just as
> __do_proc_dointvec does, adding a check for parameters 'left'. In
> __do_proc_douintvec, its code implementation explicitly does not
> support multiple inputs.
>
> static int __do_proc_douintvec(...){
> ...
> /*
> * Arrays are not supported, keep this simple. *Do not* add
> * support for them.
> */
> if (vleft != 1) {
> *lenp = 0;
> return -EINVAL;
> }
> ...
> }
>
> So, just __do_proc_doulongvec_minmax has the problem. And most use of
> proc_doulongvec_minmax/proc_doulongvec_ms_jiffies_minmax just have one
> parameter.
>
> Signed-off-by: Cheng Lin
Thanks for fixing up the commit log.
Acked-by: Luis Chamberlain
I think we can live with this outside of stable. So stable is not
needed. But I would not be surprised if autosel algorithm will end
up picking it up. And if so.. well, it cannot hurt.
Luis
RE: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
> From: Oleg Nesterov [mailto:o...@redhat.com] > Sent: Wednesday, December 05, 2018 11:36 PM > To: Ingo Molnar > Cc: Linus Torvalds; Linux List Kernel Mailing; Rafael J. Wysocki; Chanho Min; > Thomas Gleixner; Peter Zijlstra; Pavel Machek; Michal Hocko > Subject: Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux > 4.20-rc4) > > Ingo, et al, > > Sorry, I am sick and can't participate this discussion right now, > > On 12/04, Ingo Molnar wrote: > > > > * Oleg Nesterov wrote: > > > > > we really need to narrow the (huge) scope of ->cred_guard_mutex in exec > paths. > > > > > > my attempt to fix this was nacked, and nobody suggested a better solution > so far. > > > > Any link to your patch and the NAK? > > See https://lore.kernel.org/lkml/20170213141452.ga30...@redhat.com/ > > No questions, the patch wasn't pretty. And imo we need to rework the security > hooks in the long term. > > Oleg. I am sorry for the reverting this patch. It's also my fault that I didn't check lockdep. But, We decided to keep this patch in our product. Freeze fail is a real problem we've had for the last two years, whereas lockdep's notice is not a real problem. We hope this issue will be resolved soon. Special thanks to Oleg, Chanho
Re: [PATCH] Revert "firmware: dmi_scan: Use lowercase letters for UUID"
On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote: > This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7. > > The output of dmi_save_uuid() is exposed to user space as > /sys/devices/virtual/dmi/id/*_uuid, so this breaks backwards compatibility, > E.G. I have systems that include the content of dmi/id/product_uuid as part > of the keyphrase for cryptsetup luksOpen. > > As the change was purely cosmetical, revert it to fix such breakage. The change is not "cosmetical". The change was done to comply with RFC 4122: https://tools.ietf.org/html/rfc4122 The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input. If "cryptsetup luksOpen" does not lowercase digits before computing its key passphrase, then it's not RFC 4122-compliant and should be fixed. > Signed-off-by: Peter Korsgaard > --- > drivers/firmware/dmi_scan.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c > index 099d83e4e910..2ed51651565f 100644 > --- a/drivers/firmware/dmi_scan.c > +++ b/drivers/firmware/dmi_scan.c > @@ -211,9 +211,9 @@ static void __init dmi_save_uuid(const struct dmi_header > *dm, int slot, >* says that this is the defacto standard. >*/ > if (dmi_ver >= 0x020600) > - sprintf(s, "%pUl", d); > + sprintf(s, "%pUL", d); > else > - sprintf(s, "%pUb", d); > + sprintf(s, "%pUB", d); > > dmi_ident[slot] = s; > } Nak. This is too late. Changing it again would just add confusion. -- Jean Delvare SUSE L3 Support
Re: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
Hi! > > On 12/04, Ingo Molnar wrote: > > > > > > * Oleg Nesterov wrote: > > > > > > > we really need to narrow the (huge) scope of ->cred_guard_mutex in exec > > paths. > > > > > > > > my attempt to fix this was nacked, and nobody suggested a better > > > > solution > > so far. > > > > > > Any link to your patch and the NAK? > > > > See https://lore.kernel.org/lkml/20170213141452.ga30...@redhat.com/ > > > > No questions, the patch wasn't pretty. And imo we need to rework the > > security > > hooks in the long term. > > > > Oleg. > > I am sorry for the reverting this patch. It's also my fault that > I didn't check lockdep. But, We decided to keep this patch in our product. > Freeze fail is a real problem we've had for the last two years, > whereas lockdep's notice is not a real problem. > We hope this issue will be resolved soon. I guess it makes sense for your usage. How often do you see the failures without the patch? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 0/5 v7] Keep rtsx_usb suspended when there's no card
On Fri, 23 Nov 2018 at 13:21, Ulf Hansson wrote: > > On Fri, 23 Nov 2018 at 07:06, Kai Heng Feng > wrote: > > > > Hi Ulf, > > > > > On Nov 8, 2018, at 8:17 PM, Oleksandr Natalenko > > > wrote: > > > > > >> This is based on Ulf's work [1] [2]. > > >> This patch series can keep rtsx_usb suspended, to save ~0.5W on Intel > > >> platforms and ~1.5W on AMD platforms. > > >> [1] https://patchwork.kernel.org/patch/10440583/ > > >> [2] https://patchwork.kernel.org/patch/10445725/ > > > > > > Tested-by: Oleksandr Natalenko > > > > Do you think this series is ready to be merged to v4.20? > > I have had a brief look at the latest version a while ago, looked > good. However, allow a few more days before I can give it my final > blessing. > > BTW. We need to figure out what path to route the changes through. I > can pick it via my mmc tree, unless someone object to that. Okay, so I have picked up the patches and applied them to my next branch to my mmc tree. While doing that, I have also added Oleksandr's tested-by tag for all patches, including the four mmc patches. I also added your tested-by tags to the the four mmc patches. Finally I made little cosmetic change to last patch in this series, which was dropping the surrounding #ifdef CONFIG_PM while do the assignment of .driver.pm to &rtsx_usb_ms_pm_ops, as that isn't needed. If anybody have any objections, please tell me. Kind regards Uffe
Re: [PATCH 06/15 v3] regulator: max8973: Let core handle GPIO descriptor
On Wed, Dec 5, 2018 at 4:33 PM Charles Keepax wrote: > On Wed, Dec 05, 2018 at 03:42:06PM +0100, Linus Walleij wrote: > > On Wed, Dec 5, 2018 at 2:43 PM Charles Keepax > > wrote: > > > On Wed, Dec 05, 2018 at 01:47:12PM +0100, Linus Walleij wrote: > > > > @@ -775,10 +779,13 @@ static int max8973_probe(struct i2c_client > > > > *client, > > > > /* > > > >* We do not let the core switch this regulator on/off, > > > >* we just leave it on. > > > > + * > > > > + * Do not use devm* here: the regulator core takes over > > > > the > > > > + * lifecycle management of the GPIO descriptor. > > > >*/ > > > > - gpiod = devm_gpiod_get_optional(&client->dev, > > > > - "maxim,enable", > > > > - GPIOD_OUT_HIGH); > > > > + gpiod = gpiod_get_optional(&client->dev, > > > > +"maxim,enable", > > > > +GPIOD_OUT_HIGH); > > > > > > My comment on v2 still stands here, the GPIO is not passed to > > > the regulator core on this path. > > > > Patch 01 should take care of that, did you check it? > > Yeah, patch 1 makes the regulator core consistently handle GPIOs > that are passed into it. Sorry. I confused this patch for the max77686 patch. That one was fixed with patch 01... > However, on the MAX77621 path in this > switch statement the GPIO is never passed into the regulator > core, so the core never takes ownership of it, so the driver still > needs to manage the lifetime. > > It should be a pretty easy fix though as commented on v2, again > apologies for the slow review. OK I switch it to devm_ as you suggested, as we implemented gpiod_unhinge it's a piece of cake nowadays. Thanks a lot! Linus Walleij
KMSAN: kernel-infoleak in __kvm_write_guest_page
Hello, syzbot found the following crash on: HEAD commit:6f0597832d81 kmsan: unpoison data passed to skb_put_xxx() .. git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=10b6da5d40 kernel config: https://syzkaller.appspot.com/x/.config?x=9b071100dcf8e641 dashboard link: https://syzkaller.appspot.com/bug?extid=af22f34edec5361fb143 compiler: clang version 8.0.0 (trunk 348261) 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+af22f34edec5361fb...@syzkaller.appspotmail.com == BUG: KMSAN: kernel-infoleak in __copy_to_user include/linux/uaccess.h:121 [inline] BUG: KMSAN: kernel-infoleak in __kvm_write_guest_page+0x2cc/0x4a0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1855 CPU: 1 PID: 17704 Comm: syz-executor1 Not tainted 4.20.0-rc5+ #107 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x32d/0x480 lib/dump_stack.c:113 kmsan_report+0x12d/0x290 mm/kmsan/kmsan.c:683 kmsan_internal_check_memory+0x9ce/0xa50 mm/kmsan/kmsan.c:769 kmsan_copy_to_user+0x8d/0xa0 mm/kmsan/kmsan_hooks.c:634 __copy_to_user include/linux/uaccess.h:121 [inline] __kvm_write_guest_page+0x2cc/0x4a0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1855 kvm_vcpu_write_guest_page+0x196/0x1e0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1876 nested_release_vmcs12 arch/x86/kvm/vmx.c:8489 [inline] handle_vmptrld+0x1613/0x1750 arch/x86/kvm/vmx.c:9328 vmx_handle_exit+0x213b/0xb920 arch/x86/kvm/vmx.c:10632 vcpu_enter_guest arch/x86/kvm/x86.c:7811 [inline] vcpu_run arch/x86/kvm/x86.c:7874 [inline] kvm_arch_vcpu_ioctl_run+0xa551/0x11150 arch/x86/kvm/x86.c:8074 kvm_vcpu_ioctl+0x1098/0x1e30 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2596 do_vfs_ioctl+0xf36/0x2d30 fs/ioctl.c:46 ksys_ioctl fs/ioctl.c:713 [inline] __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718 __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718 do_syscall_64+0xcd/0x110 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x457569 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f0d0d3f0c78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00457569 RDX: RSI: ae80 RDI: 0006 RBP: 0072c040 R08: R09: R10: R11: 0246 R12: 7f0d0d3f16d4 R13: 004c034e R14: 004d0bc0 R15: Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline] kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:169 kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186 kmem_cache_alloc_trace+0x6b7/0xe20 mm/slub.c:2789 kmalloc include/linux/slab.h:546 [inline] enter_vmx_operation+0x105/0xe10 arch/x86/kvm/vmx.c:8315 vmx_set_nested_state+0xdc9/0x18a0 arch/x86/kvm/vmx.c:14922 kvm_arch_vcpu_ioctl+0x4d99/0x7370 arch/x86/kvm/x86.c:4190 kvm_vcpu_ioctl+0xcf3/0x1e30 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 do_vfs_ioctl+0xf36/0x2d30 fs/ioctl.c:46 ksys_ioctl fs/ioctl.c:713 [inline] __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718 __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718 do_syscall_64+0xcd/0x110 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 Bytes 1000-4095 of 4096 are uninitialized Memory access of size 4096 starts at 8881147db000 Data copied to user address 20feb000 == --- 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.
[PATCH] omfs: Use kmemdup instead of duplicating its function
kmemdup has implemented the function that kmalloc() + memcpy().
We prefer to kmemdup rather than code opened implementation.
This issue was detected with the help of coccinelle.
Signed-off-by: Wen Yang
CC: Bob Copeland
CC: linux-karma-de...@lists.sourceforge.net
CC: linux-kernel@vger.kernel.org
---
fs/omfs/inode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
index e5258fefcd2b..195c6baa3c8e 100644
--- a/fs/omfs/inode.c
+++ b/fs/omfs/inode.c
@@ -363,12 +363,11 @@ static int omfs_get_imap(struct super_block *sb)
bh = sb_bread(sb, block++);
if (!bh)
goto nomem_free;
- *ptr = kmalloc(sb->s_blocksize, GFP_KERNEL);
+ *ptr = kmemdup(bh->b_data, sb->s_blocksize, GFP_KERNEL);
if (!*ptr) {
brelse(bh);
goto nomem_free;
}
- memcpy(*ptr, bh->b_data, sb->s_blocksize);
if (count < sb->s_blocksize)
memset((void *)*ptr + count, 0xff,
sb->s_blocksize - count);
--
2.19.1
Re: [PATCH 0/4] soc: renesas: rcar-sysc: Miscellaneous fixes and cleanups
On Wed, Dec 5, 2018 at 4:39 PM Geert Uytterhoeven
wrote:
> This series (against renesas-devel-20181204-v4.20-rc5) contains
> miscellaneous fixes and cleanups for the R-Car SYSC driver.
>
> This has been tested on R-Car Gen2 (H2 and M2-W) and R-Car Gen3 (H3
> ES1.0, H3 ES2.0, M3-W, M3-N, D3, E3, and V3M) (without 3DG).
>
> This not been tested on R-Car H1 and R-Car V3H.
Now tested on R-Car H1 (Marzen), with no ill effects on secondary CPU
boot and CPU hotplug.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
On 05.12.18 17:57, Michal Hocko wrote:
> On Wed 05-12-18 13:29:18, Michal Hocko wrote:
> [...]
>> After some more thinking I am not really sure the above reasoning is
>> still true with the current upstream kernel. Maybe I just managed to
>> confuse myself so please hold off on this patch for now. Testing by
>> Oscar has shown this patch is helping but the changelog might need to be
>> updated.
>
> OK, so Oscar has nailed it down and it seems that 4.4 kernel we have
> been debugging on behaves slightly different. The underlying problem is
> the same though. So I have reworded the changelog and added "just in
> case" PageLRU handling. Naoya, maybe you have an argument that would
> make this void for current upstream kernels.
>
> I have dropped all the reviewed tags as the patch has changed slightly.
> Thanks a lot to Oscar for his patience and testing he has devoted to
> this issue.
>
> Btw. the way how we drop all the work on the first page that we cannot
> isolate is just goofy. Why don't we simply migrate all that we already
> have on the list and go on? Something for a followup cleanup though.
> ---
> From 909521051f41ae46a841b481acaf1ed9c695ae7b Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Mon, 3 Dec 2018 10:27:18 +0100
> Subject: [PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be
> offlined
>
> We have received a bug report that an injected MCE about faulty memory
> prevents memory offline to succeed on 4.4 base kernel. The underlying
> reason was that the HWPoison page has an elevated reference count and
> the migration keeps failing. There are two problems with that. First
> of all it is dubious to migrate the poisoned page because we know that
> accessing that memory is possible to fail. Secondly it doesn't make any
> sense to migrate a potentially broken content and preserve the memory
> corruption over to a new location.
>
> Oscar has found out that 4.4 and the current upstream kernels behave
> slightly differently with his simply testcase
> ===
>
> int main(void)
> {
> int ret;
> int i;
> int fd;
> char *array = malloc(4096);
> char *array_locked = malloc(4096);
>
> fd = open("/tmp/data", O_RDONLY);
> read(fd, array, 4095);
>
> for (i = 0; i < 4096; i++)
> array_locked[i] = 'd';
>
> ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked),
> sizeof(array_locked));
> if (ret)
> perror("mlock");
>
> sleep (20);
>
> ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096,
> MADV_HWPOISON);
> if (ret)
> perror("madvise");
>
> for (i = 0; i < 4096; i++)
> array_locked[i] = 'd';
>
> return 0;
> }
> ===
>
> + offline this memory.
>
> In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU
> list
> kernel: [] dump_trace+0x59/0x340
> kernel: [] show_stack_log_lvl+0xea/0x170
> kernel: [] show_stack+0x21/0x40
> kernel: [] dump_stack+0x5c/0x7c
> kernel: [] warn_slowpath_common+0x81/0xb0
> kernel: [] __pagevec_lru_add_fn+0x14c/0x160
> kernel: [] pagevec_lru_move_fn+0xad/0x100
> kernel: [] __lru_cache_add+0x6c/0xb0
> kernel: [] add_to_page_cache_lru+0x46/0x70
> kernel: [] extent_readpages+0xc3/0x1a0 [btrfs]
> kernel: [] __do_page_cache_readahead+0x177/0x200
> kernel: [] ondemand_readahead+0x168/0x2a0
> kernel: [] generic_file_read_iter+0x41f/0x660
> kernel: [] __vfs_read+0xcd/0x140
> kernel: [] vfs_read+0x7a/0x120
> kernel: [] kernel_read+0x3b/0x50
> kernel: [] do_execveat_common.isra.29+0x490/0x6f0
> kernel: [] do_execve+0x28/0x30
> kernel: [] call_usermodehelper_exec_async+0xfb/0x130
> kernel: [] ret_from_fork+0x55/0x80
>
> And that later confuses the hotremove path because an LRU page is
> attempted to be migrated and that fails due to an elevated reference
> count. It is quite possible that the reuse of the HWPoisoned page is
> some kind of fixed race condition but I am not really sure about that.
>
> With the upstream kernel the failure is slightly different. The page
> doesn't seem to have LRU bit set but isolate_movable_page simply fails
> and do_migrate_range simply puts all the isolated pages back to LRU and
> therefore no progress is made and scan_movable_pages finds same set of
> pages over and over again.
>
> Fix both cases by explicitly checking HWPoisoned pages before we even
> try to get a reference on the page, try to unmap it if it is still
> mapped. As explained by Naoya
> : Hwpoison code never unmapped those for no big reason because
> : Ksm pages never dominate memory, so we simply didn't have strong
> : motivation to save the pages.
>
> Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU
> HWPoison pages which shouldn't happen but I couldn't convince myself
> about that.
>
> Debugged-by: Oscar Salvador
> Cc: stable
> Signed-off-by: Michal Hocko
> ---
> mm/memory_hotplug.c | 16
ASSIST ME TO GET THESE FUNDS PLEASE
Good day dear friend, Let me start by introducing myself. I am Bartholomew Caleb, an accounts officer with Bank of Africa here in Burkina Faso West Africa. I am writing you this letter based on the latest development at my bank whichI will like to bring to your personal edification. ($9million) transfer claim into your bank account. Pleaded,I need your help here, do reply for more details on how we are going to proceed if you are intrested in this grateful oppurtunity. Get back to me at my private email address at, drbartholomewcale...@gmail.com Please note is strictly confidential. Thanks, Dr Bartholomew Caleb, +226 633 82 485.
RE: [PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
> > > > I am sorry for the reverting this patch. It's also my fault that > > I didn't check lockdep. But, We decided to keep this patch in our product. > > Freeze fail is a real problem we've had for the last two years, > > whereas lockdep's notice is not a real problem. > > We hope this issue will be resolved soon. > > I guess it makes sense for your usage. > > How often do you see the failures without the patch? Very rare, it happens about 1 in 1000 suspends. Chanho,
Re: [PATCH v4 0/4] Add support of STM32 hwspinlock
Le jeu. 6 déc. 2018 à 02:12, Bjorn Andersson a écrit : > > On Fri 30 Nov 06:45 PST 2018, Benjamin Gaignard wrote: > > > Le mer. 14 nov. 2018 ą 10:00, Benjamin Gaignard > > a écrit : > > > > > > This serie adds the support of the hardware semaphore block for stm32mp1 > > > SoC. > > > > > > version 4: > > > - add Linaro SoB > > > > Gentle ping on this series > > > > Sorry about that Benjamin, I was convinced that I picked your patches > already. Applied first two patches to hwspinlock tree. Thanks. > > I expect the dts update to go through the ST tree, and I guess the > complaint from 0day tells us they already are? Yes I will send fixed dts patches for stm32 tree > > Regards, > Bjorn
Re: [RFC/RFT][PATCH v6] cpuidle: New timer events oriented governor for tickless systems
On Thu, Dec 6, 2018 at 12:06 AM Doug Smythies wrote: > > On 2018.12.03 03:48 Rafael J. Wysocki wrote: > > >>> There is an additional issue where if idle state 0 is disabled (with the > >>> above suggested code patch), > >>> idle state usage seems to fall to deeper states than idle state 1. > >>> This is not the expected behaviour. > >> > >> No, it isn't. > >> > >>> Kernel 4.20-rc3 works as expected. > >>> I have not figured this issue out yet, in the code. > >>> > >>> Example (1 minute per sample. Number of entries/exits per state): > >>> State 0 State 1 State 2 State 3 State 4Watts > >>>28235143, 83, 26, 17,837, 64.900 > >>> 5583238, 657079,5884941,8498552, 30986831, 62.433 << > >>> Transition sample, after idle state 0 disabled > >>> 0, 793517,7186099, 10559878, 38485721, 61.900 << > >>> ?? should have all gone into Idle state 1 > >>> 0, 795414,7340703, 10553117, 38513456, 62.050 > >>> 0, 807028,7288195, 10574113, 38523524, 62.167 > >>> 0, 814983,7403534, 10575108, 38571228, 62.167 > >>> 0, 838302,7747127, 10552289, 38556054, 62.183 > >>> 9664999, 544473,4914512,6942037, 25295361, 63.633 << > >>> Transition sample, after idle state 0 enabled > >>>27893504, 96, 40, 9,912, 66.500 > >>>26556343, 83, 29, 7,814, 66.683 > >>>27929227, 64, 20, 10,931, 66.683 > >> > >> I see. > >> > >> OK, I'll look into this too, thanks! > > > > This probably is the artifact of the fix for the teo_find_shallower_state() > > issue. > > > > Anyway, I'm not able to reproduce this with the teo_find_shallower_state() > > issue > > fixed differently. > > I am not able to reproduce with your teo_find_shallower_state(), or teo V 7, > either. Everything is graceful now, as states are disabled: > (10 seconds per sample. Number of entries/exits per state): > > State 0 State 1 State 2 State 3 State 4Watts > 0, 6, 4, 1,414, 3.700 > 2, 4, 30, 3,578, 3.700 << No > load > 168619, 37, 39, 4,480, 5.600 << > Transition sample > 4643618, 45, 8, 1,137, 61.200 << All > idle states enabled > 4736227, 40, 3, 5,111, 61.800 > 1888417,4369314, 25, 2, 89, 62.000 << > Transition sample > 0,7266864, 9, 0, 0, 62.200 << > state 0 disabled > 0,7193372, 9, 0, 0, 62.700 > 0,5539898,1744007, 0, 0, 63.500 << > Transition sample > 0, 0,8152956, 0, 0, 63.700 << > states 0,1 disabled > 0, 0,8015151, 0, 0, 63.900 > 0, 0,4146806,6349619, 0, 63.000 << > Transition sample > 0, 0, 0, 13252144, 0, 61.600 << > states 0,1,2 disabled > 0, 0, 0, 13258313, 0, 61.800 > 0, 0, 0, 10417428,1984451, 61.200 << > Transition sample > 0, 0, 0, 0,9247172, 58.500 << > states 0,1,2,3 disabled > 0, 0, 0, 0,9242657, 58.500 > 0, 0, 0, 0,9233749, 58.600 > 0, 0, 0, 0,9238444, 58.700 > 0, 0, 0, 0,9236345, 58.600 > > For reference, this is kernel 4.20-rc5 (with your other proposed patches): > > State 0 State 1 State 2 State 3 State 4Watts > 0, 4, 8, 6,426, 3.700 > 1592870,279,149, 96,831, 21.800 > 5071279,154, 25, 6,105, 61.200 > 5095090, 78, 21, 1, 86, 61.800 > 5001493, 94, 30, 4,101, 62.200 > 616019,5446924, 5, 3, 38, 62.500 > 0,6249752, 0, 0, 0, 63.300 > 0,6293671, 0, 0, 0, 63.800 > 0,3751035,2529964, 0, 0, 64.100 > 0, 0,6101167, 0, 0, 64.500 > 0, 0,6172526, 0, 0, 64.700 > 0, 0,6163797, 0, 0, 64.900 > 0, 0,1724841,9567528, 0, 63.300 > 0, 0, 0, 13349668, 0,
[PATCH 2/2] staging: iio: adc: ad7192: Add clock output option
When using the internal clock the device has an option in which the clock
output is available on MCLK2 pin. This patch adds a dt binding for enabling
this property.
Signed-off-by: Mircea Caprioru
---
drivers/staging/iio/adc/ad7192.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 8a4e6ede42b3..a11c8a82bb7c 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -611,6 +611,10 @@ static const struct iio_chan_spec ad7193_channels[] = {
static int ad7192_clock_select(struct spi_device *spi, struct ad7192_state *st)
{
int ret;
+ bool clock_out_en;
+
+ clock_out_en = of_property_read_bool(spi->dev.of_node,
+"adi,int-clock-output-enable");
st->clock_sel = AD7192_CLK_EXT_MCLK2;
st->mclk = devm_clk_get(&spi->dev, "clk");
@@ -626,7 +630,10 @@ static int ad7192_clock_select(struct spi_device *spi,
struct ad7192_state *st)
return PTR_ERR(st->mclk);
/* use internal clock */
- st->clock_sel = AD7192_CLK_INT;
+ if (!clock_out_en)
+ st->clock_sel = AD7192_CLK_INT;
+ else
+ st->clock_sel = AD7192_CLK_INT_CO;
st->fclk = AD7192_INT_FREQ_MHZ;
}
}
--
2.17.1
[PATCH 1/2] staging: iio: adc: ad7192: Add clock for external clock reference
This patch adds a clock to the state structure of ad7192 for getting the
external clock frequency. This modifications is in accordance with clock
framework dt bindings documentation.
Signed-off-by: Mircea Caprioru
---
drivers/staging/iio/adc/ad7192.c | 74 +---
drivers/staging/iio/adc/ad7192.h | 2 -
2 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index acdbc07fd259..8a4e6ede42b3 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -6,6 +6,7 @@
* Licensed under the GPL-2.
*/
+#include
#include
#include
#include
@@ -156,8 +157,9 @@
struct ad7192_state {
struct regulator*avdd;
struct regulator*dvdd;
+ struct clk *mclk;
u16 int_vref_mv;
- u32 mclk;
+ u32 fclk;
u32 f_order;
u32 mode;
u32 conf;
@@ -165,6 +167,7 @@ struct ad7192_state {
u8 gpocon;
u8 devid;
struct mutexlock; /* protect sensor state */
+ u8 clock_sel;
struct ad_sigma_delta sd;
};
@@ -250,28 +253,8 @@ static int ad7192_setup(struct ad7192_state *st,
dev_warn(&st->sd.spi->dev, "device ID query failed (0x%X)\n",
id);
- switch (pdata->clock_source_sel) {
- case AD7192_CLK_INT:
- case AD7192_CLK_INT_CO:
- st->mclk = AD7192_INT_FREQ_MHZ;
- break;
- case AD7192_CLK_EXT_MCLK1_2:
- case AD7192_CLK_EXT_MCLK2:
- if (ad7192_valid_external_frequency(pdata->ext_clk_hz)) {
- st->mclk = pdata->ext_clk_hz;
- break;
- }
- dev_err(&st->sd.spi->dev, "Invalid frequency setting %u\n",
- pdata->ext_clk_hz);
- ret = -EINVAL;
- goto out;
- default:
- ret = -EINVAL;
- goto out;
- }
-
st->mode = AD7192_MODE_SEL(AD7192_MODE_IDLE) |
- AD7192_MODE_CLKSRC(pdata->clock_source_sel) |
+ AD7192_MODE_CLKSRC(st->clock_sel) |
AD7192_MODE_RATE(480);
st->conf = AD7192_CONF_GAIN(0);
@@ -499,7 +482,7 @@ static int ad7192_read_raw(struct iio_dev *indio_dev,
*val -= 273 * ad7192_get_temp_scale(unipolar);
return IIO_VAL_INT;
case IIO_CHAN_INFO_SAMP_FREQ:
- *val = st->mclk /
+ *val = st->fclk /
(st->f_order * 1024 * AD7192_MODE_RATE(st->mode));
return IIO_VAL_INT;
}
@@ -546,7 +529,7 @@ static int ad7192_write_raw(struct iio_dev *indio_dev,
break;
}
- div = st->mclk / (val * st->f_order * 1024);
+ div = st->fclk / (val * st->f_order * 1024);
if (div < 1 || div > 1023) {
ret = -EINVAL;
break;
@@ -625,6 +608,42 @@ static const struct iio_chan_spec ad7193_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(14),
};
+static int ad7192_clock_select(struct spi_device *spi, struct ad7192_state *st)
+{
+ int ret;
+
+ st->clock_sel = AD7192_CLK_EXT_MCLK2;
+ st->mclk = devm_clk_get(&spi->dev, "clk");
+ if (IS_ERR(st->mclk)) {
+ if (PTR_ERR(st->mclk) != -ENOENT)
+ return PTR_ERR(st->mclk);
+
+ /* try xtal option */
+ st->mclk = devm_clk_get(&spi->dev, "xtal");
+ st->clock_sel = AD7192_CLK_EXT_MCLK1_2;
+ if (IS_ERR(st->mclk)) {
+ if (PTR_ERR(st->mclk) != -ENOENT)
+ return PTR_ERR(st->mclk);
+
+ /* use internal clock */
+ st->clock_sel = AD7192_CLK_INT;
+ st->fclk = AD7192_INT_FREQ_MHZ;
+ }
+ }
+ if (st->clock_sel == AD7192_CLK_EXT_MCLK2 ||
+ st->clock_sel == AD7192_CLK_EXT_MCLK1_2) {
+ ret = clk_prepare_enable(st->mclk);
+ if (ret < 0)
+ return ret;
+
+ st->fclk = clk_get_rate(st->mclk);
+ if (!ad7192_valid_external_frequency(st->fclk))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int ad7192_probe(struct spi_device *spi)
{
const struct ad7192_platform_data *pdata = dev_get_platdata(&spi->dev);
@@ -672,6 +691,10 @@ static int ad7192_probe(struct spi_device *spi)
goto error_disable_avdd;
}
+ ret = ad7192
[PATCH] thermal: stm32: read factory settings properly
Call stm_thermal_read_factory_settings once
internal peripheral is properly clocked.
To avoid wrong initialization of fmt0
(stm_thermal_sensor struct) member add
brackets properly.
Change-Id: I150d00fd50e382df04bfad12f0653b1ed6a1db1b
Signed-off-by: David Hernandez Sanchez
diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
index 47623da..bbd73c5 100644
--- a/drivers/thermal/st/stm_thermal.c
+++ b/drivers/thermal/st/stm_thermal.c
@@ -241,8 +241,8 @@ static int stm_thermal_read_factory_settings(struct
stm_thermal_sensor *sensor)
sensor->t0 = TS1_T0_VAL1;
/* Retrieve fmt0 and put it on Hz */
- sensor->fmt0 = ADJUST * readl_relaxed(sensor->base + DTS_T0VALR1_OFFSET)
- & TS1_FMT0_MASK;
+ sensor->fmt0 = ADJUST * (readl_relaxed(sensor->base +
+DTS_T0VALR1_OFFSET) & TS1_FMT0_MASK);
/* Retrieve ramp coefficient */
sensor->ramp_coeff = readl_relaxed(sensor->base + DTS_RAMPVALR_OFFSET) &
@@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor
*sensor)
if (ret)
return ret;
+ ret = stm_thermal_read_factory_settings(sensor);
+ if (ret)
+ goto thermal_unprepare;
+
ret = stm_thermal_calibration(sensor);
if (ret)
goto thermal_unprepare;
@@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device *pdev)
/* Populate sensor */
sensor->base = base;
- ret = stm_thermal_read_factory_settings(sensor);
- if (ret)
- return ret;
-
sensor->clk = devm_clk_get(&pdev->dev, "pclk");
if (IS_ERR(sensor->clk)) {
dev_err(&pdev->dev, "%s: failed to fetch PCLK clock\n",
--
2.7.4
MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression)
On Wed 05-12-18 16:58:02, Linus Torvalds wrote: [...] > I realize that we probably do want to just have explicit policies that > do not exist right now, but what are (a) sane defaults, and (b) sane > policies? I would focus on the current default first (which is defrag=madvise). This means that we only try the cheapest possible THP without MADV_HUGEPAGE. If there is none we simply fallback. We do restrict to the local node. I guess there is a general agreement that this is a sane default. MADV_HUGEPAGE changes the picture because the caller expressed a need for THP and is willing to go extra mile to get it. That involves allocation latency and as of now also a potential remote access. We do not have complete agreement on the later but the prevailing argument is that any strong NUMA locality is just reinventing node-reclaim story again or makes THP success rate down the toilet (to quote Mel). I agree that we do not want to fallback to a remote node overeagerly. I believe that something like the below would be sensible 1) THP on a local node with compaction not giving up too early 2) THP on a remote node in NOWAIT mode - so no direct compaction/reclaim (trigger kswapd/kcompactd only for defrag=defer+madvise) 3) fallback to the base page allocation This would allow both full memory utilization and try to be as local as possible. Whoever strongly prefers NUMA locality should be using MPOL_NODE_RECLAIM (or similar) and that would skip 2 and make 1) and 2) use more aggressive compaction and reclaim. This will also fit into our existing NUMA api. MPOL_NODE_RECLAIM wouldn't be restricted to THP obviously. It would act on base pages as well and it would basically use the same implementation as we have for the global node_reclaim and make it usable again. Does this sound at least remotely sane? -- Michal Hocko SUSE Labs
Re: [PATCH v10 21/27] drivers: firmware: psci: Add a helper to attach a CPU to its PM domain
On Tue, 4 Dec 2018 at 19:45, Lina Iyer wrote:
>
> On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
> >Introduce a new PSCI DT helper function, psci_dt_attach_cpu(), which takes
> >a CPU number as an in-parameter and attaches the CPU's struct device to its
> >corresponding PM domain. Additionally, the helper prepares the CPU to be
> >power managed via runtime PM, which is the last step needed to enable the
> >interaction with the PM domain through the runtime PM callbacks.
> >
> >Signed-off-by: Ulf Hansson
> >---
> >
> >Changes in v10:
> > - New patch: Replaces "PM / Domains: Add helper functions to
> > attach/detach CPUs to/from genpd".
> >
> >---
> > drivers/firmware/psci/psci.h | 1 +
> > drivers/firmware/psci/psci_pm_domain.c | 19 +++
> > 2 files changed, 20 insertions(+)
> >
> >diff --git a/drivers/firmware/psci/psci.h b/drivers/firmware/psci/psci.h
> >index 05af462cc96e..fbc9980dee69 100644
> >--- a/drivers/firmware/psci/psci.h
> >+++ b/drivers/firmware/psci/psci.h
> >@@ -15,6 +15,7 @@ int psci_dt_parse_state_node(struct device_node *np, u32
> >*state);
> > int psci_dt_init_pm_domains(struct device_node *np);
> > int psci_dt_pm_domains_parse_states(struct cpuidle_driver *drv,
> > struct device_node *cpu_node, u32 *psci_states);
> >+int psci_dt_attach_cpu(int cpu);
> > #else
> > static inline int psci_dt_init_pm_domains(struct device_node *np) { return
> > 0; }
> > #endif
> >diff --git a/drivers/firmware/psci/psci_pm_domain.c
> >b/drivers/firmware/psci/psci_pm_domain.c
> >index 6c9d6a644c7f..b0fa7da8a0ce 100644
> >--- a/drivers/firmware/psci/psci_pm_domain.c
> >+++ b/drivers/firmware/psci/psci_pm_domain.c
> >@@ -12,8 +12,10 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> > #include
> >+#include
> > #include
> > #include
> >
> >@@ -367,4 +369,21 @@ int psci_dt_pm_domains_parse_states(struct
> >cpuidle_driver *drv,
> >
> > return 0;
> > }
> >+
> >+int psci_dt_attach_cpu(int cpu)
> >+{
> >+ struct device *dev = get_cpu_device(cpu);
> >+ int ret;
> >+
> >+ ret = dev_pm_domain_attach(dev, true);
> >+ if (ret)
> >+ return ret;
> >+
> >+ pm_runtime_irq_safe(dev);
> >+ pm_runtime_get_noresume(dev);
> >+ pm_runtime_set_active(dev);
> You would want to set this only if the CPU is online. Otherwise we will
> not power down the domain, if the CPU was never brought online.
Nice catch!
The platforms I tested this series on brings all their CPUs online
during boot, hence I haven't observed the problem.
I will post a new version soon to address the problem. Again, thanks
for your review!
[...]
Kind regards
Uffe
Re: [RFC PATCH] hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined
On Thu, Dec 06, 2018 at 09:32:06AM +0100, Michal Hocko wrote:
> On Thu 06-12-18 05:21:38, Naoya Horiguchi wrote:
> > On Wed, Dec 05, 2018 at 05:57:16PM +0100, Michal Hocko wrote:
> > > On Wed 05-12-18 13:29:18, Michal Hocko wrote:
> > > [...]
> > > > After some more thinking I am not really sure the above reasoning is
> > > > still true with the current upstream kernel. Maybe I just managed to
> > > > confuse myself so please hold off on this patch for now. Testing by
> > > > Oscar has shown this patch is helping but the changelog might need to be
> > > > updated.
> > >
> > > OK, so Oscar has nailed it down and it seems that 4.4 kernel we have
> > > been debugging on behaves slightly different. The underlying problem is
> > > the same though. So I have reworded the changelog and added "just in
> > > case" PageLRU handling. Naoya, maybe you have an argument that would
> > > make this void for current upstream kernels.
> >
> > The following commit (not in 4.4.x stable tree) might explain the
> > difference you experienced:
> >
> > commit 286c469a988fbaf68e3a97ddf1e6c245c1446968
> > Author: Naoya Horiguchi
> > Date: Wed May 3 14:56:22 2017 -0700
> >
> > mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page
> >
> > This commit adds shake_page() for mlocked pages to make sure that the target
> > page is flushed out from LRU cache. Without this shake_page(), subsequent
> > delete_from_lru_cache() (from me_pagecache_clean()) fails to isolate it and
> > the page will finally return back to LRU list. So this scenario leads to
> > "hwpoisoned by still linked to LRU list" page.
>
> OK, I see. So does that mean that the LRU handling is no longer needed
> and there is a guanratee that all kernels with the above commit cannot
> ever get an LRU page?
Theoretically no such gurantee, because try_to_unmap() doesn't have a
guarantee of success and then memory_failure() returns immediately
when hwpoison_user_mappings fails.
Or the following code (comes after hwpoison_user_mappings block) also implies
that the target page can still have PageLRU flag.
/*
* Torn down by someone else?
*/
if (PageLRU(p) && !PageSwapCache(p) && p->mapping == NULL) {
action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED);
res = -EBUSY;
goto out;
}
So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in
current version of your patch.
Feel free to add my ack.
Acked-by: Naoya Horiguchi
Thanks,
Naoya Horiguchi
Re: [PATCH v14 04/11] livepatch: Refuse to unload only livepatches available during a forced transition
On Thu, 6 Dec 2018, Petr Mladek wrote: > On Mon 2018-12-03 16:29:32, Miroslav Benes wrote: > > You probably forgot to replace the subject with Josh's proposal. > > > > > module_put() is currently never called in klp_complete_transition() when > > > klp_force is set. As a result, we might keep the reference count even when > > > klp_enable_patch() fails and klp_cancel_transition() is called. > > > > Correct. > > > > > This might make an assumption that a module might get blocked in some > > > strange init state. Fortunately, it is not the case. The reference count > > > is ignored when mod->init fails and erroneous modules are always removed. > > > > I do not understand the paragraph and its connection to the problem (and I > > don't > > remember if I understood it previously or not and forgot to mention it). > > It was one example of the confusion. I wonder if the following text > is more clear: > > One might wonder if the reference could block the module in > MODULE_STATE_COMING or MODULE_STATE_GOING infinitely. > Fortunately, it is not the case. The reference count is > ignored when mod->init fails and erroneous modules are > always removed. > > Or I could remove the paragraph as you suggested below. I think Joe's proposal would suffice. s/make an assumption/give the impression/. It confused me. Thanks, Miroslav
Re: [PATCH] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3
Hi All,
On 2018-12-06 09:25, Marek Szyprowski wrote:
> On 2018-12-05 17:11, Anand Moon wrote:
>> On Wed, 5 Dec 2018 at 19:36, Krzysztof Kozlowski wrote:
>>> On Tue, 4 Dec 2018 at 20:40, Anand Moon wrote:
Add suspend-to-mem node to regulator core to be enabled or disabled
during system suspend and also support changing the regulator operating
mode during runtime and when the system enter sleep mode.
Signed-off-by: Anand Moon
---
Tested on Odroid U3+
...
>> Well I have tested this patch as following
>> with only one issue, before enable suspend number of On-line cpu is 4
>> after resume number of On-line cpu is 1.
> This seems to be a regression in v4.20-rc1, not related to dts changes
> at all. I'm investigating this now...
Okay, I mixed kernel versions a bit. To be precise, this regression is
between v4.20-rc2 and v4.20-rc3. Bisecting pointed commit 383fb3ee8024
("ARM: spectre-v2: per-CPU vtables to work around big.Little systems").
I will post a bug report about the regression.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH][misc-next] misc: cardreader: fix spelling mistake "invailid" -> "invalid"
From: Colin Ian King
There are spelling mistakes in a couple of dev_dbg messages, fix these.
Signed-off-by: Colin Ian King
---
drivers/misc/cardreader/alcor_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cardreader/alcor_pci.c
b/drivers/misc/cardreader/alcor_pci.c
index 6872b8e29b4d..bcb10fa4bc3a 100644
--- a/drivers/misc/cardreader/alcor_pci.c
+++ b/drivers/misc/cardreader/alcor_pci.c
@@ -105,7 +105,7 @@ static int alcor_pci_find_cap_offset(struct alcor_pci_priv
*priv,
while (1) {
pci_read_config_dword(pci, where, &val32);
if (val32 == 0x) {
- dev_dbg(priv->dev, "find_cap_offset invailid value
%x.\n",
+ dev_dbg(priv->dev, "find_cap_offset invalid value
%x.\n",
val32);
return 0;
}
@@ -116,7 +116,7 @@ static int alcor_pci_find_cap_offset(struct alcor_pci_priv
*priv,
}
if ((val32 & 0xff00) == 0x00) {
- dev_dbg(priv->dev, "pci_find_cap_offset invailid value
%x.\n",
+ dev_dbg(priv->dev, "pci_find_cap_offset invalid value
%x.\n",
val32);
break;
}
--
2.19.1
Re: [PATCH] Revert "firmware: dmi_scan: Use lowercase letters for UUID"
> "Jean" == Jean Delvare writes: > On Wed, 2018-12-05 at 22:13 +0100, Peter Korsgaard wrote: >> This reverts commit 712ff25450bd01366301eef81c33e865d901e7b7. >> >> The output of dmi_save_uuid() is exposed to user space as >> /sys/devices/virtual/dmi/id/*_uuid, so this breaks backwards compatibility, >> E.G. I have systems that include the content of dmi/id/product_uuid as part >> of the keyphrase for cryptsetup luksOpen. >> >> As the change was purely cosmetical, revert it to fix such breakage. > The change is not "cosmetical". The change was done to comply with RFC > 4122: > https://tools.ietf.org/html/rfc4122 > The hexadecimal values "a" through "f" are output as > lower case characters and are case insensitive on input. I get that - but it changes the content of sysfs entries, breaking real systems - E.G. a user space ABI regression. It is a cosmetic code change in the sense that no known software was broken with the upper case characters. > If "cryptsetup luksOpen" does not lowercase digits before computing its > key passphrase, then it's not RFC 4122-compliant and should be fixed. cryptsetup naturally doesn't know anything about RFC 4122. It just reads a disk encryption keyphrase which happen to include the content of id/product_uuid because of my scripts. > Nak. This is too late. Changing it again would just add confusion. Please reconsider. 4.17 is from June, and 4.19 has only recently become LTS. -- Bye, Peter Korsgaard
Re: [PATCH v5 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
Hi Yogesh, I've had a closer look at your v5. See my comments below. On 16.11.18 12:13, Yogesh Narayan Gaur wrote: > - Add driver for NXP FlexSPI host controller > > (0) What is the FlexSPI controller? > FlexSPI is a flexsible SPI host controller which supports two SPI > channels and up to 4 external devices. Each channel supports > Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional > data lines) i.e. FlexSPI acts as an interface to external devices, > maximum 4, each with up to 8 bidirectional data lines. > > It uses new SPI memory interface of the SPI framework to issue > flash memory operations to up to four connected flash > devices (2 buses with 2 CS each). > > (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility > on NXP LX2160ARDB and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512ab, [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Signed-off-by: Yogesh Gaur > --- > Changes for v5: > - Rebase on top of v4.20-rc2 > - Modified fspi_readl_poll_tout() as per review comments > - Arrange header file in alphabetical order > - Removed usage of read()/write() function callback pointer > - Add support for 1 and 2 byte address length > - Change Frieder e-mail to new e-mail address > Changes for v4: > - Incorporate Boris review comments >* Use readl_poll_timeout() instead of busy looping. >* Re-define register masking as per comment. >* Drop fspi_devtype enum. > Changes for v3: > - Added endianness flag in platform specific structure instead of DTS. > - Modified nxp_fspi_read_ahb(), removed remapping code. > - Added Boris and Frieder as Author and provided reference of spi-fsl-qspi.c > Changes for v2: > - Incorporated Boris review comments. > - Remove dependency of driver over connected flash device size. > - Modified the logic to select requested CS. > - Remove SPI-Octal Macros. > > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile |1 + > drivers/spi/spi-nxp-fspi.c | 1145 > > 3 files changed, 1156 insertions(+) > create mode 100644 drivers/spi/spi-nxp-fspi.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 7d3a5c9..36630a1 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -259,6 +259,16 @@ config SPI_FSL_LPSPI > help > This enables Freescale i.MX LPSPI controllers in master mode. > > +config SPI_NXP_FLEXSPI > + tristate "NXP Flex SPI controller" > + depends on ARCH_LAYERSCAPE || HAS_IOMEM > + help > + This enables support for the Flex SPI controller in master mode. > + Up to four slave devices can be connected on two buses with two > + chipselects each. > + This controller does not support generic SPI messages and only > + supports the high-level SPI memory interface. > + > config SPI_GPIO > tristate "GPIO-based bitbanging SPI Master" > depends on GPIOLIB || COMPILE_TEST > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 3575205..55fec5c 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -60,6 +60,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o > obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > obj-$(CONFIG_SPI_MXS) += spi-mxs.o > obj-$(CONFIG_SPI_NUC900)+= spi-nuc900.o > +obj-$(CONFIG_SPI_NXP_FLEXSPI)+= spi-nxp-fspi.o > obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o > spi-octeon-objs := spi-cavium.o > spi-cavium-octeon.o > obj-$(CONFIG_SPI_OCTEON)+= spi-octeon.o > diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c > new file mode 100644 > index 000..a35013b > --- /dev/null > +++ b/drivers/spi/spi-nxp-fspi.c > @@ -0,0 +1,1145 @@ > +// SPDX-License-Identifier: GPL-2.0+ > + > +/* > + * NXP FlexSPI(FSPI) controller driver. > + * > + * Copyright 2018 NXP. > + * > + * FlexSPI is a flexsible SPI host controller which supports two SPI > + * channels and up to 4 external devices. Each channel supports > + * Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional > + * data lines). > + * > + * FlexSPI controller is driven by the LUT(Look-up Table) registers > + * LUT registers are a look-up-table for sequences of instructions. > + * A valid sequence consists of four LUT registers. > + * Maximum 32 LUT sequences can be programmed simultaneously. > + * > + * LUTs are being created at run-time based on the commands passed > + * from the spi-mem framework, thus using single LUT index. > + * > + * Software triggered Flash read/write access by IP Bus. > + * > + * Memory mapp
Re: [PATCH v14 05/11] livepatch: Simplify API by removing registration step
On Thu, 6 Dec 2018, Petr Mladek wrote: > On Wed 2018-12-05 14:32:53, Joe Lawrence wrote: > > > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > > > index 972520144713..e01dfa3b58d2 100644 > > > --- a/kernel/livepatch/core.c > > > +++ b/kernel/livepatch/core.c > > > @@ -45,7 +45,7 @@ > > > */ > > > DEFINE_MUTEX(klp_mutex); > > > > > > -/* Registered patches */ > > > +/* Actively used patches. */ > > > LIST_HEAD(klp_patches); > > > > By itself, this comment makes me wonder if there are un-active and/or > > un-used patches that I need to worry about. After this patchset, > > klp_patches will include patches that have been enabled and those that > > have been replaced, but the replacement transition is still in progress. > > > > If that sounds accurate, how about adding to the comment: > > > > /* Actively used patches: enabled or replaced and awaiting transition */ > > The replaced patches are not in the list. This is why I used the word > "actively". The replaced patches are removed in klp_discard_replaced_patches(), which is called from klp_complete_transition(). Joe is right. The patches are in the list if a transition is still in progress. Miroslav > /* > * Actively used patches: enabled or in transition. Note that replaced > * or disabled patches are not listed even though the related kernel > * module still can be loaded. > */
[PATCH][next] mmc: sdhci-of-esdhc: fix spelling mistake "upsupported" -> "unsupported"
From: Colin Ian King
There is a spelling mistake in a pr_warn message, fix it.
Signed-off-by: Colin Ian King
---
drivers/mmc/host/sdhci-of-esdhc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 856e809f38b7..e21e90f81bbd 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -597,7 +597,7 @@ static void esdhc_of_set_clock(struct sdhci_host *host,
unsigned int clock)
pre_div = 4;
div = 3;
} else {
- pr_warn("%s: using upsupported clock division.\n",
+ pr_warn("%s: using unsupported clock division.\n",
mmc_hostname(host->mmc));
}
}
--
2.19.1
Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
On Thu, Dec 6, 2018 at 9:36 AM Martin Kepplinger wrote: > > On 06.12.18 00:03, Peter Hutterer wrote: > > ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of > > ffe0e7cf290f5c9 when the high-resolution scrolling code was removed. > > > > Signed-off-by: Peter Hutterer > > Reviewed-by: Martin Kepplinger Acked-by: Benjamin Tissoires Dmitry, I do not think this one will conflict with the high res wheel patches, so I think it should be safe to take it through your tree. If you think it'll be an issue, I can also take it through the HID one. Cheers, Benjamin
Re: dmapool regression in next
On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote:
>
> Hi,
>
> Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability
> of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)"
> on at least omap4 pandaboard, see below.
>
> Any ideas what might be going wrong?
>
> Regards,
>
> Tony
>
> 8< -
> omap-dma-engine 4a056000.dma-controller: dma_pool_free
> 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe80
> omap-dma-engine 4a056000.dma-controller: dma_pool_free
> 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe80001c
> omap-dma-engine 4a056000.dma-controller: dma_pool_free
> 4a056000.dma-controller, (ptrval) (bad vaddr)/0xbe800038
> ...
I see it as well on all my Exynos boards, since yesterday's next. In
my case it is the USB EHCI driver:
exynos-ehci 1211.usb: dma_pool_free ehci_qtd, (ptrval) (bad
vaddr)/0xb8844180
Full log here:
https://krzk.eu/#/builders/1/builds/2937/steps/12/logs/serial0
Best regards,
Krzysztof
[PATCH] mmc: sdhci: fix the timeout check window for clock and reset
From: Alek Du
We observed some premature timeouts on a virtualization platform, the log
is like this:
case 1:
[159525.255629] mmc1: Internal clock never stabilised.
[159525.255818] mmc1: sdhci: SDHCI REGISTER DUMP ===
[159525.256049] mmc1: sdhci: Sys addr: 0x | Version: 0x1002
...
[159525.257205] mmc1: sdhci: Wake-up: 0x | Clock:0xfa03
>From the clock control register dump, we are pretty sure the clock was
stablized.
case 2:
[ 914.550127] mmc1: Reset 0x2 never completed.
[ 914.550321] mmc1: sdhci: SDHCI REGISTER DUMP ===
[ 914.550608] mmc1: sdhci: Sys addr: 0x0010 | Version: 0x1002
After checking the sdhci code, we found the timeout check actually has a
little window that the CPU can be scheduled out and when it comes back,
the original time set or check is not valid.
Fixes: 5a436cc0af62 ("mmc: sdhci: Optimize delay loops")
Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Alek Du
---
drivers/mmc/host/sdhci.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 99bdae53fa2e..451b08a818a9 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -216,8 +216,12 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
timeout = ktime_add_ms(ktime_get(), 100);
/* hw clears the bit when it's done */
- while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
- if (ktime_after(ktime_get(), timeout)) {
+ while (1) {
+ bool timedout = ktime_after(ktime_get(), timeout);
+
+ if (!(sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask))
+ break;
+ if (timedout) {
pr_err("%s: Reset 0x%x never completed.\n",
mmc_hostname(host->mmc), (int)mask);
sdhci_dumpregs(host);
@@ -1608,9 +1612,13 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
/* Wait max 20 ms */
timeout = ktime_add_ms(ktime_get(), 20);
- while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
- & SDHCI_CLOCK_INT_STABLE)) {
- if (ktime_after(ktime_get(), timeout)) {
+ while (1) {
+ bool timedout = ktime_after(ktime_get(), timeout);
+
+ clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
+ if (clk & SDHCI_CLOCK_INT_STABLE)
+ break;
+ if (timedout) {
pr_err("%s: Internal clock never stabilised.\n",
mmc_hostname(host->mmc));
sdhci_dumpregs(host);
--
2.17.1
Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression
On 12/6/18 1:54 AM, Andrea Arcangeli wrote: > On Wed, Dec 05, 2018 at 04:18:14PM -0800, David Rientjes wrote: >> On Wed, 5 Dec 2018, Andrea Arcangeli wrote: >> >> Note that in addition to COMPACT_SKIPPED that you mention, compaction can >> fail with COMPACT_COMPLETE, meaning the full scan has finished without >> freeing a hugepage, or COMPACT_DEFERRED, meaning that doing another scan >> is unlikely to produce a different result. COMPACT_SKIPPED makes sense to >> do reclaim if it can become accessible to isolate_freepages() and >> hopefully another allocator does not allocate from these newly freed pages >> before compaction can scan the zone again. For COMPACT_COMPLETE and >> COMPACT_DEFERRED, reclaim is unlikely to ever help. > > The COMPACT_COMPLETE and (COMPACT_PARTIAL_SKIPPED for that matter) > seems just a mistake in the max() evaluation try_to_compact_pages() > that let it return COMPACT_COMPLETE and COMPACT_PARTIAL_SKIPPED. I > think it should just return COMPACT_DEFERRED in those two cases and it > should be enforced forced for all prio. > > There are really only 3 cases that matter for the caller: > > 1) succeed -> we got the page > 2) defer -> we failed (caller won't care about why) > 3) skipped -> failed because not enough 4k freed -> reclaim must be invoked > then >compaction can be retried > > PARTIAL_SKIPPED/COMPLETE both fall into 2) above so for the caller > they should be treated the same way. It doesn't seem very concerning > that it may try like if it succeeded and do a spurious single reclaim > invocation, but it's good to fix this and take the COMPACT_DEFERRED > nopage path in the __GFP_NORETRY case. Yeah good point. I wouldn't change the general logic of try_to_compact_pages() though, but the condition for __GFP_NORETRY can simply change to: if (compact_result != COMPACT_SKIPPED) goto nopage; I can make a patch ASAP together with a few others I think are needed, that should hopefully avoid the need for __GFP_COMPACT_ONLY or checks based on order. What's probably unavoidable though is adding back __GFP_NORETRY for madvised allocations (i.e. partially reverting 2516035499b95), but David was fine with that and your __GFP_ONLY_COMPACT approach effectively did it too.
Re: [PATCH V3 rebase] mmc: sdhci: fix the timeout check window for clock and reset
On Thu, 6 Dec 2018 08:55:04 +0100 Ulf Hansson wrote: > Could you check at your side and see what can be wrong? If there is > too much hazzle I can manually fixup the patch next week, as one time > thing. Sorry for the confusion, I just resent with git send-email to avoid any thing unexpected. Please try again. > > Kind regards > Uffe >
Re: linux-next: Tree for Dec 6
Hi all, On Thu, 6 Dec 2018 19:18:51 +1100 Stephen Rothwell wrote: > > New trees: thunderbolt, thunderbolt-next Actually thunderbolt-fixes ... -- Cheers, Stephen Rothwell pgpxeS_sPCw8m.pgp Description: OpenPGP digital signature
Re: [PATCH v14 00/11] livepatch: Atomic replace feature
> > I don't have many code comments as the changes appear to safely and > > correctly do what the say. (We are at v14 after all :) I mainly > > compared the text and comments to the implementation and noted typos > > (marked by substitution s/old/new) and awkward wordings (marked by > > "re-wording suggestion"). That said, I ack'd each patch as I wouldn't > > want these to hold up the patchset. > > Thanks a lot both you and Miroslav for the review. > > I'll give it some more days before I prepare v15. I wonder if Josh > could find some cycle to look at it at least from the top level. For what is worth, I'm fine with all the changes Joe proposed and you can preserve my acks there. Miroslav
RE: [RFC PATCH v2 04/15] usb:cdns3: Driver initialization code.
Hi,
>On 04/12/18 10:50, Peter Chen wrote:
+ * Cadence USBSS DRD Driver.
+ *
+ * Copyright (C) 2018 Cadence.
+ *
+ * Author: Peter Chen
+ * Pawel Laszczak
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "gadget.h"
+#include "core.h"
+
+static inline struct cdns3_role_driver
*cdns3_get_current_role_driver(struct cdns3 *cdns)
+{
+ WARN_ON(cdns->role >= CDNS3_ROLE_END || !cdns->roles[cdns->role]);
+ return cdns->roles[cdns->role];
+}
+
+static inline int cdns3_role_start(struct cdns3 *cdns, enum cdns3_roles
role)
+{
+ int ret;
+
+ if (role >= CDNS3_ROLE_END)
>>>
>>> WARN_ON()?
>>>
+ return 0;
+
+ if (!cdns->roles[role])
+ return -ENXIO;
+
+ mutex_lock(&cdns->mutex);
+ cdns->role = role;
+ ret = cdns->roles[role]->start(cdns);
+ mutex_unlock(&cdns->mutex);
+ return ret;
+}
+
+static inline void cdns3_role_stop(struct cdns3 *cdns)
+{
+ enum cdns3_roles role = cdns->role;
+
+ if (role == CDNS3_ROLE_END)
>>>
>>> WARN_ON(role >= CNDS3_ROLE_END) ?
>>>
+ return;
+
+ mutex_lock(&cdns->mutex);
+ cdns->roles[role]->stop(cdns);
+ cdns->role = CDNS3_ROLE_END;
>>>
>>> Why change the role here? You are just stopping the role not changing it.
>>> I think cdns->role should remain unchanged, so we can call
>>> cdns3_role_start()
>>> if required without error.
>>>
>>
>> The current version of this IP has some issues to detect vbus status
>> correctly,
>> we have to force vbus status accordingly, so we need a status to indicate
>> vbus disconnection, and add some code to let controller know vbus
>> removal, in that case, the controller's state machine can be correct.
>> So, we increase one role 'CDNS3_ROLE_END' to for this purpose.
>>
>> CDNS3_ROLE_GADGET: gadget mode and VBUS on
>> CDNS3_ROLE_HOST: host mode and VBUS on
>> CDNS3_ROLE_END: VBUS off, eg either host or device cable on the port.
>>
>> So, we may start role from CDNS3_ROLE_END at probe when nothing is connected,
>> and need to set role as CDNS3_ROLE_END at ->stop for further handling at
>> role switch routine.
>
>OK. but still this (changing to ROLE_END) must be moved to the role switch
>routine
>and the explanation you just mentioned must be added there.
>
>>
+ mutex_unlock(&cdns->mutex);
+}
+
+static enum cdns3_roles cdns3_get_role(struct cdns3 *cdns)
+{
+ if (cdns->roles[CDNS3_ROLE_HOST] && cdns->roles[CDNS3_ROLE_GADGET]) {
+ //TODO: implements selecting device/host mode
+ return CDNS3_ROLE_HOST;
+ }
+ return cdns->roles[CDNS3_ROLE_HOST]
+ ? CDNS3_ROLE_HOST
+ : CDNS3_ROLE_GADGET;
>>>
>>> Why not just
>>> return cdns->role;
>>>
>>> I'm wondering if we really need this function.
>>
>> cdns->role gets from cdns3_get_role, and this API tells role at the runtime.
>> If both roles are supported, the role is decided by external
>> conditions, eg, vbus/id
>> or external connector. If only single role is supported, only one role
>> structure
>> is allocated, cdns->roles[CDNS3_ROLE_HOST] or cdns->roles[CDNS3_ROLE_GADGET]
>>
>
>How about adding this description in function documentation.
Ok, I will do it.
>
+}
>>>
+
+/**
+ * cdns3_core_init_role - initialize role of operation
+ * @cdns: Pointer to cdns3 structure
+ *
+ * Returns 0 on success otherwise negative errno
+ */
+static int cdns3_core_init_role(struct cdns3 *cdns)
+{
+ struct device *dev = cdns->dev;
+ enum usb_dr_mode dr_mode;
+
+ dr_mode = usb_get_dr_mode(dev);
+ cdns->role = CDNS3_ROLE_END;
+
+ /*
+ * If driver can't read mode by means of usb_get_dr_mdoe function
then
+ * chooses mode according with Kernel configuration. This setting
+ * can be restricted later depending on strap pin configuration.
+ */
+ if (dr_mode == USB_DR_MODE_UNKNOWN) {
+ if (IS_ENABLED(CONFIG_USB_CDNS3_HOST) &&
+ IS_ENABLED(CONFIG_USB_CDNS3_GADGET))
+ dr_mode = USB_DR_MODE_OTG;
+ else if (IS_ENABLED(CONFIG_USB_CDNS3_HOST))
+ dr_mode = USB_DR_MODE_HOST;
+ else if (IS_ENABLED(CONFIG_USB_CDNS3_GADGET))
+ dr_mode = USB_DR_MODE_PERIPHERAL;
+ }
+
+ if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
+ //TODO: implements host initialization
>>>
>>> /* TODO: Add host role */ ?
>>>
+ }
+
+ if (dr_mode == USB_DR_MODE_O
Re: KMSAN: kernel-infoleak in __kvm_write_guest_page
On Thu, Dec 6, 2018 at 10:01 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:6f0597832d81 kmsan: unpoison data passed to skb_put_xxx() .. > git tree: https://github.com/google/kmsan.git/master > console output: https://syzkaller.appspot.com/x/log.txt?x=10b6da5d40 > kernel config: https://syzkaller.appspot.com/x/.config?x=9b071100dcf8e641 > dashboard link: https://syzkaller.appspot.com/bug?extid=af22f34edec5361fb143 > compiler: clang version 8.0.0 (trunk 348261) > > 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+af22f34edec5361fb...@syzkaller.appspotmail.com #syz dup: KMSAN: kernel-infoleak in kvm_vcpu_write_guest_page > == > BUG: KMSAN: kernel-infoleak in __copy_to_user include/linux/uaccess.h:121 > [inline] > BUG: KMSAN: kernel-infoleak in __kvm_write_guest_page+0x2cc/0x4a0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1855 > CPU: 1 PID: 17704 Comm: syz-executor1 Not tainted 4.20.0-rc5+ #107 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x32d/0x480 lib/dump_stack.c:113 > kmsan_report+0x12d/0x290 mm/kmsan/kmsan.c:683 > kmsan_internal_check_memory+0x9ce/0xa50 mm/kmsan/kmsan.c:769 > kmsan_copy_to_user+0x8d/0xa0 mm/kmsan/kmsan_hooks.c:634 > __copy_to_user include/linux/uaccess.h:121 [inline] > __kvm_write_guest_page+0x2cc/0x4a0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1855 > kvm_vcpu_write_guest_page+0x196/0x1e0 > arch/x86/kvm/../../../virt/kvm/kvm_main.c:1876 > nested_release_vmcs12 arch/x86/kvm/vmx.c:8489 [inline] > handle_vmptrld+0x1613/0x1750 arch/x86/kvm/vmx.c:9328 > vmx_handle_exit+0x213b/0xb920 arch/x86/kvm/vmx.c:10632 > vcpu_enter_guest arch/x86/kvm/x86.c:7811 [inline] > vcpu_run arch/x86/kvm/x86.c:7874 [inline] > kvm_arch_vcpu_ioctl_run+0xa551/0x11150 arch/x86/kvm/x86.c:8074 > kvm_vcpu_ioctl+0x1098/0x1e30 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2596 > do_vfs_ioctl+0xf36/0x2d30 fs/ioctl.c:46 > ksys_ioctl fs/ioctl.c:713 [inline] > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718 > __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718 > do_syscall_64+0xcd/0x110 arch/x86/entry/common.c:291 > entry_SYSCALL_64_after_hwframe+0x63/0xe7 > RIP: 0033:0x457569 > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f0d0d3f0c78 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 0003 RCX: 00457569 > RDX: RSI: ae80 RDI: 0006 > RBP: 0072c040 R08: R09: > R10: R11: 0246 R12: 7f0d0d3f16d4 > R13: 004c034e R14: 004d0bc0 R15: > > Uninit was created at: > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline] > kmsan_internal_poison_shadow+0x92/0x150 mm/kmsan/kmsan.c:169 > kmsan_kmalloc+0xa1/0x100 mm/kmsan/kmsan_hooks.c:186 > kmem_cache_alloc_trace+0x6b7/0xe20 mm/slub.c:2789 > kmalloc include/linux/slab.h:546 [inline] > enter_vmx_operation+0x105/0xe10 arch/x86/kvm/vmx.c:8315 > vmx_set_nested_state+0xdc9/0x18a0 arch/x86/kvm/vmx.c:14922 > kvm_arch_vcpu_ioctl+0x4d99/0x7370 arch/x86/kvm/x86.c:4190 > kvm_vcpu_ioctl+0xcf3/0x1e30 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2748 > do_vfs_ioctl+0xf36/0x2d30 fs/ioctl.c:46 > ksys_ioctl fs/ioctl.c:713 [inline] > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718 > __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718 > do_syscall_64+0xcd/0x110 arch/x86/entry/common.c:291 > entry_SYSCALL_64_after_hwframe+0x63/0xe7 > > Bytes 1000-4095 of 4096 are uninitialized > Memory access of size 4096 starts at 8881147db000 > Data copied to user address 20feb000 > == > > > --- > 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. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/ff9610057c56bcd7%40google.com. > For more options, visit https://group
Re: [RFC] sched/fair: Align vruntime to last_se when curr_se's timeslice run out
On Wed, Dec 05, 2018 at 08:41:39PM +0800, weiqi (C) wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index ee271bb..1f61b9c 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4020,7 +4020,23 @@ static void clear_buddies(struct cfs_rq *cfs_rq,
> struct sched_entity *se)
> ideal_runtime = sched_slice(cfs_rq, curr);
> delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
> if (delta_exec > ideal_runtime) {
> + struct rb_node *next = NULL;
> + struct rb_node *right_most = NULL;
> + struct sched_entity *last;
> resched_curr(rq_of(cfs_rq));
> +
> +/* always set to max vruntime */
> +if (cfs_rq->nr_running > 1) {
> +next = &curr->run_node;
> +do {
> +right_most = next;
> +next = rb_next(next);
> +} while (next);
> +
> +last = rb_entry(right_most,
> + struct sched_entity, run_node);
This you can obviously do better by tracking max_vruntime along side
min_vruntime. But for testing this should work fine I suppose.
> +curr->vruntime = last->vruntime + 1; // maybe +1 is
> not needed
This however is completely broken... you've basically reduced a virtual
runtime scheduler to a simple RR one.
Yes, place_entity() is not ideal, for starters we should not insert
relative to min_vruntime but to the 0-lag point (weighted average
vruntime). And IIRC, we should not let negative lag tasks reduce the
runqueue weight.
But those things are computationally expensive to do, so we fudged it.
> +}
> +
> /*
> * The current task ran long enough, ensure it doesn't get
> * re-elected due to buddy favours.
[PATCH v2] thermal: tsens: qcom: do not create duplicate regmap debugfs entries
Regmap would use device name to create debugfs entries. If the device
has multiple regmaps it is recommended to use name field in regmap_config.
Fix this by providing name to the regmap configs correctly.
Without this patch we would see below error on DB820c.
qcom-tsens 4a9000.thermal-sensor: Failed to create 4a9000.thermal-sensor
debugfs directory
Signed-off-by: Srinivas Kandagatla
Acked-by: Amit Kucheria
Tested-by: Amit Kucheria
---
Changes since v1:
-rename tsens_config to tsens_tm_config as suggested by Amit.
drivers/thermal/qcom/tsens-common.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/qcom/tsens-common.c
b/drivers/thermal/qcom/tsens-common.c
index 3be4be2e0465..ddfdf88ffb4e 100644
--- a/drivers/thermal/qcom/tsens-common.c
+++ b/drivers/thermal/qcom/tsens-common.c
@@ -113,7 +113,15 @@ int get_temp_common(struct tsens_device *tmdev, int id,
int *temp)
return 0;
}
-static const struct regmap_config tsens_config = {
+static const struct regmap_config tsens_tm_config = {
+ .name = "tm",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static const struct regmap_config tsens_srot_config = {
+ .name = "srot",
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
@@ -139,8 +147,8 @@ int __init init_common(struct tsens_device *tmdev)
if (IS_ERR(srot_base))
return PTR_ERR(srot_base);
- tmdev->srot_map = devm_regmap_init_mmio(tmdev->dev,
- srot_base,
&tsens_config);
+ tmdev->srot_map = devm_regmap_init_mmio(tmdev->dev, srot_base,
+ &tsens_srot_config);
if (IS_ERR(tmdev->srot_map))
return PTR_ERR(tmdev->srot_map);
@@ -154,7 +162,8 @@ int __init init_common(struct tsens_device *tmdev)
if (IS_ERR(tm_base))
return PTR_ERR(tm_base);
- tmdev->tm_map = devm_regmap_init_mmio(tmdev->dev, tm_base,
&tsens_config);
+ tmdev->tm_map = devm_regmap_init_mmio(tmdev->dev, tm_base,
+&tsens_tm_config);
if (IS_ERR(tmdev->tm_map))
return PTR_ERR(tmdev->tm_map);
--
2.19.2
Re: [PATCH v2 1/3] PCI: imx: No-op imx6_setup_phy_mpll() on i.MX7D
Am Mittwoch, den 05.12.2018, 23:35 -0800 schrieb Andrey Smirnov:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6
> family,
> so none of the code in current implementation of
> imx6_setup_phy_mpll()
> is applicable.
>
> Cc: bhelg...@google.com
> Cc: Fabio Estevam
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez
> Cc: "A.s. Dong"
> Cc: Richard Zhu
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Tested-by: Trent Piepho
> Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 2cbef2d7c207..c140f7987598 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -525,6 +525,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie
> *imx6_pcie)
> int mult, div;
> u32 val;
>
> + if (imx6_pcie->variant == IMX7D)
> + return 0;
> +
> switch (phy_rate) {
> case 12500:
> /*
Re: [PATCH v2 2/3] PCI: imx: No-op imx6_pcie_reset_phy() on i.MX7D
Am Mittwoch, den 05.12.2018, 23:35 -0800 schrieb Andrey Smirnov:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> so none of the code in current implementation of imx6_pcie_reset_phy()
> is applicable.
>
> Cc: bhelg...@google.com
> > Cc: Fabio Estevam
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> > Cc: Leonard Crestez
> > Cc: "A.s. Dong"
> > Cc: Richard Zhu
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> > Tested-by: Trent Piepho
> Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index c140f7987598..3c3002861d25 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -245,6 +245,9 @@ static void imx6_pcie_reset_phy(struct imx6_pcie
> *imx6_pcie)
> {
> > u32 tmp;
>
> > + if (imx6_pcie->variant == IMX7D)
> > + return;
> +
> > pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, &tmp);
> > tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
> > PHY_RX_OVRD_IN_LO_RX_PLL_EN);
Re: [PATCH 2/2] staging: greybus: Added space between string concatenated
On 05/12/2018 21:00, Sicilia Cristian wrote: It doesn't change the result string So why do it then ?
Re: [PATCH] thermal: stm32: read factory settings properly
Hi David,
On 06/12/2018 10:12, David HERNANDEZ SANCHEZ wrote:
> Call stm_thermal_read_factory_settings once
> internal peripheral is properly clocked.
>
> To avoid wrong initialization of fmt0
> (stm_thermal_sensor struct) member add
> brackets properly.
>
> Change-Id: I150d00fd50e382df04bfad12f0653b1ed6a1db1b
Please do a cleanup of the log:
- line wrap at 72 characters
- No Change-Id
State the problem and then tell what you do to fix it.
For example, it is unclear what happens if the factory settings are read
before the clock is set.
The bracket change is not directly related to the clock ordering and it
should go in another patch.
In addition each patch is fixing something, in this case it is the
initial import, so each fixes should contain the tag:
Fixes: 1d693155 (thermal: add stm32 thermal driver)
> Signed-off-by: David Hernandez Sanchez
>
> diff --git a/drivers/thermal/st/stm_thermal.c
> b/drivers/thermal/st/stm_thermal.c
> index 47623da..bbd73c5 100644
> --- a/drivers/thermal/st/stm_thermal.c
> +++ b/drivers/thermal/st/stm_thermal.c
> @@ -241,8 +241,8 @@ static int stm_thermal_read_factory_settings(struct
> stm_thermal_sensor *sensor)
> sensor->t0 = TS1_T0_VAL1;
>
> /* Retrieve fmt0 and put it on Hz */
> - sensor->fmt0 = ADJUST * readl_relaxed(sensor->base + DTS_T0VALR1_OFFSET)
> - & TS1_FMT0_MASK;
> + sensor->fmt0 = ADJUST * (readl_relaxed(sensor->base +
> + DTS_T0VALR1_OFFSET) & TS1_FMT0_MASK);
>
> /* Retrieve ramp coefficient */
> sensor->ramp_coeff = readl_relaxed(sensor->base + DTS_RAMPVALR_OFFSET) &
> @@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor
> *sensor)
> if (ret)
> return ret;
>
> + ret = stm_thermal_read_factory_settings(sensor);
> + if (ret)
> + goto thermal_unprepare;
> +
> ret = stm_thermal_calibration(sensor);
> if (ret)
> goto thermal_unprepare;
> @@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device
> *pdev)
> /* Populate sensor */
> sensor->base = base;
>
> - ret = stm_thermal_read_factory_settings(sensor);
> - if (ret)
> - return ret;
> -
> sensor->clk = devm_clk_get(&pdev->dev, "pclk");
> if (IS_ERR(sensor->clk)) {
> dev_err(&pdev->dev, "%s: failed to fetch PCLK clock\n",
>
--
Facebook |
Twitter |
Re: [PATCH 2/6] __wr_after_init: write rare for static allocation
On Wed, Dec 05, 2018 at 03:13:56PM -0800, Andy Lutomirski wrote: > > + if (op == WR_MEMCPY) > > + memcpy((void *)wr_poking_addr, (void *)src, len); > > + else if (op == WR_MEMSET) > > + memset((u8 *)wr_poking_addr, (u8)src, len); > > + else if (op == WR_RCU_ASSIGN_PTR) > > + /* generic version of rcu_assign_pointer */ > > + smp_store_release((void **)wr_poking_addr, > > + RCU_INITIALIZER((void **)src)); > > + kasan_enable_current(); > > Hmm. I suspect this will explode quite badly on sane architectures > like s390. (In my book, despite how weird s390 is, it has a vastly > nicer model of "user" memory than any other architecture I know > of...). I think you should use copy_to_user(), etc, instead. I'm not > entirely sure what the best smp_store_release() replacement is. > Making this change may also mean you can get rid of the > kasan_disable_current(). If you make the MEMCPY one guarantee single-copy atomicity for native words then you're basically done. smp_store_release() can be implemented with: smp_mb(); WRITE_ONCE(); So if we make MEMCPY provide the WRITE_ONCE(), all we need is that barrier, which we can easily place at the call site and not overly complicate our interface with this. Because performance is down the drain already, an additional full memory barrier is peanuts here (and in fact already implied by the x86 CR3 munging).
Re: [PATCH v5 1/2] module: Overwrite st_size instead of st_info
On Tue, 4 Dec 2018, Vincent Whitchurch wrote: > st_info is currently overwritten after relocation and used to store the > elf_type(). However, we're going to need it fix kallsyms on ARM's > Thumb-2 kernels, so preserve st_info and overwrite the st_size field > instead. st_size is neither used by the module core nor by any > architecture. > > Reviewed-by: Dave Martin > Signed-off-by: Vincent Whitchurch Reviewed-by: Miroslav Benes M
[PATCH] gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB
If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return
the same type of error as regular version: NULL. All the callers
compare the return value of gpio_to_desc() against NULL, so returned
ERR_PTR would be treated as non-error case leading to dereferencing of
error value.
Fixes: 79a9becda894 ("gpiolib: export descriptor-based GPIO interface")
Cc:
Signed-off-by: Krzysztof Kozlowski
---
include/linux/gpio/consumer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index ed070512b40e..3b01fbcafc94 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -505,7 +505,7 @@ static inline int gpiod_set_consumer_name(struct gpio_desc
*desc,
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
- return ERR_PTR(-EINVAL);
+ return NULL;
}
static inline int desc_to_gpio(const struct gpio_desc *desc)
--
2.7.4
[PATCH] dt-bindings: i2c: use correct vendor prefix for atmel's at24 EEPROMs
This is a follow-up to Thierry's patch which missed a few occurences.
Cc: Thierry Reding
Signed-off-by: Bartosz Golaszewski
---
Documentation/devicetree/bindings/i2c/i2c-at91.txt| 2 +-
Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
index ef973a0343c7..b7cec17c3daf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
@@ -33,7 +33,7 @@ i2c0: i2c@fff84000 {
clock-frequency = <40>;
24c512@50 {
- compatible = "24c512";
+ compatible = "atmel,24c512";
reg = <0x50>;
pagesize = <128>;
}
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
index c661b9083ec6..8b1e49cdce3f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -54,7 +54,7 @@ Example:
reg = <1>;
eeprom@50 {
- compatible = "at,24c02";
+ compatible = "atmel,24c02";
reg = <0x50>;
};
};
--
2.19.1
[PATCH stable v4.4+ 2/3] leds: turn off the LED and wait for completion on unregistering LED class device
From: Milo Kim commit d1aa577f5e191d77d3ad62da93729b5af9532bb4 upstream. Workqueue, 'set_brightness_work' is used for scheduling brightness control. This workqueue is canceled when the LED class device is unregistered. Currently, LED subsystem handles like below. cancel_work_sync(&led_cdev->set_brightness_work) led_set_brightness(led_cdev, LED_OFF) However, this could be a problem. Workqueue is going to be canceled but LED device needs to be off. The worst case is null pointer access due to scheduling a workqueue. LED module is loaded. LED driver private data is allocated by using devm_zalloc(). LED module is unloaded. led_classdev_unregister() is called. cancel_work_sync() led_set_brightness(led_cdev, LED_OFF) schedule_work() if LED driver uses brightness_set_blocking() In the meantime, driver private data will be freed. ..scheduling.. brightness_set_blocking() callback is invoked. For the brightness control, LED driver tries to access private data but resource is removed! To avoid this problem, LED subsystem should turn off the brightness first and wait for completion. led_set_brightness(led_cdev, LED_OFF) flush_work(&led_cdev->set_brightness_work) It guarantees that LED driver turns off the brightness prior to resource management. Cc: linux-l...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim Signed-off-by: Jacek Anaszewski Signed-off-by: Krzysztof Kozlowski --- drivers/leds/led-class.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c index 7385f98dd54b..51a5b51ec467 100644 --- a/drivers/leds/led-class.c +++ b/drivers/leds/led-class.c @@ -247,12 +247,13 @@ void led_classdev_unregister(struct led_classdev *led_cdev) up_write(&led_cdev->trigger_lock); #endif - cancel_work_sync(&led_cdev->set_brightness_work); - /* Stop blinking */ led_stop_software_blink(led_cdev); + led_set_brightness(led_cdev, LED_OFF); + flush_work(&led_cdev->set_brightness_work); + device_unregister(led_cdev->dev); down_write(&leds_list_lock); -- 2.7.4
Re: [PATCH 2/4] power: reset: at91-poweroff: move shdwc related data to one structure
Hi Sebastian, On 06.12.2018 00:40, Sebastian Reichel wrote: > Hi, > > On Wed, Nov 07, 2018 at 06:23:40PM +0100, Alexandre Belloni wrote: >> On 07/11/2018 14:54:17+, claudiu.bez...@microchip.com wrote: >>> Hi Alexandre, >>> >>> On 06.11.2018 23:09, Alexandre Belloni wrote: Hi Claudiu, On 05/11/2018 11:14:26+, claudiu.bez...@microchip.com wrote: > static int __init at91_poweroff_probe(struct platform_device *pdev) > @@ -154,16 +160,22 @@ static int __init at91_poweroff_probe(struct > platform_device *pdev) > u32 ddr_type; > int ret; > > + at91_shdwc = devm_kzalloc(&pdev->dev, sizeof(*at91_shdwc), GFP_KERNEL); > + if (!at91_shdwc) > + return -ENOMEM; > + Is there any real benefit that will offset the time lost for that allocation at boot time? >>> >>> No, I haven't run benchmarks on this. I only wanted to have them grouped in >>> one structure. Please let me know if you have some tests in mind. >>> >> >> Well, it is probably not much but small things adds up. Having it as a >> global structure is probably good enough. > > I suppose I will get a new patch with this change? Yes, I will send a new version for this one. Thank you, Claudiu Beznea > > -- Sebastian > >> I understand you are then testing at91_shdwc to know whether the driver already probed once. But, the driver will never probe twice as there is only one shutdown controller on the SoC and anyway, If it was to probe twice, it will still work as expected. >>> >>> I had in mind the scenario where the driver would be compiled as module. I >>> know insmod already does this checking. I'm ok to remove this checking. I >>> will do it in next version. With this I will also remove devm_kzalloc() of >>> at91_shdwc. >>> >> >> Thanks, >> >> -- >> Alexandre Belloni, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com
COMPLIMENT OF THE SEASON,
Dear Friend, I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Gaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have an investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need an investment Manager/Partner and because of the asylum status i will authorize you the ownership of the funds, however, I am interested in you for investment project assistance in your country, may be from there, we can build a business relationship in the near future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated Please Reply me in my box. (mrs.aisha...@gmail.com) Best Regards Mrs Aisha Gaddafi
Re: [LKP] [x86/jump_table] b34006c425: BUG:unable_to_handle_kernel
On Thu, 6 Dec 2018 at 10:17, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: b34006c4258c9c86597b6b7123d6a9a3513d6cd7 ("x86/jump_table: Use
> relative references")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +--+++
> | | 9fc0f798ab | b34006c425 |
> +--+++
> | boot_successes | 4 | 0 |
> | boot_failures| 0 | 4 |
> | BUG:unable_to_handle_kernel | 0 | 4 |
> | Oops:#[##] | 0 | 4 |
> | RIP:memcmp | 0 | 4 |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 4 |
> +--+++
>
>From the attached log:
[0.00] Linux version 4.19.0-rc5-6-gb34006c
while
$ git tag --contains b34006c
v4.20-rc1
v4.20-rc2
v4.20-rc3
v4.20-rc4
v4.20-rc5
If this is reproducible on a clean rebuild of b34006c425, I'm happy to
look into it.
> [ 21.261613] BUG: unable to handle kernel paging request at 01001893
> [ 21.262316] PGD 0 P4D 0
> [ 21.262578] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
> [ 21.263139] CPU: 1 PID: 252 Comm: systemd-udevd Not tainted
> 4.19.0-rc5-6-gb34006c #1
> [ 21.263952] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 21.264797] RIP: 0010:memcmp+0x7/0x1d
> [ 21.265179] Code: 39 ca 75 e7 41 c6 41 01 00 c3 c3 48 01 fa 48 89 f8 48 39
> d0 74 0c 0f b6 08 39 f1 74 05 48 ff c0 eb ef c3 31 c9 48 39 d1 74 13 <0f> b6
> 04 0f 44 0f b6 04 0e 48 ff c1 44 29 c0 74 ea eb 02 31 c0 c3
> [ 21.267043] RSP: 0018:880110aebc50 EFLAGS: 00010293
> [ 21.267579] RAX: 8101b80d RBX: 01001893 RCX:
>
> [ 21.268299] RDX: 0005 RSI: 880110aebc6b RDI:
> 01001893
> [ 21.269015] RBP: 824019a4 R08: 0044 R09:
> 0008
> [ 21.269736] R10: 000701029ae0 R11: 82a42360 R12:
> 8101b80d
> [ 21.270458] R13: c90001029ae0 R14: c900010297e0 R15:
> c900010295e0
> [ 21.271185] FS: 7f22ad10e8c0() GS:88013b30()
> knlGS:
> [ 21.271989] CS: 0010 DS: ES: CR0: 80050033
> [ 21.272571] CR2: 01001893 CR3: 000110ae6000 CR4:
> 000406a0
> [ 21.273290] DR0: DR1: DR2:
>
> [ 21.274006] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 21.274724] Call Trace:
> [ 21.274993] __jump_label_transform+0xb6/0x11f
> [ 21.275455] jump_label_apply_nops+0x5d/0x72
> [ 21.275894] module_finalize+0x18d/0x1c3
> [ 21.276323] load_module+0x1800/0x236d
> [ 21.276710] ? vfs_read+0x108/0x116
> [ 21.277068] ? set_fs+0x9/0x20
> [ 21.277390] ? security_kernel_post_read_file+0x67/0x75
> [ 21.277916] ? allow_write_access+0x13/0x24
> [ 21.278346] ? kernel_read_file+0x1d3/0x1fa
> [ 21.278773] ? __do_sys_finit_module+0xae/0xd4
> [ 21.279238] __do_sys_finit_module+0xae/0xd4
> [ 21.279675] do_syscall_64+0x20f/0x224
> [ 21.280063] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 21.280602] RIP: 0033:0x7f22abf8b229
> [ 21.280970] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d 3f 4c 2b 00 f7 d8 64 89 01 48
> [ 21.282830] RSP: 002b:7fff5c9d38e8 EFLAGS: 0246 ORIG_RAX:
> 0139
> [ 21.283599] RAX: ffda RBX: 55e996bd96b0 RCX:
> 7f22abf8b229
> [ 21.284316] RDX: RSI: 7f22ac8a4265 RDI:
> 0007
> [ 21.285027] RBP: 7f22ac8a4265 R08: R09:
> 55e996bcd860
> [ 21.285743] R10: 0007 R11: 0246 R12:
>
> [ 21.286459] R13: 55e996bd04d0 R14: 0002 R15:
> 55e996439cbc
> [ 21.287186] Modules linked in: button(+) ip_tables x_tables ipv6
> [ 21.287800] CR2: 01001893
> Starting LSB: Execute the kexec -e command to reboot system...
> [ 21.346498] input: Power Button as
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
> [ 21.347338] evbug: Connected device: input4 (Power Button at
> LNXPWRBN/button/input0)
> [ 21.347665] ---[ end trace 3282d04b21b84631 ]---
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
Re: [PATCH 2/2] drm/ttm: Use pr_debug for all output from ttm_bo_evict
Am 06.12.18 um 10:39 schrieb Zhang, Jerry(Junwei): On 12/6/18 5:33 PM, Koenig, Christian wrote: Am 06.12.18 um 10:09 schrieb Michel Dänzer: On 2018-12-06 3:43 a.m., Zhang, Jerry(Junwei) wrote: On 12/6/18 12:56 AM, Michel Dänzer wrote: From: Michel Dänzer All the output is related, so it should all be printed the same way. Some of it was using pr_debug, but some of it appeared in dmesg by default. The caller should handle failure, so there's no need to spam dmesg with potentially quite a lot of output by default. Signed-off-by: Michel Dänzer Sounds reasonable, but personally prefer to show error when some vital incident happens, e.g. no memory on eviction. The amdgpu driver still prints these in that case: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* amdgpu_cs_list_validate(validated) failed. [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission! That's from cs submit, perhaps it may come from other places by ttm_bo_evict_mm(). Is that right? Christian. Yeah, exactly my thinking as well. When we silence the TTM messages we might miss those cases. Additional to that other drivers using TTM might not have those messages either. If TTM is to noisy we should use ratelimit and/or reduce the number and size of the warning messages. A simple "Warning, I ran out of memory during eviction!" should do. Regards, Christian. Regards, Jerry That's plenty as far as I'm concerned. :) Yeah, but in this case I would rather make the amdgpu messages debug level and leave the TTM meassages on error level. Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 10/24] arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking
On 05/12/18 18:26, Catalin Marinas wrote:
> On Wed, Dec 05, 2018 at 04:55:54PM +, Julien Thierry wrote:
>> On 04/12/18 17:36, Catalin Marinas wrote:
>>> On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
diff --git a/arch/arm64/include/asm/irqflags.h
b/arch/arm64/include/asm/irqflags.h
index 24692ed..e0a32e4 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -18,7 +18,27 @@
#ifdef __KERNEL__
+#include
+#include
#include
+#include
+
+
+/*
+ * When ICC_PMR_EL1 is used for interrupt masking, only the bit indicating
+ * whether the normal interrupts are masked is kept along with the daif
+ * flags.
+ */
+#define ARCH_FLAG_PMR_EN 0x1
+
+#define MAKE_ARCH_FLAGS(daif, pmr)
\
+ ((daif) | (((pmr) >> GIC_PRIO_STATUS_SHIFT) & ARCH_FLAG_PMR_EN))
+
+#define ARCH_FLAGS_GET_PMR(flags) \
+ flags) & ARCH_FLAG_PMR_EN) << GIC_PRIO_STATUS_SHIFT) \
+ | GIC_PRIO_IRQOFF)
+
+#define ARCH_FLAGS_GET_DAIF(flags) ((flags) & ~ARCH_FLAG_PMR_EN)
>>>
>>> I wonder whether we could just use the PSR_I_BIT here to decide whether
>>> to set the GIC_PRIO_IRQ{ON,OFF}. We could clear the PSR_I_BIT in
>>> _restore_daif() with an alternative.
>>
>> So, the issue with it is that some contexts might be using PSR.I to
>> disable interrupts (any contexts with async errors or debug exceptions
>> disabled, kvm guest entry paths, pseudo-NMIs, ...).
>>
>> If any of these contexts calls local_irq_save()/local_irq_restore() or
>> local_daif_save()/local_daif_restore(), by only relying on PSR_I_BIT to
>> represent the PMR status, we might end up clearing PSR.I when we shouldn't.
>>
>> I'm not sure whether there are no callers of these functions in those
>> context. But if that is the case, we could simplify things, yes.
>
> There are callers of local_daif_save() (3) and local_daif_mask() (7) but
> do they all need to disable the pseudo-NMIs?
>
Hmmm, I really think that both of those should be disabling NMIs.
Otherwise, if we take an NMI, the first thing the el1_irq handler is
going to do is "enable_da_f()" which could lead to potential issues.
One thing that could be done is:
- local_daif_save() and local_daif_mask() both mask all daif bits
(taking care to represent PMR value in the I bit of the saved flags)
- local_daif_restore() restores da_f as expected and decides values to
put for PMR and PSR.I as follows:
* do the da_f restore
* if PSR.A bit is cleared in the saved flags, then we also do a
start_nmi()
However, this would not work with a local_daif_save()/restore() on the
return path of an NMI because I think it is the only context with NMIs
"stopped" that can take aborts. I can add a WARN_ON(in_nmi()) for
local_daif_restore() if that doesn't affect performance too much.
Does that sound alright?
> At a brief look at x86, it seems that they have something like
> stop_nmi() and restart_nmi(). These don't have save/restore semantics,
> so we could do something similar on arm64 that only deals with the
> PSTATE.I bit directly and keep the software (flags) PSR.I as the PMR
> bit. But we'd have to go through the 10 local_daif_* cases above to see
> which actually need the stop_nmi() semantics.
>
Yes, having those could be useful to deal with the above and maybe some
other places.
Thanks,
--
Julien Thierry
Re: [PATCH v2 2/4] dmaengine: mtk_uart_dma: add Mediatek uart DMA support
On Wed, 2018-12-05 at 13:07 -0800, Sean Wang wrote:
> .
> On Wed, Dec 5, 2018 at 1:31 AM Long Cheng wrote:
> >
> > In DMA engine framework, add 8250 mtk dma to support it.
> >
> > Signed-off-by: Long Cheng
> > ---
> > drivers/dma/mediatek/8250_mtk_dma.c | 894
> > +++
> > drivers/dma/mediatek/Kconfig| 11 +
> > drivers/dma/mediatek/Makefile |1 +
> > 3 files changed, 906 insertions(+)
> > create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
> >
> > diff --git a/drivers/dma/mediatek/8250_mtk_dma.c
> > b/drivers/dma/mediatek/8250_mtk_dma.c
> > new file mode 100644
> > index 000..3454679
> > --- /dev/null
> > +++ b/drivers/dma/mediatek/8250_mtk_dma.c
> > @@ -0,0 +1,894 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mediatek 8250 DMA driver.
> > + *
> > + * Copyright (c) 2018 MediaTek Inc.
> > + * Author: Long Cheng
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "../virt-dma.h"
> > +
> > +#define MTK_APDMA_DEFAULT_REQUESTS 127
> > +#define MTK_APDMA_CHANNELS (CONFIG_SERIAL_8250_NR_UARTS * 2)
> > +
> > +#define VFF_EN_B BIT(0)
> > +#define VFF_STOP_B BIT(0)
> > +#define VFF_FLUSH_BBIT(0)
> > +#define VFF_4G_SUPPORT_B BIT(0)
> > +#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
> > +#define VFF_RX_INT_EN1_B BIT(1)
> > +#define VFF_TX_INT_EN_BBIT(0) /*tx left size >= vff thre*/
> > +#define VFF_WARM_RST_B BIT(0)
> > +#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
> > +#define VFF_TX_INT_FLAG_CLR_B 0
> > +#define VFF_STOP_CLR_B 0
> > +#define VFF_FLUSH_CLR_B0
> > +#define VFF_INT_EN_CLR_B 0
> > +#define VFF_4G_SUPPORT_CLR_B 0
> > +
> > +/* interrupt trigger level for tx */
> > +#define VFF_TX_THRE(n) ((n) * 7 / 8)
> > +/* interrupt trigger level for rx */
> > +#define VFF_RX_THRE(n) ((n) * 3 / 4)
> > +
> > +#define MTK_DMA_RING_SIZE 0xU
> > +/* invert this bit when wrap ring head again*/
> > +#define MTK_DMA_RING_WRAP 0x1U
> > +
> > +#define VFF_INT_FLAG 0x00
> > +#define VFF_INT_EN 0x04
> > +#define VFF_EN 0x08
> > +#define VFF_RST0x0c
> > +#define VFF_STOP 0x10
> > +#define VFF_FLUSH 0x14
> > +#define VFF_ADDR 0x1c
> > +#define VFF_LEN0x24
> > +#define VFF_THRE 0x28
> > +#define VFF_WPT0x2c
> > +#define VFF_RPT0x30
> > +/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
> > +#define VFF_VALID_SIZE 0x3c
> > +/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
> > +#define VFF_LEFT_SIZE 0x40
> > +#define VFF_DEBUG_STATUS 0x50
> > +#define VFF_4G_SUPPORT 0x54
> > +
> > +struct mtk_dmadev {
> > + struct dma_device ddev;
> > + void __iomem *mem_base[MTK_APDMA_CHANNELS];
> > + spinlock_t lock; /* dma dev lock */
> > + struct tasklet_struct task;
> > + struct list_head pending;
> > + struct clk *clk;
> > + unsigned int dma_requests;
> > + bool support_33bits;
> > + unsigned int dma_irq[MTK_APDMA_CHANNELS];
> > + struct mtk_chan *ch[MTK_APDMA_CHANNELS];
> > +};
> > +
> > +struct mtk_chan {
> > + struct virt_dma_chan vc;
> > + struct list_head node;
> > + struct dma_slave_config cfg;
> > + void __iomem *base;
> > + struct mtk_dma_desc *desc;
> > +
> > + bool stop;
> > + bool requested;
> > +
> > + unsigned int dma_sig;
>
> the member can be removed as no real user would refer to it
>
Ok, i will remove it at next patch
> > + unsigned int dma_ch;
>
> a chan_id is already included in struct dma_chan, we can reuse it
>
chan_id is start from 0. but in this driver, dma info is stored to list.
if use port1, in filter_fn function, will set dma_ch to 2, 3(tx, rx). So
can't using chan_id
> > + unsigned int sgidx;
>
> the member also can be removed as no real user would refer to it
>
Ok, i will remove it at next patch
> > + unsigned int remain_size;
>
> The member remain_size seems unnecessary data to maintain a channel.
> The virtual channel struct virt_dma_chan already provide the way to
> manage all descriptors you're operating on, you should reuse related
> functions to virt_dma_chan first.
>
> Or if you mean remain_size is about the remaining size of current
> descriptor, and then putting into struct mtk_dma_desc would be better.
>
i will move it to mtk_dma_desc
> > + unsigned int rx_ptr;
> > +};
> > +
> > +struct mtk_dma_sg {
> > + dma_addr_t addr;
> > +
Re: [PATCH] ALSA: Use of_node_name_eq for node name comparisons
On Wed, 05 Dec 2018 20:50:46 +0100, Rob Herring wrote: > > Convert string compares of DT node names to use of_node_name_eq helper > instead. This removes direct access to the node name pointer. > > A couple of open coded iterating thru the child node names are converted > to use for_each_child_of_node() instead. > > Cc: Johannes Berg > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-...@lists.ozlabs.org > Cc: alsa-de...@alsa-project.org > Signed-off-by: Rob Herring Applied, thanks. Takashi
[PATCH] kprobes: x86_64: blacklist non-attachable interrupt functions
These interrupt functions are already non-attachable by kprobes. Blacklist them explicitly so that they can show up in /sys/kernel/debug/kprobes/blacklist and tools like BCC can use this additional information. Signed-off-by: Andrea Righi --- arch/x86/entry/entry_64.S | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index ce25d84023c0..1f0efdb7b629 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -566,6 +566,7 @@ ENTRY(interrupt_entry) ret END(interrupt_entry) +_ASM_NOKPROBE(interrupt_entry) /* Interrupt entry/exit. */ @@ -766,6 +767,7 @@ native_irq_return_ldt: jmp native_irq_return_iret #endif END(common_interrupt) +_ASM_NOKPROBE(common_interrupt) /* * APIC interrupts. @@ -780,6 +782,7 @@ ENTRY(\sym) call\do_sym /* rdi points to pt_regs */ jmp ret_from_intr END(\sym) +_ASM_NOKPROBE(\sym) .endm /* Make sure APIC interrupt handlers end up in the irqentry section: */ @@ -960,6 +963,7 @@ ENTRY(\sym) jmp error_exit .endif +_ASM_NOKPROBE(\sym) END(\sym) .endm -- 2.17.1
Re: [PATCH v7 13/14] module: Do not set nx for module memory before freeing
On Tue, Dec 04, 2018 at 05:34:07PM -0800, Nadav Amit wrote: > So let's remove it. Andy suggested that the changes of the PTEs can be > avoided (excluding the direct-mapping alias), which is true. However, > in x86 it requires some cleanup of the contiguous page allocator, which > is outside of the scope of this patch-set. I think x86-cpa stands for change_page_attr() :-)
Re: [PATCH v2 1/7] arm64: capabilities: Merge entries for ARM64_WORKAROUND_CLEAN_CACHE
On Wed, Dec 05, 2018 at 05:14:53PM +, Suzuki K Poulose wrote:
> On 05/12/2018 15:02, Will Deacon wrote:
> >On Fri, Nov 30, 2018 at 05:18:00PM +, Suzuki K Poulose wrote:
> >>diff --git a/arch/arm64/include/asm/cputype.h
> >>b/arch/arm64/include/asm/cputype.h
> >>index 12f93e4d..2e26375 100644
> >>--- a/arch/arm64/include/asm/cputype.h
> >>+++ b/arch/arm64/include/asm/cputype.h
> >>@@ -151,6 +151,7 @@ struct midr_range {
> >>.rv_max = MIDR_CPU_VAR_REV(v_max, r_max), \
> >>}
> >>+#define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v,
> >>r_max)
> >
> >What's the point of this macro?
>
> That can be used to specify a set of MIDRs which has the same "variant" but a
> range of "revisions". This is used for the A53 errata and also for the Cavium
> errata in the following patch.
Gah, I read this at least 10 times and I /still/ failed to spot the extra
'v' argument to MIDR_RANGE!
Ignore my silly comment; I'll queue this up today. Thanks.
Will
[PATCH] tps65218.c: fix IRQ resource leak in tps65218_probe()
Free allocated IRQ if reading the device ID fails.
Signed-off-by: Christian Hohnstaedt
---
drivers/mfd/tps65218.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 910f569..19270bc 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -244,7 +244,7 @@ static int tps65218_probe(struct i2c_client *client,
ret = regmap_read(tps->regmap, TPS65218_REG_CHIPID, &chipid);
if (ret) {
dev_err(tps->dev, "Failed to read chipid: %d\n", ret);
- return ret;
+ goto err_irq;
}
tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
--
2.7.4
[PATCH] ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
From: Benjamin Gaignard
Declare hwspinlock device for stm32mp157 SoC
Signed-off-by: Benjamin Gaignard
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32mp157c.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index f8bbfff5950b..2bd4394fd791 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -886,6 +886,14 @@
status = "disabled";
};
+ hsem: hwspinlock@4c00 {
+ compatible = "st,stm32-hwspinlock";
+ #hwlock-cells = <1>;
+ reg = <0x4c00 0x400>;
+ clocks = <&rcc HSEM>;
+ clock-names = "hwsem";
+ };
+
rcc: rcc@5000 {
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x5000 0x1000>;
--
2.15.0
Re: [PATCH v4 3/4] ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
Le mer. 14 nov. 2018 à 10:00, Benjamin Gaignard
a écrit :
>
> From: Benjamin Gaignard
>
> Declare hwspinlock device for stm32mp157 SoC
I abandon this patch and I will send a one that fixes the issues.
>
> Signed-off-by: Benjamin Gaignard
> Signed-off-by: Benjamin Gaignard
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
> b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 185541a5b69f..98f824d8b0f0 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -803,6 +803,15 @@
> status = "disabled";
> };
>
> + hsem: hwspinlock@4c00 {
> + compatible = "st,stm32-hwspinlock";
> + #hwlock-cells = <1>;
> + reg = <0x4c00 0x400>;
> + clocks = <&rcc HSEM>;
> + clock-names = "hwsem";
> + status = "disabled";
> + };
> +
> rcc: rcc@5000 {
> compatible = "st,stm32mp1-rcc", "syscon";
> reg = <0x5000 0x1000>;
> --
> 2.15.0
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v7 14/14] module: Prevent module removal racing with text_poke()
On Tue, Dec 04, 2018 at 05:34:08PM -0800, Nadav Amit wrote: > It seems dangerous to allow code modifications to take place > concurrently with module unloading. So take the text_mutex while the > memory of the module is freed. Fun detail, only x86 seems to actually take text_mutex while poking text. > Signed-off-by: Nadav Amit > --- > kernel/module.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/kernel/module.c b/kernel/module.c > index 57c5b23746e7..b45754961143 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -64,6 +64,7 @@ > #include > #include > #include > +#include > #include > #include "module-internal.h" > > @@ -2181,6 +2182,9 @@ static void free_module(struct module *mod) > synchronize_sched(); > mutex_unlock(&module_mutex); > > + /* Protect against patching of the module while it is being removed */ > + mutex_lock(&text_mutex); > + > /* This may be empty, but that's OK */ > module_restore_mappings(&mod->init_layout); > module_arch_freeing_init(mod); > @@ -2194,6 +2198,7 @@ static void free_module(struct module *mod) > /* Finally, free the core (containing the module structure) */ > module_restore_mappings(&mod->core_layout); > module_memfree(mod->core_layout.base); > + mutex_unlock(&text_mutex); > } > > void *__symbol_get(const char *symbol) > -- > 2.17.1 >
Re: [PATCH v7 00/14] x86/alternative: text_poke() enhancements
On Tue, Dec 04, 2018 at 05:33:54PM -0800, Nadav Amit wrote: > Which leads me to (b) - the patch-set is big "enough" IMHO. Indeed, > there are open security issues in the kernel when it comes to W^X. But > some people would want to use Andy's temporary mm-struct for other uses. > So additional security hardening may be left for future patches. Yes, at the very least we should get the first 7 patches merged, since they work and clean up the text poking irrespective of all that W^X munging. (also, I think you lost my ACK)
Re: [PATCH] mm/alloc: fallback to first node if the wanted node offline
[...]
> THanks for pointing this out. It made my life easier. So It think the
> bug is that we call init_memory_less_node from this path. I suspect
> numa_register_memblks is the right place to do this. So I admit I
> am not 100% sure but could you give this a try please?
>
Sure.
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 1308f5408bf7..4575ae4d5449 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -527,6 +527,19 @@ static void __init numa_clear_kernel_node_hotplug(void)
> }
> }
>
> +static void __init init_memory_less_node(int nid)
> +{
> + unsigned long zones_size[MAX_NR_ZONES] = {0};
> + unsigned long zholes_size[MAX_NR_ZONES] = {0};
> +
> + free_area_init_node(nid, zones_size, 0, zholes_size);
> +
> + /*
> +* All zonelists will be built later in start_kernel() after per cpu
> +* areas are initialized.
> +*/
> +}
> +
> static int __init numa_register_memblks(struct numa_meminfo *mi)
> {
> unsigned long uninitialized_var(pfn_align);
> @@ -592,6 +605,8 @@ static int __init numa_register_memblks(struct
> numa_meminfo *mi)
> continue;
>
> alloc_node_data(nid);
> + if (!end)
> + init_memory_less_node(nid);
> }
>
> /* Dump memblock with node info and return. */
> @@ -721,21 +736,6 @@ void __init x86_numa_init(void)
> numa_init(dummy_numa_init);
> }
>
> -static void __init init_memory_less_node(int nid)
> -{
> - unsigned long zones_size[MAX_NR_ZONES] = {0};
> - unsigned long zholes_size[MAX_NR_ZONES] = {0};
> -
> - /* Allocate and initialize node data. Memory-less node is now
> online.*/
> - alloc_node_data(nid);
> - free_area_init_node(nid, zones_size, 0, zholes_size);
> -
> - /*
> -* All zonelists will be built later in start_kernel() after per cpu
> -* areas are initialized.
> -*/
> -}
> -
> /*
> * Setup early cpu_to_node.
> *
> @@ -763,9 +763,6 @@ void __init init_cpu_to_node(void)
> if (node == NUMA_NO_NODE)
> continue;
>
> - if (!node_online(node))
> - init_memory_less_node(node);
> -
> numa_set_node(cpu, node);
> }
> }
> --
Which commit is this patch applied on? I can not apply it on latest linux tree.
Thanks,
Pingfan
Re: [PATCH] auxdisplay: charlcd: fix x/y command parsing
On Wed, Dec 5, 2018 at 6:58 PM Måns Rullgård wrote: > > Suppose the command "\e[Lx0y0;" is written to the device. The > charlcd_write_char() function adds one character at a time to the escape > sequence buffer. Ah, yes, that is much more clear. Indeed, parse_xy() expects the entire command; the strchr() should still be there. By the way, if we are going to move to a direct check, I would also do so in the generator command too if possible, to be consistent (in another patch, possibly). > BTW, the parsing of this command has been broken since 3.2-rc1 due to > commit 129957069e6a. Thanks for checking! Are you able to test this? Cheers, Miguel
[PATCH v2 2/9] ARM: dts: imx7d-pico: Switch to SPDX identifier
From: Fabio Estevam Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Fabio Estevam Signed-off-by: Otavio Salvador --- Changes in v2: None arch/arm/boot/dts/imx7d-pico-pi.dts | 44 ++--- arch/arm/boot/dts/imx7d-pico.dtsi | 44 ++--- 2 files changed, 6 insertions(+), 82 deletions(-) diff --git a/arch/arm/boot/dts/imx7d-pico-pi.dts b/arch/arm/boot/dts/imx7d-pico-pi.dts index ee02d931cf49..33951f4c7f41 100644 --- a/arch/arm/boot/dts/imx7d-pico-pi.dts +++ b/arch/arm/boot/dts/imx7d-pico-pi.dts @@ -1,44 +1,6 @@ -/* - * Copyright 2017 NXP - * - * This file is dual-licensed: you can use it either under the terms - * of the GPL or the X11 license, at your option. Note that this dual - * licensing only applies to this file, and not this project as a - * whole. - * - * a) This file is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of the - * License, or (at your option) any later version. - * - * This file is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * Or, alternatively, - * - * b) Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use, - * copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following - * conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. - */ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +// +// Copyright 2017 NXP #include "imx7d-pico.dtsi" diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi index 0df68e53e9fa..d957454ce16b 100644 --- a/arch/arm/boot/dts/imx7d-pico.dtsi +++ b/arch/arm/boot/dts/imx7d-pico.dtsi @@ -1,44 +1,6 @@ -/* - * Copyright 2017 NXP - * - * This file is dual-licensed: you can use it either under the terms - * of the GPL or the X11 license, at your option. Note that this dual - * licensing only applies to this file, and not this project as a - * whole. - * - * a) This file is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of the - * License, or (at your option) any later version. - * - * This file is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * Or, alternatively, - * - * b) Permission is hereby granted, free of charge, to any person - * obtaining a copy of this software and associated documentation - * files (the "Software"), to deal in the Software without - * restriction, including without limitation the rights to use, - * copy, modify, merge, publish, distribute, sublicense, and/or - * sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following - * conditions: - * - * The above copyright notice and this permission notice shall be - * included in all copies or substantial portions of the Software. - * - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES - * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, - * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR - * OTHER DEALINGS IN THE SOFTWARE. - */ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +// +// Co
