BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

Hi, We run criu tests for linux-next and today we get this bug: The kernel version is 4.15.0-rc3-next-20171215 [ 235.397328] BUG: unable to handle kernel NULL pointer dereference at 000c [ 235.398624] IP: fdb_find_rcu+0x3c/0x130 [ 235.399365] PGD 51970067 P4D 51970067 PUD

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 4:29 PM, Dan Williams wrote: > So do you want to do a straight revert of these that went in for 4.15: I think that's the right thing to do, but would want to verify that there are no *other* issues than just the attempt at PKRU. The commit

Re: [PATCH] ACPI / CPPC: Fix negative array index read in cppc_set_perf

On Wednesday, December 13, 2017 11:45:41 PM CET Gustavo A. R. Silva wrote: > If pcc_ss_id is less than 0, there is a negative array index read > before verifying pcc_ss_id is not a negative value. > > Fix this by removing the code that triggers this issue. > > Notice that this code is already

Re: [PATCH 04/17] mm: pass the vmem_altmap to arch_add_memory and __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig Yeah, the lookup of vmem_altmap is too magical

[RFC 2/5] [media] dt: bindings: Update binding documentation for sunxi IR controller

This patch updates documentation for Device-Tree bindings for sunxi IR controller and adds the new requiered property for the base clock frequency. Signed-off-by: Philipp Rossak --- Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 -- 1 file changed, 8

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 06:28:36PM -0800, Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 5:25 PM, Dave Hansen wrote: > > > > I think the reason we needed VMA and PTE checks was the > > get_user_pages_fast() path not having a VMA. > > That is indeed the point of

[PATCH v2,net-next 1/2] ip_gre: fix potential memory leak in erspan_rcv

If md is NULL, tun_dst must be freed, otherwise it will cause memory leak. Fixes: 1a66a836da6 ("gre: add collect_md mode to ERSPAN tunnel") Cc: William Tu Signed-off-by: Haishuang Yan Change since v2: * Rebase on latest master branch.

[PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board

This is tested in the S400 dev board which use a RTL8211F PHY, and the pins connect to the 'eth_rgmii_y_pins' group. Reviewed-by: Neil Armstrong Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++ 1 file

[PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller

Add DT info for the stmmac ethernet MAC which found in the Amlogic's Meson-AXG SoC, also describe the ethernet pinctrl & clock information here. Reviewed-by: Neil Armstrong Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi |

[PATCH v4 0/2] Add ethernet support for Meson-AXG SoC

This series try to add support for the ethernet MAC controller found in Meson-AXG SoC, and also enable it in the S400 board. Hi Kevin: You still need to at least merge the clock patch[3] in order to compile the DTS, or just merge the tag from meson-clock's tree[6] - the tag is

Re: [PATCH 01/19] fs: new API for handling inode->i_version

On Wed, Dec 13 2017, Jeff Layton wrote: > On Thu, 2017-12-14 at 09:04 +1100, NeilBrown wrote: >> On Wed, Dec 13 2017, Jeff Layton wrote: >> >> > +/* >> > + * The change attribute (i_version) is mandated by NFSv4 and is mostly for >> > + * knfsd, but is also used for other purposes (e.g. IMA).

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[...] > >> + case ESR_ELx_AET_UER: /* The error has not been propagated */ >> + /* >> + * Userspace only handle the guest SError Interrupt(SEI) if the >> + * error has not been propagated >> + */ >> + run->exit_reason =

Re: [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > This commit drops pin configs that cannot be moved to board files as > no boards use them. > > Signed-off-by: Damien Riegel Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > The QUP core can be used either for I2C or SPI, so the same IP is mapped > by a driver or the other. SPI bindings use a leading 0 for the start > address and a size of 0x600, I2C bindings don't have the leading 0 and > have a size 0x1000. > >

Re: [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > Nodes relative to the first sdhc node were interlaced with node of the > second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also > rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as > "pmx_sdc" is the prefix used

Re: [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > Following a suggestion from Bjorn Andersson [1], this commit moves > electrical specifications which were defined in mms8916-pins.dtsi to > board files, where they actually belong. > > Pinmuxing is kept in the platform file because there are

Re: [PATCH 4.4 000/105] 4.4.106-stable review

On 15 December 2017 at 15:13, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.106 release. > There are 105 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH v19 3/7] xbitmap: add more operations

Matthew Wilcox wrote: > On Sat, Dec 16, 2017 at 01:31:24PM +0900, Tetsuo Handa wrote: > > Michael S. Tsirkin wrote: > > > On Sat, Dec 16, 2017 at 01:21:52AM +0900, Tetsuo Handa wrote: > > > > My understanding is that virtio-balloon wants to handle sparsely > > > > spreaded > > > > unsigned long

Re: [PATCH v2 net-next 2/4] net: tracepoint: replace tcp_set_state tracepoint with sock_set_state tracepoint

2017-12-16 6:47 GMT+08:00 Song Liu : > >> On Dec 15, 2017, at 9:56 AM, Yafang Shao wrote: >> >> As sk_state is a common field for struct sock, so the state >> transition should not be a TCP specific feature. >> So I rename tcp_set_state tracepoint to

Re: [PATCH] drm/virtio: Add window server support

Hi Tomeu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc3] [cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215] [if your patch is applied to the wrong git tree, please drop us a note

Re: [2/2] fs, elf: drop MAP_FIXED usage from elf_map

Hi Michal, We run CRIU tests for linux-next and the 4.15.0-rc3-next-20171215 kernel doesn't boot: [3.492549] Freeing unused kernel memory: 1640K [3.494547] Write protecting the kernel read-only data: 18432k [3.498781] Freeing unused kernel memory: 2016K [3.503330] Freeing unused

Re: [PATCH 03/17] mm: don't export __add_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > This function isn't used by any modules, and is only to be called > from core MM code. This includes the calls for the add_pages wrapper > that might be inlined. > > Signed-off-by: Christoph Hellwig Looks

Re: [PATCH 02/17] mm: don't export arch_add_memory

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > Only x86_64 and sh export this symbol, and it is not used by any > modular code. > > Signed-off-by: Christoph Hellwig Looks good, Reviewed-by: Dan Williams

Re: [PATCH 01/17] memremap: provide stubs for vmem_altmap_offset and vmem_altmap_free

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > Currently all calls to those functions are eliminated by the compiler when > CONFIG_ZONE_DEVICE is not set, but this soon won't be the case. > > Signed-off-by: Christoph Hellwig Looks good, Reviewed-by: Dan

Re: [PATCH] ACPI / CPPC: remove initial assignment of pcc_ss_data

On Saturday, December 9, 2017 12:59:49 AM CET Colin King wrote: > From: Colin Ian King > > The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before > pcc_ss_id is being range checked could lead to an out-of-bounds array > read. This very same initialization is

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Fri, Dec 15, 2017 at 5:53 PM, Rafael J. Wysocki wrote: > On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote: >> On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler >> wrote: >> > The current implementation of acpi_parse_entries_array()

Re: [PATCH v2] ACPI / PMIC: constify platform_device_id

On Wednesday, November 29, 2017 9:51:32 AM CET Mika Westerberg wrote: > On Wed, Nov 29, 2017 at 10:05:02AM +0530, Arvind Yadav wrote: > > platform_device_id are not supposed to change at runtime. All functions > > working with platform_device_id provided by > > work with const platform_device_id.

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

I reproduced the issue. Will have a look. -- Best regards Tianyu Lan 2017-12-15 18:14 GMT+08:00 syzbot : > syzkaller has found reproducer for the following crash on > 82bcf1def3b5f1251177ad47c44f7e17af039b4b >

Re: [PATCH v3 00/11] ASoC: fsl_ssi: Clean up - coding style level

On 12/13/17 5:18 PM, Nicolin Chen wrote: Additionally, in order to fix/work-around hardware bugs and design flaws, the driver made a lot of compromise so now its program flow looks very complicated and it's getting hard to maintain or update. So I am going to clean up the driver on both coding

Re: [PATCH] platform/chrome: cros_ec_lpc: remove redundant pointer request

Hi Colin, On Tue, Oct 31, 2017 at 10:27:47AM +, Colin King wrote: > From: Colin Ian King > > Pointer request is being assigned but never used, so remove it. Cleans > up the clang warning: > > drivers/platform/chrome/cros_ec_lpc.c:68:2: warning: Value stored to >

Re: [PATCH v2 0/4] Utilization estimation (util_est) for FAIR tasks

On Fri, 2017-12-15 at 21:23 +0100, Mike Galbraith wrote: > > Point: if you think it's OK to serialize these firefox threads, would > you still think so if those were kernel threads instead?  Serializing > your kernel is a clear fail, but unpinned kthreads can be stacked up > just as effectively

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On 2017/12/16 8:04, Andrew Morton wrote: >> The implementation is steered toward an expensive slowpath, such as after >> the oom reaper has grabbed mm->mmap_sem of a still alive oom victim. > > some tweakage, please review. > > From: Andrew Morton > Subject: >

Re: [PATCH] mm: Reduce memory bloat with THP

On 12/15/17 2:00 AM, Kirill A. Shutemov wrote: > On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote: >> Currently, if the THP enabled policy is "always", or the mode >> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage >> is allocated on a page fault if the pud or pmd is

Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

On 2017/12/16 3:35, Matthew Wilcox wrote: >> It's going to be complicated to do, I don't think its worth the effort. > We can find a bit in struct page that we guarantee will only be set if > this is allocated as a pagetable. Bit 1 of the third union is currently > available (compound_head is a

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 04:20:31PM -0800, Linus Torvalds wrote: > On Thu, Dec 14, 2017 at 11:51 PM, Peter Zijlstra wrote: > > > > So we actually need the pte_access_permitted() stuff if we want to > > ensure we're not stepping on !PAGE_USER things. > > We really don't. Not

[RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

Linus, Please consider pulling the latest x86-pti-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus # HEAD: eeb17ad55b3f7959805ae995fe955d6d93e67e89 Merge branch 'WIP.x86/pti.entry' into x86/pti These are the x86-64 low level entry code

Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection

On 12/13/2017 12:53 PM, Alexandre Belloni wrote: > The clocksource and clockevent timer are probed early in the boot process. > At that time it is difficult for linux to know whether a particular timer > can be used as the clocksource or the clockevent or by another driver, > especially when

Re: [GIT PULL] Immutable branch between MFD and Platform due for the v4.16 merge window

Hi Lee, On Fri, Dec 15, 2017 at 10:48:20AM +, Lee Jones wrote: > Enjoy! > > The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: > > Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) > > are available in the git repository at: > >

[PATCH 1/1] usb: xhci: dbc: Fix lockdep warning

The xHCI DbC implementation might enter a deadlock situation because there is no sufficient protection against the shared data between process and softirq contexts. This can lead to the following lockdep warnings. This patch changes to use spin_{,un}lock_irq{save,restore} to avoid potential

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Thu, Dec 14, 2017 at 11:51 PM, Peter Zijlstra wrote: > > So we actually need the pte_access_permitted() stuff if we want to > ensure we're not stepping on !PAGE_USER things. We really don't. Not in that complex and broken format, and not for every level. Also, while I

Re: [PATCH PTI v3 10/10] x86/pti: Put the LDT in its own PGD if PTI is on

On Tue, 12 Dec 2017, Andy Lutomirski wrote: > + > + return 0; > +#else > + return -EINVAL; Errm. What's the point of that? Breaking non PTI? > new_ldt = alloc_ldt_struct(old_mm->context.ldt->nr_entries); > if (!new_ldt) { > @@ -155,8 +266,17 @@ int init_new_context_ldt(struct

[PATCH] x86/mm/dump_pagetables: Check PAGE_PRESENT for real

The check for a present page in printk_prot(): if (!pgprot_val(prot)) { /* Not present */ is bogus. If a PTE is set to PAGE_NONE then the pgprot_val is not zero and the entry is decoded in bogus ways, e.g. as RX GLB. That is confusing when analyzing mapping correctness.

Re: [PATCH] drm/virtio: Add window server support

Hi Tomeu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc3] [cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next next-20171215] [if your patch is applied to the wrong git tree, please drop us a note

Re: [PATCH 07/17] mm: pass the vmem_altmap to vmemmap_free

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking a few levels into the callchain. > > Signed-off-by: Christoph Hellwig Now I remember why I went with the radix

[PATCH] trace: reenable preemption if we modify the ip

From: Josef Bacik Things got moved around between the original bpf_override_return patches and the final version, and now the ftrace kprobe dispatcher assumes if you modified the ip that you also enabled preemption. Make a comment of this and enable preemption, this fixes the

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 6:48 PM, Al Viro wrote: > > Treating protection key bits as "escalate to page fault and let that > deal with the checks" should be fine Well, it's *semantically* fine and I think it's the right model from that standpoint. However, since the main

[PATCH v3] staging: ion: Fix ion_cma_heap allocations

In trying to add support for drm_hwcomposer to HiKey, I've needed to utilize the ION CMA heap, and I've noticed problems with allocations on newer kernels failing. It seems back with 204f672255c2 ("ion: Use CMA APIs directly"), the ion_cma_heap code was modified to use the CMA API, but kept the

[PATCH V2] x86/efi: fix kernel param add_efi_memmap regression

'add_efi_memmap' is an early param, but do_add_efi_memmap() has no chance to run because the code path is before parse_early_param(). I believe it worked when the param was introduced but probably later some other changes caused the wrong order and nobody noticed it. Move

Re: [PATCH v2 10/10] arm64: dts: qcom: msm8916: add nodes for i2c1, i2c3, i2c5

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > Signed-off-by: Damien Riegel Please move pinconf settings into the structure in apq8016-sbc-soc-pins.dtsi (didn't see this when commenting on the previous patch). Apart from this, the patch looks good.

Re: [patch v2 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On 2017/12/16 1:25, Michal Hocko wrote: >> struct mmu_notifier_ops { >> +/* >> + * Flags to specify behavior of callbacks for this MMU notifier. >> + * Used to determine which context an operation may be called. >> + * >> + * MMU_INVALIDATE_DOES_NOT_BLOCK:

Re: [PATCH PTI v3 10/10] x86/pti: Put the LDT in its own PGD if PTI is on

On Fri, Dec 15, 2017 at 2:54 PM, Thomas Gleixner wrote: > On Tue, 12 Dec 2017, Andy Lutomirski wrote: >> +/* This is a multiple of PAGE_SIZE. */ >> +#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE) >> + >> +static void *ldt_slot_va(int slot) > > How is that supposed to

Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

Hi Maxime, I love your patch! Yet something to improve: [auto build test ERROR on ] url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-sun4i-Support-the-Display-Engine-frontend/20171216-122702 base: config: arm-sunxi_defconfig (attached as .config) compiler:

Re: [PATCH] exit: move exit_task_namespaces() after exit_task_work()

On Sat, Dec 16, 2017 at 1:00 AM, Cong Wang wrote: > syzbot reported we have a use-after-free when mqueue_evict_inode() > is called on __cleanup_mnt() path, where the ipc ns is already > freed by the previous exit_task_namespaces(). We can just move > it

[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

I've found that on Google's "Kevin" Chromebook, the rt5514 codec might not be set up completely, yet its device is still present, and therefore its PM suspend/resume is called. This hits a NULL pointer exception, since we never had the chance to set our drvdata pointer. This resolves crashes seen

Re: [PATCH 05/17] mm: pass the vmem_altmap to vmemmap_populate

[ cc Michal ] On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking a few levels into the callchain. > > Signed-off-by: Christoph Hellwig I know Michal has concerns

Re: [PATCH 06/17] mm: pass the vmem_altmap to arch_remove_memory and __remove_pages

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > We can just pass this on instead of having to do a radix tree lookup > without proper locking 2 levels into the callchain. > > Signed-off-by: Christoph Hellwig wip I assume that "wip" is a typo? Otherwise,

Re: [PATCH 08/17] mm: pass the vmem_altmap to memmap_init_zone

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > Pass the vmem_altmap two levels down instead of needing a lookup. > > Signed-off-by: Christoph Hellwig Given the fact that HMM and now P2P are attracted to devm_memremap_pages() I think this churn is worth it.

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Sat, Dec 16, 2017 at 2:57 AM, Dan Williams wrote: > On Fri, Dec 15, 2017 at 5:53 PM, Rafael J. Wysocki wrote: >> On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote: >>> On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler >>>

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 6:52 PM, Linus Torvalds wrote: > > However, since the main use case of protection keys is probably > databases (Dave?) and since those also might be performance-sensitive > about direct-IO doing page table lookups, it might not be great in >

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

+ others On Fri, Dec 15, 2017 at 05:12:30PM -0800, Brian Norris wrote: > I've found that on Google's "Kevin" Chromebook, the rt5514 codec might > not be set up completely, yet its device is still present, and therefore > its PM suspend/resume is called. This hits a NULL pointer exception, > since

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On 12/15/2017 06:52 PM, Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 6:48 PM, Al Viro wrote: >> Treating protection key bits as "escalate to page fault and let that >> deal with the checks" should be fine > > Well, it's *semantically* fine and I think it's the right

[PATCH] ext4: delayed inode update for the consistency of file size after a crash

> > 1. Current file offset of fileA is 14 KB. An application appends 2 KB data > > to > > fileA by executing a write() system call. At this time, the file size in > > the ext4_inode of fileA is updated to 16 KB by ext4_da_write_end(). > > 2. Current file offset of fileB is 14 KB. An application

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

+ RTC maintainers On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote: > On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote: > > From: Stephen Barber > > > > On platforms with a Chrome OS EC, the EC can function as a simple RTC. > > Add a

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

On Fri, Dec 01, 2017 at 11:49:54AM -0800, Gwendal Grignou wrote: > Checked against 7412f0a0d90ee6ddbad4cde794f88f1489422f3a (CHROMIUM: > platform/chrome: Support MKBP protocol over ACPI) > Reviewed-by: Gwendal Grignou > Thanks Gwendal. (ps, don't top post.) -- Benson

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 12/16/17 at 01:15am, Jiri Bohac wrote: > On machines where the GART aperture is mapped over physical RAM > /proc/vmcore contains the remapped range and reading it may > cause hangs or reboots. > > In the past, the GART region was added into the resource map, implemented by > commit

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 5:10 PM, Linus Torvalds wrote: > On Fri, Dec 15, 2017 at 4:29 PM, Dan Williams > wrote: >> So do you want to do a straight revert of these that went in for 4.15: > > I think that's the right thing to do, but would

Re: [PATCH 10/17] mm: merge vmem_altmap_alloc into altmap_alloc_block_buf

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > There is no clear separation between the two, so merge them. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Logan Gunthorpe Looks good, Reviewed-by: Dan Williams

[PATCH v2,net-next 2/2] ip6_gre: fix error path when ip6erspan_rcv failed

Same as ipv4 code, when ip6erspan_rcv call return PACKET_REJECT, we should call icmpv6_send to send icmp unreachable message in error path. Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support") Acked-by: William Tu Cc: William Tu

[PATCH v2,net-next 1/2] ip_gre: fix error path when erspan_rcv failed

When erspan_rcv call return PACKET_REJECT, we shoudn't call ipgre_rcv to process packets again, instead send icmp unreachable message in error path. Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN") Acked-by: William Tu Cc: William Tu

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

Hi, On Fri, Nov 10, 2017 at 10:55:52PM +0100, Enric Balletbo i Serra wrote: > From: Stephen Barber > > The EC can function as a simple RT, this patch adds the RTC related > definitions needed by the rtc-cros-ec driver. > > Signed-off-by: Stephen Barber

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote: > From: Stephen Barber > > On platforms with a Chrome OS EC, the EC can function as a simple RTC. > Add a basic driver with this functionality. > > Signed-off-by: Stephen Barber

Re: [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes

On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote: > These nodes reserve and configure some pins as GPIOs. They are not > generic pinctrls, they actually belong to board files but they are not > used by any other node, so just drop them altogether. > > Signed-off-by: Damien Riegel

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

Hi Thierry, Sorry for the delay in processing these. On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote: > From: Enric Balletbo i Serra > > Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for > GOOG004 ACPI device") added support when

Re: [PATCH v5 1/3] platform/chrome: cros_ec_lpc: Register the driver if ACPI entry is missing.

Hi Thierry, On Fri, Dec 01, 2017 at 02:42:21PM +0100, Thierry Escande wrote: > From: Enric Balletbo i Serra > > Commit 12278dc7c572 ("platform/chrome: cros_ec_lpc: Add support for > GOOG004 ACPI device") added support when the firmware reports the ACPI > device,

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 4:20 PM, Linus Torvalds wrote: > > On Thu, Dec 14, 2017 at 11:51 PM, Peter Zijlstra wrote: > > > > So we actually need the pte_access_permitted() stuff if we want to > > ensure we're not stepping on !PAGE_USER things. >

Re: [PATCH 2/2] input - leds: fix input_led_disconnect path

Hi Benjamin, On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote: > Before unregistering the led classes, we have to be sure there is no > more events in the input pipeline. > Closing the input node before removing the led classes flushes the > pipeline and this prevents segfaults.

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On 12/15/2017 05:10 PM, Linus Torvalds wrote: > Because *if* we want to check protection keys, I think we should do > that at the vma layer, partly exactly because the exact implementation > of protection keys is so architecture-specific, and partly because I > don't think it makes sense to check

Re: [PATCH] ip6_gre: fix a pontential issue in ip6erspan_rcv

> On 2017年12月16日, at 上午3:11, David Miller wrote: > > From: Haishuang Yan > Date: Fri, 15 Dec 2017 10:46:38 +0800 > >> pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at >> the right place. >> >> Fixes:

Re: [PATCH 09/17] mm: split altmap memory map allocation from normal case

On Fri, Dec 15, 2017 at 6:09 AM, Christoph Hellwig wrote: > No functional changes, just untangling the call chain. I'd also mention that creating more helper functions in the altmap_ namespace helps document why altmap is passed all around the hotplug code. > > Signed-off-by:

Re: [PATCH] locking/lockdep: Remove the cross-release locking checks

On Sat, Dec 16, 2017 at 6:15 AM, Theodore Ts'o wrote: > On Fri, Dec 15, 2017 at 05:39:25PM +0900, Byungchul Park wrote: >> >> All locks should belong to one class if each path of acquisition >> can be switchable each other within the class at any time. >> Otherwise, they should

Re: [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller

HI Kevin On 12/16/2017 03:29 AM, Kevin Hilman wrote: > Yixun Lan writes: > >> Add DT info for the stmmac ethernet MAC which found in >> the Amlogic's Meson-AXG SoC, also describe the ethernet >> pinctrl & clock information here. >> >> Reviewed-by: Neil Armstrong

Re: [PATCH] cros_ec: fix nul-termination for firmware build info

Hi Arnd, On Mon, Dec 04, 2017 at 03:49:48PM +0100, Arnd Bergmann wrote: > As gcc-8 reports, we zero out the wrong byte: > > drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version': > drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript > 4294967295 is above

Re: [PATCH 4.14 00/52] 4.14.7-stable review

On 15 December 2017 at 15:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.7 release. > There are 52 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH v5 2/3] platform/chrome: cros_ec_lpc: Add support for Google Glimmer

Hi Thierry, On Fri, Dec 01, 2017 at 02:42:22PM +0100, Thierry Escande wrote: > This patch adds device information to the DMI table of the cros_ec_lpc > driver for Google Glimmer devices. Since Google BIOS does not enumerate > devices in the LPC bus, the cros_ec_lpc driver checks for system >

Re: [PATCH 3/3] arm64: dts: meson-axg: add new reset DT node

Neil Armstrong writes: > On 10/11/2017 09:46, Yixun Lan wrote: >> Add reset DT node for Amlogic's Meson-AXG SoC. >> >> Signed-off-by: Yixun Lan >> --- >> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 ++ >> 1 file changed, 6 insertions(+)

[Resend][PATCH V2] cpufreq: intel_pstate: allow trace in passive mode

Allow use of the trace_pstate_sample trace function when the intel_pstate driver is in passive mode. Since the core_busy and scaled_busy fields are not used, and it might be desirable to know which path through the driver was used, either intel_cpufreq_target or intel_cpufreq_fast_switch, re-task

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 4:31 PM, Al Viro wrote: >> >> The fact is, if we have non-user mappings in the user part of the >> address space, we _need_ to teach access_ok() about them, because >> fundamentally any "get_user()/put_user()" will happily ignore the lack >> of

Re: [PATCH v3 1/3] acpi: HMAT support in acpi_parse_entries_array()

On Friday, December 15, 2017 2:10:17 AM CET Dan Williams wrote: > On Wed, Dec 13, 2017 at 6:10 PM, Ross Zwisler > wrote: > > The current implementation of acpi_parse_entries_array() assumes that each > > subtable has a standard ACPI subtable entry of type struct > >

Re: [PATCH v8 4/8] intel_sgx: driver for Intel Software Guard Extensions

Jarkko, Suresh, On Fri, Dec 15, 2017 at 9:27 PM, Jarkko Sakkinen wrote: > Intel SGX is a set of CPU instructions that can be used by applications > to set aside private regions of code and data. The code outside the > enclave is disallowed to access the memory

Re: [PATCH v2 01/17] mm/gup: Fixup p*_access_permitted()

On Fri, Dec 15, 2017 at 5:25 PM, Dave Hansen wrote: > > I think the reason we needed VMA and PTE checks was the > get_user_pages_fast() path not having a VMA. That is indeed the point of get_user_pages_fast(): no vma lookup, no locking, just "do the default case as

Re: [PATCH] kbuild: fix dependency of dtbs targets

2017-12-14 6:31 GMT+09:00 Rob Herring : > On Wed, Oct 25, 2017 at 12:40 AM, Masahiro Yamada > wrote: >> Hi. >> >> >> 2017-10-10 0:05 GMT+09:00 Russell King - ARM Linux : >>> On Wed, Oct 04, 2017 at 01:27:20PM +0900, Masahiro

Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

Hi, El Sun, Nov 19, 2017 at 03:43:50PM +0100 Greg Kroah-Hartman ha dit: > 4.13-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Leif Liddy > > commit fd865802c66bc451dc515ed89360f84376ce1a56 upstream. > > There's

Re: [PATCH v4 0/2] dt: add pinctrl driver for Meson-AXG SoC

On 12/16/2017 03:48 AM, Kevin Hilman wrote: > Yixun Lan writes: > >> This is DT part patchset for adding pinctrl support for >> the Amlogic's Meson-AXG SoC. >> >> Changes since v3 at [3] >> -- rebase to khilman's v4.16/dt64 branch and re-send >> -- add Rob's Ack >>

Re: [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

Hi, On Tue, Nov 21, 2017 at 04:25:17PM +0800, Jeffy Chen wrote: > The rt5514 dsp captures pcm data through spi directly, so we should not > use rockchip-i2s as it's cpu dai like other codecs. > > Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again. > > Reported-by: Jimmy

[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

If an rt5514-spi device is probed but the platform hasn't linked it in, we might never fully request the SPI IRQ, nor configure the rt5514 DSP, but we still might try to enable the SPI IRQ (enable_irq_wake()). This is bad, and among other things, can cause the interrupt to trigger every time we

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/13/17 5:18 PM, Nicolin Chen wrote: -* We are running on a SoC which does not support online SSI -* reconfiguration, so we have to enable all necessary flags at once -* even if we do not use them later (capture and playback configuration) +* Online

Re: [PATCH 4.9 00/27] 4.9.70-stable review

On 15 December 2017 at 15:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.70 release. > There are 27 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: jsm_tty: Deletion of a null pointer check in two functions?

> Thanks for the fix. Thanks for your positive feedback. > I was on vacation - but now seeing all the analysis made here, I assume that special communication settings could trigger corresponding consequences for the discussed source code adjustment. > if "ch" can't be NULL then please go

[PATCH v2,net-next] ip6_gre: fix a pontential issue in ip6erspan_rcv

pskb_may_pull() can change skb->data, so we need to load ipv6h/ershdr at the right place. Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support") Acked-by: William Tu Cc: William Tu Signed-off-by: Haishuang Yan

Re: [PATCH v2 4/4] sched/cpufreq_schedutil: use util_est for OPP selection

On Tuesday, December 5, 2017 6:10:18 PM CET Patrick Bellasi wrote: > When schedutil looks at the CPU utilization, the current PELT value for > that CPU is returned straight away. In certain scenarios this can have > undesired side effects and delays on frequency selection. > > For example, since

  1   2   3   4   5   6   7   8   9   10   >