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

Re: PROBLEM: brcmfmac driver crashes on resuming if no firmware is loaded

by Jon Hunter

Correcting stable address ... On 12/10/18 13:37, Jon Hunter wrote: > [1.] One line summary of the problem: > brcmfmac driver crashes on resuming if no firmware is loaded > > [2.] Full description of the problem/report: > In stable-v4.4, if the brcmfmac driver fails to load the required > firmware on boot for an SDIO based device, then the driver fails > to remove one of the two devices it registered during probe with > the kernel. If the kernel then enters suspend, on resume the > kernel tries to resume the device registered by brcmfmac driver > and crashes due to a NULL pointer deference (see 6 below). > > This issue is seen in stable-v4.4 but not in stable-v4.9 and I > believe is fixed by commit 7a51461fc2da ("brcmfmac: unbind all > devices upon failure in firmware callback"). Unfortunately, this > fix is dependent on other changes and so is not easily > back-ported AFAICT. > > This issue is seen on Tegra20 Ventana and Tegra30 Cardhu. > > [3.] Keywords (i.e., modules, networking, kernel): > BROADCOM BRCM80211 > > [4.] Kernel information > [4.1.] Kernel version (from /proc/version): > Linux version 4.4.160-rc1-00116-g5826f1d1ce56 > [4.2.] Kernel .config file: > Generated using tegra_defconfig > > [5.] Most recent kernel version which did not have the bug: > Not seen in current mainline or -next. > > [6.] Output of Oops.. message (if applicable) with symbolic information > > [ 51.941094] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > [ 51.949836] pgd = eee54000 > > [ 51.952771] [00000000] *pgd=2db16831, *pte=00000000, *ppte=00000000 > > [ 51.959722] Internal error: Oops: 17 [#1] SMP ARM > > [ 51.964774] Modules linked in: snd_soc_tegra_wm8903 snd_soc_wm8903 snd_soc_tegra_utils snd_soc_core snd_pcm_dmaengine snd_pcm brcmfmac brcmutil cfg80211 snd_timer snd soundcore ac97_bus snd_soc_tegra20_das > > [ 51.984922] CPU: 1 PID: 512 Comm: rtcwake Not tainted 4.4.160-rc1-00116-g5826f1d1ce56 #1 > > [ 51.993577] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) > > [ 52.000303] task: eefa3900 ti: ed93c000 task.ti: ed93c000 > > [ 52.006294] PC is at brcmf_ops_sdio_resume+0x10/0x5c [brcmfmac] > > [ 52.012672] LR is at pm_generic_resume+0x2c/0x38 > > [ 52.017641] pc : [<bf12bbb8>] lr : [<c06502d4>] psr: 60000113 > > [ 52.017641] sp : ed93ddb8 ip : eed72e74 fp : c0f4a2d8 > > [ 52.029914] r10: c0fa7580 r9 : 00000010 r8 : 00000000 > > [ 52.035522] r7 : 00000010 r6 : eed7303c r5 : 00000001 r4 : c06502a8 > > [ 52.042514] r3 : 00000000 r2 : 00000002 r1 : eed73008 r0 : eed73008 > > [ 52.049511] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > [ 52.057156] Control: 10c5387d Table: 2ee5404a DAC: 00000051 > > [ 52.063319] Process rtcwake (pid: 512, stack limit = 0xed93c220) > > [ 52.069761] Stack: (0xed93ddb8 to 0xed93e000) > > [ 52.074450] dda0: c06502a8 c06502d4 > > [ 52.083225] ddc0: c0cae914 c0653674 17c10408 c027fc00 eed72e08 eed73008 00000001 c0653cdc > > [ 52.091993] dde0: eed73070 eed73008 c0fa7548 c0fa7578 c104ce7c c0655018 c0f4a2d8 c0654ee8 > > [ 52.100757] de00: 0ea73a40 0000000c 0ea73a40 0000000c 0e3050d8 00000010 00000003 00000000 > > [ 52.109529] de20: c0f1650c c10109f4 c0f170a4 00000000 00000000 c06552e8 c10109f4 c02870b0 > > [ 52.118399] de40: 00000000 c028a464 c0d3b71c ed93de6c c0f49314 c02cd350 00000003 c10109f4 > > [ 52.127166] de60: 00000003 00000000 00000003 edbb45c0 00000004 00000000 00000000 c0287540 > > [ 52.135933] de80: 00000003 c0c8401c c1010a04 c02862fc 00000004 ee8f86e0 edbb45c0 edbb4fcc > > [ 52.144698] dea0: 00000004 ed93df80 00028290 c048c684 00000004 c036dec8 c036de84 edbb4fc0 > > [ 52.169613] dec0: edbb45c0 c036d70c 00000000 00000000 000081a4 c0a0113c 00028290 eee13b40 > > [ 52.194484] dee0: ed93df80 00000004 00028290 00000000 00000005 c030f990 c0f1ba64 ed93dfb0 > > [ 52.219219] df00: 00002710 000001ff b6fb42e4 c020a29c 5a9fd343 0b532b80 5a9fd343 0b532b80 > > [ 52.244031] df20: 0000050e 00000000 eee13b40 becb54b8 00028128 00028128 000000c5 eee13b40 > > [ 52.268893] df40: eee13b40 00028290 ed93df80 00000004 00000004 c031018c 0000000f 000081a4 > > [ 52.293765] df60: 00000001 00000000 00000000 eee13b40 eee13b40 00000004 00028290 c0310994 > > [ 52.318818] df80: 00000000 00000000 5a9fd343 00000004 00028290 00028128 00000004 c0210c44 > > [ 52.343980] dfa0: ed93c000 c0210a80 00000004 00028290 00000004 00028290 00000004 00000000 > > [ 52.369292] dfc0: 00000004 00028290 00028128 00000004 00014f40 00026180 00014ca4 00000005 > > [ 52.394701] dfe0: 00000000 becb5a1c b6f3479b b6f700d6 000f0030 00000004 00000000 00000000 > > [ 52.420294] [<bf12bbb8>] (brcmf_ops_sdio_resume [brcmfmac]) from [<c06502d4>] (pm_generic_resume+0x2c/0x38) > > [ 52.447649] [<c06502d4>] (pm_generic_resume) from [<c0653674>] (dpm_run_callback+0x1c/0x58) > > [ 52.474009] [<c0653674>] (dpm_run_callback) from [<c0653cdc>] (device_resume+0x98/0x260) > > [ 52.500177] [<c0653cdc>] (device_resume) from [<c0655018>] (dpm_resume+0x100/0x228) > > [ 52.525931] [<c0655018>] (dpm_resume) from [<c06552e8>] (dpm_resume_end+0xc/0x18) > > [ 52.551807] [<c06552e8>] (dpm_resume_end) from [<c02870b0>] (suspend_devices_and_enter+0x124/0x420) > > [ 52.579701] [<c02870b0>] (suspend_devices_and_enter) from [<c0287540>] (pm_suspend+0x194/0x254) > > [ 52.607599] [<c0287540>] (pm_suspend) from [<c02862fc>] (state_store+0x6c/0xbc) > > [ 52.634364] [<c02862fc>] (state_store) from [<c048c684>] (kobj_attr_store+0x14/0x20) > > [ 52.661518] [<c048c684>] (kobj_attr_store) from [<c036dec8>] (sysfs_kf_write+0x44/0x48) > > [ 52.688909] [<c036dec8>] (sysfs_kf_write) from [<c036d70c>] (kernfs_fop_write+0xbc/0x1b0) > > [ 52.716566] [<c036d70c>] (kernfs_fop_write) from [<c030f990>] (__vfs_write+0x24/0xd8) > > [ 52.743917] [<c030f990>] (__vfs_write) from [<c031018c>] (vfs_write+0x94/0x154) > > [ 52.770230] [<c031018c>] (vfs_write) from [<c0310994>] (SyS_write+0x40/0x94) > > [ 52.795713] [<c0310994>] (SyS_write) from [<c0210a80>] (ret_fast_syscall+0x0/0x48) > > [ 52.821478] Code: e92d4010 e590218c e5903058 e3520002 (e5934000) > > [ 52.845762] ---[ end trace d797b5b1ce195377 ]--- > -- nvpublic

6 years, 10 months

1
0
0 0

Re: [PATCH 4.4 00/27] 4.4.161-stable review

by Greg Kroah-Hartman

On Thu, Oct 11, 2018 at 03:22:11PM -0700, kernelci.org bot wrote: > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.160-28-… > > Tree: stable-rc > Branch: linux-4.4.y > Git Describe: v4.4.160-28-gb3522afcec59 > Git Commit: b3522afcec59a6a8030ebf4397f5b285b3e804d2 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 39 unique boards, 20 SoC families, 13 builds out of 178 > > Boot Regressions Detected: > > x86: > > x86_64_defconfig: > qemu: > lab-baylibre: new failure (last pass: v4.4.160) Should I worry about this? thanks, greg k-h

6 years, 10 months

2
1
0 0

URGENT RESPONSE NEEDED

by Sean Kim.

Hello my dear. Did you receive my email message to you? Please, get back to me ASAP as the matter is becoming late. Expecting your urgent response. Sean.

6 years, 10 months

1
0
0 0

[PATCH] ALSA: hda - Add mic quirk for the Lenovo G50-30 (17aa:3905)

by Jeremy Cline

The Lenovo G50-30, like other G50 models, has a Conexant codec that requires a quirk for its inverted stereo dmic. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1249364 Reported-by: Alexander Ploumistos <alex.ploumistos(a)gmail.com> Tested-by: Alexander Ploumistos <alex.ploumistos(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Jeremy Cline <jcline(a)redhat.com> --- sound/pci/hda/patch_conexant.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 5592557fe50e..950e02e71766 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -943,6 +943,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = { SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD), + SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC), -- 2.19.1

6 years, 10 months

2
1
0 0

[RESEND][PATCH 4.4-stable] jffs2: return -ERANGE when xattr buffer is too small

by Hou Tao

When a file have multiple xattrs and the passed buffer is smaller than the required size, jffs2_listxattr() should return -ERANGE instead of continue, else Oops may occur due to memory corruption. Also remove the unnecessary check ("rc < 0"), because xhandle->list(...) will not return an error number. Spotted by generic/377 in xfstests-dev. NB: The problem had been fixed by commit 764a5c6b1fa4 ("xattr handlers: Simplify list operation") in v4.5-rc1, but the modification in that commit may be too much because it modifies all file-systems which implement xattr, so I create a single patch for jffs2 to fix the problem. Signed-off-by: Hou Tao <houtao1(a)huawei.com> --- fs/jffs2/xattr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/jffs2/xattr.c b/fs/jffs2/xattr.c index 4c2c03663533..8e1427762eeb 100644 --- a/fs/jffs2/xattr.c +++ b/fs/jffs2/xattr.c @@ -1004,12 +1004,14 @@ ssize_t jffs2_listxattr(struct dentry *dentry, char *buffer, size_t size) rc = xhandle->list(xhandle, dentry, buffer + len, size - len, xd->xname, xd->name_len); + if (rc > size - len) { + rc = -ERANGE; + goto out; + } } else { rc = xhandle->list(xhandle, dentry, NULL, 0, xd->xname, xd->name_len); } - if (rc < 0) - goto out; len += rc; } rc = len; -- 2.16.2.dirty

6 years, 10 months

1
0
0 0

Fwd: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)

by salil GK

I was looking for fix for CVE-2018-5390 and CVE-2018-5390) in 4.18.x. Will these fix be available in 4.18 train ? PS: Sorry for sending again - I got a rejection message as my previous message contains html tags ! Thanks ~S On Oct 11, 2018 7:38 PM, "Greg KH" <gregkh(a)linux-foundation.org> wrote: On Wed, Sep 26, 2018 at 10:21:21PM +0200, Greg KH wrote: > On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote: > > Hi Greg: > > > > can you review this patch set? > > It is still in the queue, don't worry. It will take some more time to > properly review and test it. > > Ideally you could get someone else to test this and provide a > "tested-by:" tag for it? All now queued up, let's see what breaks :) thanks, greg k-h

6 years, 10 months

1
0
0 0

Re: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)

by maowenan

On 2018/10/12 10:28, salil GK wrote: > I was looking for fix for CVE-2018-5390 and CVE-2018-5390) in 4.18.x. Will these fix be available in 4.18 train ? The fixes of CVE-2018-5390 have already existed in stable 4.18. These fixes only available with < 4.9 that don't using RB tree. 58152ec tcp: add tcp_ooo_try_coalesce() helper 8541b21 tcp: call tcp_drop() from tcp_data_queue_ofo() 3d4bf93 tcp: detect malicious patterns in tcp_collapse_ofo_queue() f4a3313 tcp: avoid collapses in tcp_prune_queue() if possible 72cd43b tcp: free batches of packets in tcp_prune_ofo_queue() > > Thanks > ~S > > On Oct 11, 2018 7:38 PM, "Greg KH" <gregkh(a)linux-foundation.org <mailto:gregkh@linux-foundation.org>> wrote: > > On Wed, Sep 26, 2018 at 10:21:21PM +0200, Greg KH wrote: > > On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote: > > > Hi Greg: > > > > > > can you review this patch set? > > > > It is still in the queue, don't worry. It will take some more time to > > properly review and test it. > > > > Ideally you could get someone else to test this and provide a > > "tested-by:" tag for it? > > All now queued up, let's see what breaks :) > > thanks, > > greg k-h > >

6 years, 10 months

1
0
0 0

[PATCH AUTOSEL 4.18 01/58] soundwire: Fix duplicate stream state assignment

by Sasha Levin

From: Shreyas NC <shreyas.nc(a)intel.com> [ Upstream commit 0aebe40bae6cf5652fdc3d05ecee15fbf5748194 ] For a SoundWire stream it is expected that a Slave is added to the stream before Master is added. So, move the stream state to CONFIGURED after the first Slave is added and remove the stream state assignment for Master add. Along with these changes, add additional comments to explain the same. Signed-off-by: Shreyas NC <shreyas.nc(a)intel.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/soundwire/stream.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 4b5e250e8615..7ba6d4d8cd03 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1123,8 +1123,6 @@ int sdw_stream_add_master(struct sdw_bus *bus, if (ret) goto stream_error; - stream->state = SDW_STREAM_CONFIGURED; - stream_error: sdw_release_master_stream(stream); error: @@ -1141,6 +1139,10 @@ EXPORT_SYMBOL(sdw_stream_add_master); * @stream: SoundWire stream * @port_config: Port configuration for audio stream * @num_ports: Number of ports + * + * It is expected that Slave is added before adding Master + * to the Stream. + * */ int sdw_stream_add_slave(struct sdw_slave *slave, struct sdw_stream_config *stream_config, @@ -1186,6 +1188,12 @@ int sdw_stream_add_slave(struct sdw_slave *slave, if (ret) goto stream_error; + /* + * Change stream state to CONFIGURED on first Slave add. + * Bus is not aware of number of Slave(s) in a stream at this + * point so cannot depend on all Slave(s) to be added in order to + * change stream state to CONFIGURED. + */ stream->state = SDW_STREAM_CONFIGURED; goto error; -- 2.17.1

6 years, 10 months

5
75
0 0

[PATCH 4/6] ocfs2: fix locking for res->tracking and dlm->tracking_list

by Rodrigo Vivi

From: Ashish Samant <ashish.samant(a)oracle.com> In dlm_init_lockres() we access and modify res->tracking and dlm->tracking_list without holding dlm->track_lock. This can cause list corruptions and can end up in kernel panic. Fix this by locking res->tracking and dlm->tracking_list with dlm->track_lock instead of dlm->spinlock. Link: http://lkml.kernel.org/r/1529951192-4686-1-git-send-email-ashish.samant@ora… Signed-off-by: Ashish Samant <ashish.samant(a)oracle.com> Reviewed-by: Changwei Ge <ge.changwei(a)h3c.com> Acked-by: Joseph Qi <jiangqi903(a)gmail.com> Acked-by: Jun Piao <piaojun(a)huawei.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/ocfs2/dlm/dlmmaster.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c index aaca0949fe53..826f0567ec43 100644 --- a/fs/ocfs2/dlm/dlmmaster.c +++ b/fs/ocfs2/dlm/dlmmaster.c @@ -584,9 +584,9 @@ static void dlm_init_lockres(struct dlm_ctxt *dlm, res->last_used = 0; - spin_lock(&dlm->spinlock); + spin_lock(&dlm->track_lock); list_add_tail(&res->tracking, &dlm->tracking_list); - spin_unlock(&dlm->spinlock); + spin_unlock(&dlm->track_lock); memset(res->lvb, 0, DLM_LVB_LEN); memset(res->refmap, 0, sizeof(res->refmap)); -- 2.17.1

6 years, 10 months

1
0
0 0

[PATCH 2/6] mm/vmstat.c: skip NR_TLB_REMOTE_FLUSH* properly

by Rodrigo Vivi

From: Jann Horn <jannh(a)google.com> 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP") made the availability of the NR_TLB_REMOTE_FLUSH* counters inside the kernel unconditional to reduce #ifdef soup, but (either to avoid showing dummy zero counters to userspace, or because that code was missed) didn't update the vmstat_array, meaning that all following counters would be shown with incorrect values. This only affects kernel builds with CONFIG_VM_EVENT_COUNTERS=y && CONFIG_DEBUG_TLBFLUSH=y && CONFIG_SMP=n. Link: http://lkml.kernel.org/r/20181001143138.95119-2-jannh@google.com Fixes: 5dd0b16cdaff ("mm/vmstat: Make NR_TLB_REMOTE_FLUSH_RECEIVED available even on UP") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Kees Cook <keescook(a)chromium.org> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: Roman Gushchin <guro(a)fb.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Christoph Lameter <clameter(a)sgi.com> Cc: Kemi Wang <kemi.wang(a)intel.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/vmstat.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/vmstat.c b/mm/vmstat.c index 4cea7b8f519d..7878da76abf2 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1275,6 +1275,9 @@ const char * const vmstat_text[] = { #ifdef CONFIG_SMP "nr_tlb_remote_flush", "nr_tlb_remote_flush_received", +#else + "", /* nr_tlb_remote_flush */ + "", /* nr_tlb_remote_flush_received */ #endif /* CONFIG_SMP */ "nr_tlb_local_flush_all", "nr_tlb_local_flush_one", -- 2.17.1

6 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror