- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Apply "netfilter: nf_queue: Make the queue_handler pernet" to 4.4-stable

by Eric Biggers

Hi Greg, can you please apply commit dc3ee32e96d7 ("netfilter: nf_queue: Make the queue_handler pernet") to 4.4-stable? syzbot is hitting the crash in nfqnl_nf_hook_drop() by interrupting thread creation in pg_net_init(). An OOM condition is not required, contrary to what is suggested by the original commit message. Thanks, Eric

7 years, 4 months

2
1
0 0

[Linux-stable-mirror] Commit bc137dfdbec2 (watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop)

by Rasmus Villemoes

Hi stable maintainers Can I get you to consider including bc137dfdbec2 watchdog: gpio_wdt: set WDOG_HW_RUNNING in gpio_wdt_stop in -stable? Without that, any (always-running) gpio watchdog effectively fails to honour the magic close feature, causing an unexpected reset shortly after userspace gracefully closes the device. Anything containing 3c10bbde10 ("watchdog: core: Clear WDOG_HW_RUNNING before calling the stop function") probably needs it (i.e. 4.8+), but at the very least 4.14 and 4.15. Rasmus

7 years, 4 months

2
1
0 0

Re: [Linux-stable-mirror] [stable-4.4.y] compile error with KAISER and no vsyscall emulation

by Hugh Dickins

On Sat, 10 Feb 2018, Tobias Jakobi wrote: > Hello, > > I noticed a compile error with a recent version (4.4.115) of the 4.4.y branch: > arch/x86/mm/kaiser.c: In function ‘kaiser_init’: > arch/x86/mm/kaiser.c:348:8: error: ‘vsyscall_pgprot’ undeclared (first use in > this function) > > It seems like my combination of kernel options doesn't work for KAISER. > X86_VSYSCALL_EMULATION is not set on my system, while LEGACY_VSYSCALL is set to > NONE (LEGACY_VSYSCALL_NONE=y). I have managed to get things compiling again, by > moving the 'extern unsigned long vsyscall_pgprot' outside of the preprocessor > statement. This works for me, I guess because the code in question is never > called during runtime anyway (vsyscall_enabled() always returns false). > > With best wishes, > Tobias Yes, sorry about that, thanks Tobias. Same error on 4.9 too. Here's the patch that you correctly suggest, and it's good for both: [PATCH 4.4 and 4.9] kaiser: fix compile error without vsyscall Tobias noticed a compile error on 4.4.115, and it's the same on 4.9.80: arch/x86/mm/kaiser.c: In function ‘kaiser_init’: arch/x86/mm/kaiser.c:348:8: error: ‘vsyscall_pgprot’ undeclared (first use in this function) It seems like his combination of kernel options doesn't work for KAISER. X86_VSYSCALL_EMULATION is not set on his system, while LEGACY_VSYSCALL is set to NONE (LEGACY_VSYSCALL_NONE=y). He managed to get things compiling again, by moving the 'extern unsigned long vsyscall_pgprot' outside of the preprocessor statement. This works because the optimizer removes that code (vsyscall_enabled() is always false) - and that's how it was done in some older backports. Reported-by: Tobias Jakobi <tjakobi(a)math.uni-bielefeld.de> Signed-off-by: Hugh Dickins <hughd(a)google.com> --- arch/x86/include/asm/vsyscall.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/include/asm/vsyscall.h +++ b/arch/x86/include/asm/vsyscall.h @@ -13,7 +13,6 @@ extern void map_vsyscall(void); */ extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address); extern bool vsyscall_enabled(void); -extern unsigned long vsyscall_pgprot; #else static inline void map_vsyscall(void) {} static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) @@ -22,5 +21,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address) } static inline bool vsyscall_enabled(void) { return false; } #endif +extern unsigned long vsyscall_pgprot; #endif /* _ASM_X86_VSYSCALL_H */

7 years, 4 months

2
1
0 0

Re: B43 driver no longer works in Linux 4.15 (bisected)

by Greg Kroah-Hartman

On Mon, Feb 12, 2018 at 03:22:32PM +0000, James Hogan wrote: > On Mon, Feb 12, 2018 at 05:08:10PM +0200, Kalle Valo wrote: > > James Hogan <jhogan(a)kernel.org> writes: > > > On Mon, Feb 05, 2018 at 01:23:31PM -0500, Adric Blake wrote: > > >> I bisected to this "first bad commit:" > > >> > > >> commit 58eae1416b804d900014d84feadda7195007cc30 > > >> Author: James Hogan <jhogan(a)kernel.org> > > >> Date: Mon Jan 15 21:17:14 2018 +0000 > > >> > > >> ssb: Disable PCI host for PCI_DRIVERS_GENERIC > > > > > > Yes, really sorry about that and thanks for going to the effort of > > > bisecting. There is a patch here: > > > https://patchwork.kernel.org/patch/10185397/ > > > > > > which is applied to linux-next as commit > > > a9e6d44ddeccd3522670e641f1ed9b068e746ff7, and is tagged for stable, > > > though I've just noticed the stable email address is incorrect... I'll > > > make sure it gets applied to the 4.15 stable branch though as soon as > > > I notice its merged. > > > > The commit is now in v4.16-rc1. > > Yes, thanks, > > Greg: Please can commit a9e6d44ddeccd3522670e641f1ed9b068e746ff7 ("ssb: > Do not disable PCI host on non-Mips") be applied to 4.15 stable (the > wrong stable email address was Cc'd in the commit message). Now applied, thanks. greg k-h

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] apply (dmaengine: dmatest: fix container_of member in dmatest_callback) to stable

by Adam Wallis

Please apply commit: 66b3bd2356e0a1531c71a3dcf96944621e25c17c (dmaengine: dmatest: fix container_of member in dmatest_callback) to stable This fixes a bug in dmatest that will cause the test to give a false negative. -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

7 years, 4 months

4
3
0 0

[Linux-stable-mirror] [PATCH stable] cifs: empty TargetInfo leads to crash on recovery

by Dan Aloni

commit cabfb3680f78 upstream. [ resend from Oct 20, 2014, see [1] ] A trivially patched Samba server (see [2] [3]) can cause a remote kernel crash (see [4]) in a client's CIFS kernel module upon session recovery, under kernels prior to v4.11. The server patch can made by a single source line modification - returning an empty TargetInfo in an NTLMSSP setup negotiation response. To reproduce at the client side, the CIFS client can be instructed to mount with SMB 2.0, on a share without user/password credentials, e.g: mount -t cifs //[host]/[share] -o vers=2.0,guest [mountpoint] (It may also reproduce with credentials, but I used a simpler configuration for the reproduction) An demo patch to Samba 4.7.4 is provided in the links provided. As for the client crash itself: When the session is recovered (after a server start/stop, for example), the following condition turns out to be true: ses->auth_key.len != 0 && ses->auth_key.response == NULL This will cause the following memcpy() in setup_ntlmv2_rsp() to GPF, because tiblob == NULL and tilen != 0 (these are the old auth_key values): memcpy(ses->auth_key.response + baselen, tiblob, tilen); By bisecting, upstream commit cabfb3680f78 ("CIFS: Enable encryption during session setup phase") from v4.11 have fixed this issue. According to my tests, LTS kernels versions 4.4.x and 4.9.x are affected. The patch below applies for 4.4.x however a similar patch can be applied to 4.9.x and older kernels. Signed-off-by: Dan Aloni <dan(a)kernelim.com> CC: Steve French <sfrench(a)samba.org> CC: stable(a)vger.kernel.org # 4.4.x CC: linux-cifs(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org [1] https://patchwork.kernel.org/patch/5106391/ [2] (temporary url) http://copr-dist-git.fedorainfracloud.org/cgit/alonid/samba-for-client-cras… [3] (temporary url) https://copr.fedorainfracloud.org/coprs/alonid/samba-for-client-crash-repro/ [4] [ 3414.518134] BUG: unable to handle kernel NULL pointer dereference at (null) [ 3414.518200] IP: memcpy_erms+0x6/0x10 [ 3414.518227] PGD 0 [ 3414.518252] Oops: 0000 [#1] SMP [ 3414.518272] Modules linked in: arc4 md4 cifs rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables snd_hda_codec_generic ppdev snd_hda_intel snd_hda_codec crct10dif_pclmul crc32_pclmul snd_hwdep snd_hda_core ghash_clmulni_intel snd_seq snd_seq_device snd_pcm joydev parport_pc tpm_tis parport tpm_tis_core tpm snd_timer snd soundcore qemu_fw_cfg virtio_balloon i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c [ 3414.518708] virtio_blk virtio_console virtio_net qxl drm_kms_helper ttm crc32c_intel drm ata_generic nvme serio_raw nvme_core virtio_pci virtio_ring virtio pata_acpi [ 3414.518803] CPU: 3 PID: 1697 Comm: kworker/3:1 Not tainted 4.10.0-rc6-dan-00097-ge765a3d89ede #20 [ 3414.518852] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 [ 3414.518927] Workqueue: cifsiod smb2_reconnect_server [cifs] [ 3414.518960] task: ffff8cc6764a4000 task.stack: ffff9bc548808000 [ 3414.518997] RIP: 0010:memcpy_erms+0x6/0x10 [ 3414.519021] RSP: 0018:ffff9bc54880bbc8 EFLAGS: 00010296 [ 3414.519051] RAX: ffff8cc6ba00d8dc RBX: ffff8cc676190400 RCX: 0000000000000010 [ 3414.519091] RDX: 0000000000000010 RSI: 0000000000000000 RDI: ffff8cc6ba00d8dc [ 3414.519130] RBP: ffff9bc54880bc30 R08: ffff9bc54880bb58 R09: ffff9bc54880bb58 [ 3414.519170] R10: 000000004619520e R11: 00000000f46cd8cf R12: 0000000000000000 [ 3414.519209] R13: 0000000000000000 R14: ffff8cc6ba00d8a0 R15: 0000000000000010 [ 3414.519250] FS: 0000000000000000(0000) GS:ffff8cc6bfd80000(0000) knlGS:0000000000000000 [ 3414.519314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3414.519347] CR2: 0000000000000000 CR3: 000000007992a000 CR4: 00000000003406e0 [ 3414.519392] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3414.519431] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3414.519470] Call Trace: [ 3414.519510] ? setup_ntlmv2_rsp+0x124/0xa10 [cifs] [ 3414.519553] build_ntlmssp_auth_blob+0x36/0x310 [cifs] [ 3414.519597] SMB2_sess_auth_rawntlmssp_authenticate+0xc7/0x300 [cifs] [ 3414.519646] SMB2_sess_setup+0x9a/0x140 [cifs] [ 3414.519685] cifs_setup_session+0x78/0x100 [cifs] [ 3414.519722] ? cifs_negotiate_protocol+0x84/0xd0 [cifs] [ 3414.519763] smb2_reconnect+0x308/0x3e0 [cifs] [ 3414.519793] ? __internal_add_timer+0x1f/0x60 [ 3414.519831] smb2_reconnect_server+0x187/0x260 [cifs] [ 3414.519863] process_one_work+0x19e/0x440 [ 3414.519887] worker_thread+0x4e/0x4a0 [ 3414.519910] ? process_one_work+0x440/0x440 [ 3414.519936] kthread+0x11e/0x140 [ 3414.520493] ? kthread_park+0x90/0x90 [ 3414.520989] ret_from_fork+0x2c/0x40 [ 3414.521450] Code: 78 ff ff ff 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 [ 3414.522488] RIP: memcpy_erms+0x6/0x10 RSP: ffff9bc54880bbc8 [ 3414.522964] CR2: 0000000000000000 [ 3414.526127] ---[ end trace bbe4aa1e45cc6c17 ]--- --- fs/cifs/smb2pdu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index f2ff60e58ec8..91c9e83df457 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -633,6 +633,7 @@ SMB2_sess_setup(const unsigned int xid, struct cifs_ses *ses, */ kfree(ses->auth_key.response); ses->auth_key.response = NULL; + ses->auth_key.len = 0; /* * If memory allocation is successful, caller of this function @@ -837,6 +838,7 @@ ssetup_exit: rc = server->ops->generate_signingkey(ses); kfree(ses->auth_key.response); ses->auth_key.response = NULL; + ses->auth_key.len = 0; if (rc) { cifs_dbg(FYI, "SMB3 session key generation failed\n"); @@ -861,6 +863,7 @@ keygen_exit: if (!server->sign) { kfree(ses->auth_key.response); ses->auth_key.response = NULL; + ses->auth_key.len = 0; } if (spnego_key) { key_invalidate(spnego_key); -- 2.14.3

7 years, 4 months

2
3
0 0

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

by Mathieu Malaterre

Hi, On Tue, Feb 13, 2018 at 3:32 PM, James Hogan <jhogan(a)kernel.org> wrote: > On Tue, Feb 13, 2018 at 03:03:24PM +0100, Mathieu Malaterre wrote: >> James, >> >> On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan(a)kernel.org> wrote: >> > On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote: >> >> Could you please review the patch v3 ? >> > >> > Yes, looks good to me, and Ralf had applied to his test branch so I >> > presume he's happy with it too. I'll apply for 4.16. >> >> Hum, just to be sure I understand the process. Which branch are you >> talking about: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git > > I was referring to upstream-sfr.git branch=mips-next-test > https://git.linux-mips.org/cgit/ralf/upstream-sfr.git/log/?h=mips-next-test > > (The mips-next branch there is what Ralf puts into linux-next) > > I've applied the patch to my mips-fixes branch here: > git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git > > Sorry it seems a bit haphazard with multiple trees in use. I see it now, sorry for the noise. I was not looking at the right location. Anyway if that answer earlier question 4.11 should be correct, since I asked Greg to not backport the earlier patch: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1505915.html

7 years, 4 months

1
0
0 0

[Linux-stable-mirror] [PATCH] KVM: prevent overlap between user and private memslots

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Memslots must not overlap in guest physical memory, since otherwise some guest physical addresses will not uniquely map to a memslot. Yet, the overlap check in __kvm_set_memory_region() allows a memslot that overlaps one of the "private" memslots, e.g. the memslot reserved for the TSS on x86. This seems to be a very old bug that was introduced years ago when private memory slots were first added. It seems that later refactoring incorrectly assumed this bug was intentional and preserved it. Fix it by removing the loophole for private memslots, so we just check for overlap against all memslots. This bug was found by syzkaller, which used a memslot overlap to make pte_list_remove() be called for the wrong memslot, hitting a BUG(): pte_list_remove: 000000007185ed42 0->BUG kernel BUG at arch/x86/kvm/mmu.c:1209! [...] RIP: 0010:pte_list_remove+0x107/0x110 arch/x86/kvm/mmu.c:1208 [...] Call Trace: mmu_page_zap_pte+0x7e/0xd0 arch/x86/kvm/mmu.c:2499 kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2521 [inline] kvm_mmu_prepare_zap_page+0x4f/0x340 arch/x86/kvm/mmu.c:2565 kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5348 [inline] kvm_mmu_invalidate_zap_all_pages+0xa6/0x100 arch/x86/kvm/mmu.c:5389 kvm_mmu_notifier_release+0x4f/0x80 arch/x86/kvm/../../../virt/kvm/kvm_main.c:468 __mmu_notifier_release+0x63/0x100 mm/mmu_notifier.c:75 mmu_notifier_release include/linux/mmu_notifier.h:244 [inline] exit_mmap+0x160/0x170 mm/mmap.c:3009 __mmput kernel/fork.c:966 [inline] mmput+0x44/0xd0 kernel/fork.c:987 exit_mm kernel/exit.c:544 [inline] do_exit+0x24a/0xb50 kernel/exit.c:856 do_group_exit+0x34/0xb0 kernel/exit.c:972 SYSC_exit_group kernel/exit.c:983 [inline] SyS_exit_group+0xb/0x10 kernel/exit.c:981 entry_SYSCALL_64_fastpath+0x1e/0x8b Reproducer: #include <fcntl.h> #include <linux/kvm.h> #include <sys/ioctl.h> int main() { static char buf[4096*3] __attribute__((aligned(4096))); int kvm, vm, cpu; struct kvm_mp_state mp_state = { KVM_MP_STATE_SIPI_RECEIVED }; struct kvm_userspace_memory_region memreg = { .memory_size = sizeof(buf), .userspace_addr = (__u64)buf, }; kvm = open("/dev/kvm", O_RDWR); vm = ioctl(kvm, KVM_CREATE_VM, 0); ioctl(vm, KVM_CREATE_IRQCHIP); cpu = ioctl(vm, KVM_CREATE_VCPU, 0); ioctl(cpu, KVM_SET_MP_STATE, &mp_state); ioctl(vm, KVM_SET_TSS_ADDR, 0); ioctl(cpu, KVM_RUN, 0); ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg); } Reported-by: syzbot <syzkaller(a)googlegroups.com> Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots") Cc: <stable(a)vger.kernel.org> # v2.6.25+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- virt/kvm/kvm_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 210bf820385a..e536977e7b6d 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm *kvm, /* Check for overlaps */ r = -EEXIST; kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) { - if ((slot->id >= KVM_USER_MEM_SLOTS) || - (slot->id == id)) + if (slot->id == id) continue; if (!((base_gfn + npages <= slot->base_gfn) || (base_gfn >= slot->base_gfn + slot->npages))) -- 2.16.0

7 years, 4 months

3
6
0 0

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

by Mathieu Malaterre

James, On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan(a)kernel.org> wrote: > On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote: >> On Thu, Feb 1, 2018 at 1:12 PM, Mathieu Malaterre <malat(a)debian.org> wrote: >> > On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski >> > <marcin.nowakowski(a)mips.com> wrote: >> >> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a >> >> fix to ensure that the memory range between PHYS_OFFSET and low memory >> >> address specified by mem= cmdline argument is not later processed by >> >> free_all_bootmem. This change was incorrect for systems where the >> >> commandline specifies more than 1 mem argument, as it will cause all >> >> memory between PHYS_OFFSET and each of the memory offsets to be marked >> >> as reserved, which results in parts of the RAM marked as reserved >> >> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0 >> >> mem=768M@0x30000000'). >> >> >> >> Change the behaviour to ensure that only the range between PHYS_OFFSET >> >> and the lowest start address of the memories is marked as protected. >> >> >> >> This change also ensures that the range is marked protected even if it's >> >> only defined through the devicetree and not only via commandline >> >> arguments. >> >> >> >> Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com> >> >> Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)mips.com> >> >> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") >> >> Cc: <stable(a)vger.kernel.org> # v4.11+ >> >> --- >> >> v3: Update stable version, code cleanup as suggested by James Hogan >> >> v2: Use updated email adress, add tag for stable. >> >> --- >> >> arch/mips/kernel/setup.c | 16 ++++++++++++---- >> >> 1 file changed, 12 insertions(+), 4 deletions(-) >> >> >> >> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c >> >> index 702c678de116..e4a1581ce822 100644 >> >> --- a/arch/mips/kernel/setup.c >> >> +++ b/arch/mips/kernel/setup.c >> >> @@ -375,6 +375,7 @@ static void __init bootmem_init(void) >> >> unsigned long reserved_end; >> >> unsigned long mapstart = ~0UL; >> >> unsigned long bootmap_size; >> >> + phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX; >> >> bool bootmap_valid = false; >> >> int i; >> >> >> >> @@ -395,7 +396,8 @@ static void __init bootmem_init(void) >> >> max_low_pfn = 0; >> >> >> >> /* >> >> - * Find the highest page frame number we have available. >> >> + * Find the highest page frame number we have available >> >> + * and the lowest used RAM address >> >> */ >> >> for (i = 0; i < boot_mem_map.nr_map; i++) { >> >> unsigned long start, end; >> >> @@ -407,6 +409,8 @@ static void __init bootmem_init(void) >> >> end = PFN_DOWN(boot_mem_map.map[i].addr >> >> + boot_mem_map.map[i].size); >> >> >> >> + ramstart = min(ramstart, boot_mem_map.map[i].addr); >> >> + >> >> #ifndef CONFIG_HIGHMEM >> >> /* >> >> * Skip highmem here so we get an accurate max_low_pfn if low >> >> @@ -436,6 +440,13 @@ static void __init bootmem_init(void) >> >> mapstart = max(reserved_end, start); >> >> } >> >> >> >> + /* >> >> + * Reserve any memory between the start of RAM and PHYS_OFFSET >> >> + */ >> >> + if (ramstart > PHYS_OFFSET) >> >> + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET, >> >> + BOOT_MEM_RESERVED); >> >> + >> >> if (min_low_pfn >= max_low_pfn) >> >> panic("Incorrect memory mapping !!!"); >> >> if (min_low_pfn > ARCH_PFN_OFFSET) { >> >> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p) >> >> >> >> add_memory_region(start, size, BOOT_MEM_RAM); >> >> >> >> - if (start && start > PHYS_OFFSET) >> >> - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET, >> >> - BOOT_MEM_RESERVED); >> >> return 0; >> >> } >> >> early_param("mem", early_parse_mem); >> >> -- >> >> 2.14.1 >> >> >> > >> > Looks good to me: >> > >> > $ cat /proc/cpuinfo >> > system type : JZ4780 >> > machine : Creator CI20 >> > processor : 0 >> > cpu model : Ingenic JZRISC V4.15 FPU V0.0 >> > BogoMIPS : 956.00 >> > wait instruction : yes >> > microsecond timers : no >> > tlb_entries : 32 >> > extra interrupt vector : yes >> > hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff] >> > isa : mips1 mips2 mips32r1 mips32r2 >> > ASEs implemented : >> > shadow register sets : 1 >> > kscratch registers : 0 >> > package : 0 >> > core : 0 >> > VCED exceptions : not available >> > VCEI exceptions : not available >> > $ uname -a >> > Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux >> > >> > Tested-by: Mathieu Malaterre <malat(a)debian.org> >> > >> > Thanks >> >> Could you please review the patch v3 ? > > Yes, looks good to me, and Ralf had applied to his test branch so I > presume he's happy with it too. I'll apply for 4.16. Hum, just to be sure I understand the process. Which branch are you talking about: https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git > Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") which > this fixes was evidently requested to be backported to stable (unsure > who by) and added to the 4.9 queue, but then this arose and it was > removed until this fix is merged (see > https://patchwork.linux-mips.org/patch/17268/). > > Anybody know how far back before 4.11 both of these patches should be > applied to stable? If not I'll just leave it at 4.11 and if its > important before then for kexec or whatever they can be requested again.

7 years, 4 months

1
0
0 0

v4.14.19 build: 0 failures 0 warnings (v4.14.19)

by Build bot for Mark Brown

Tree/Branch: v4.14.19 Git describe: v4.14.19 Commit: 1722fe3727 Linux 4.14.19 Build Time: 109 min 6 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror