Hello Greg,
Can you please consider including the following patch in the stable
linux-4.14.y branch? This is to fix a broken dependency for config option
CONFIG_CIFS_POSIX
04f67ed3d83a ("cifs: allow disabling insecure dialects in the config")
Following commit introduced a dependency for CONFIG_CIFS_POSIX on the config
CONFIG_CIFS_ALLOW_INSECURE_LEGACY, but the above mentioned commit that had
enable CONFIG_CIFS_POSIX in 4.14.94.
ab9697222a1d ("cifs: In Kconfig CONFIG_CIFS_POSIX needs depends …
[View More]on legacy
(insecure cifs)")
Regards
-Alakesh Haloi
[View Less]
From: Corey Minyard <cminyard(a)mvista.com>
Date: Thu, 15 Feb 2018 16:58:26 -0600
[ upstream commit bc48fa1b9d3b04106055b27078da824cd209865a ]
Realtek has some sort of "Virtual" IPMI device on the PCI bus as a
KCS controller, but whatever it is, it's not one. Ignore it if seen.
Reported-by: Chris Chiu <chiu(a)endlessm.com>
Signed-off-by: Corey Minyard <cminyard(a)mvista.com>
Tested-by: Daniel Drake <drake(a)endlessm.com>
[ Commit 13d0b35c (ipmi_si: Move PCI setup to …
[View More]another file) from Linux
4.15-rc1 has not been back ported, so the PCI code is still in
`drivers/char/ipmi/ipmi_si_intf.c`, requiring to apply the commit
manually.
This fixes a 100 s boot delay on the HP EliteDesk 705 G4 MT with Linux
4.14.94. ]
Signed-off-by: Paul Menzel <pmenzel(a)molgen.mpg.de>
---
drivers/char/ipmi/ipmi_si_intf.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index c04aa11f0e21..6d18f8090cea 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2447,6 +2447,15 @@ static int ipmi_pci_probe_regspacing(struct smi_info *info)
return DEFAULT_REGSPACING;
}
+static struct pci_device_id ipmi_pci_blacklist[] = {
+ /*
+ * This is a "Virtual IPMI device", whatever that is. It appears
+ * as a KCS device by the class, but it is not one.
+ */
+ { PCI_VDEVICE(REALTEK, 0x816c) },
+ { 0, }
+};
+
static int ipmi_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -2454,6 +2463,9 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
int class_type = pdev->class & PCI_ERMC_CLASSCODE_TYPE_MASK;
struct smi_info *info;
+ if (pci_match_id(ipmi_pci_blacklist, pdev))
+ return -ENODEV;
+
info = smi_info_alloc();
if (!info)
return -ENOMEM;
--
2.17.1
[View Less]
From: Scott Mayhew <smayhew(a)redhat.com>
The following deadlock can occur between a process waiting for a client
to initialize in while walking the client list during nfsv4 server trunking
detection and another process waiting for the nfs_clid_init_mutex so it
can initialize that client:
Process 1 Process 2
--------- ---------
spin_lock(&nn->nfs_client_lock);
list_add_tail(&CLIENTA->cl_share_link,
&nn-…
[View More]>nfs_client_list);
spin_unlock(&nn->nfs_client_lock);
spin_lock(&nn->nfs_client_lock);
list_add_tail(&CLIENTB->cl_share_link,
&nn->nfs_client_list);
spin_unlock(&nn->nfs_client_lock);
mutex_lock(&nfs_clid_init_mutex);
nfs41_walk_client_list(clp, result, cred);
nfs_wait_client_init_complete(CLIENTA);
(waiting for nfs_clid_init_mutex)
Make sure nfs_match_client() only evaluates clients that have completed
initialization in order to prevent that deadlock.
This patch also fixes v4.0 trunking behavior by not marking the client
NFS_CS_READY until the clientid has been confirmed.
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Qian Lu <luqia(a)amazon.com>
---
fs/nfs/client.c | 11 +++++++++++
fs/nfs/nfs4client.c | 17 +++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 22880ef6d8dd..7d6ddfd60271 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -291,12 +291,23 @@ static struct nfs_client *nfs_match_client(const struct nfs_client_initdata *dat
const struct sockaddr *sap = data->addr;
struct nfs_net *nn = net_generic(data->net, nfs_net_id);
+again:
list_for_each_entry(clp, &nn->nfs_client_list, cl_share_link) {
const struct sockaddr *clap = (struct sockaddr *)&clp->cl_addr;
/* Don't match clients that failed to initialise properly */
if (clp->cl_cons_state < 0)
continue;
+ /* If a client is still initializing then we need to wait */
+ if (clp->cl_cons_state > NFS_CS_READY) {
+ atomic_inc(&clp->cl_count);
+ spin_unlock(&nn->nfs_client_lock);
+ nfs_wait_client_init_complete(clp);
+ nfs_put_client(clp);
+ spin_lock(&nn->nfs_client_lock);
+ goto again;
+ }
+
/* Different NFS versions cannot share the same nfs_client */
if (clp->rpc_ops != data->nfs_mod->rpc_ops)
continue;
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index fed9c8005c17..8f96f6548dc8 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -404,15 +404,19 @@ struct nfs_client *nfs4_init_client(struct nfs_client *clp,
if (error < 0)
goto error;
- if (!nfs4_has_session(clp))
- nfs_mark_client_ready(clp, NFS_CS_READY);
-
error = nfs4_discover_server_trunking(clp, &old);
if (error < 0)
goto error;
- if (clp != old)
+ if (clp != old) {
clp->cl_preserve_clid = true;
+ /*
+ * Mark the client as having failed initialization so other
+ * processes walking the nfs_client_list in nfs_match_client()
+ * won't try to use it.
+ */
+ nfs_mark_client_ready(clp, -EPERM);
+ }
nfs_put_client(clp);
clear_bit(NFS_CS_TSM_POSSIBLE, &clp->cl_flags);
return old;
@@ -539,6 +543,9 @@ int nfs40_walk_client_list(struct nfs_client *new,
spin_lock(&nn->nfs_client_lock);
list_for_each_entry(pos, &nn->nfs_client_list, cl_share_link) {
+ if (pos == new)
+ goto found;
+
status = nfs4_match_client(pos, new, &prev, nn);
if (status < 0)
goto out_unlock;
@@ -559,6 +566,7 @@ int nfs40_walk_client_list(struct nfs_client *new,
* way that a SETCLIENTID_CONFIRM to pos can succeed is
* if new and pos point to the same server:
*/
+found:
atomic_inc(&pos->cl_count);
spin_unlock(&nn->nfs_client_lock);
@@ -572,6 +580,7 @@ int nfs40_walk_client_list(struct nfs_client *new,
case 0:
nfs4_swap_callback_idents(pos, new);
pos->cl_confirm = new->cl_confirm;
+ nfs_mark_client_ready(pos, NFS_CS_READY);
prev = NULL;
*result = pos;
--
2.15.3.AMZN
[View Less]
Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache
for kernel mappings") was aimed at fixing the I-cache invalidation for
kernel mappings. However, it inadvertently caused all cache maintenance
for user mappings via set_pte_at() -> __sync_icache_dcache() ->
sync_icache_aliases() to call kick_all_cpus_sync().
Reported-by: Shijith Thotton <sthotton(a)marvell.com>
Tested-by: Shijith Thotton <sthotton(a)marvell.com>
Reported-by: Wandun Chen <chenwandun(a)…
[View More]huawei.com>
Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
Cc: <stable(a)vger.kernel.org> # 4.19.x-
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
---
Hi Will,
You acked the previous inlined patch but I think that's a better option
to revert the kernel behaviour w.r.t. user mapping to that prior to
commit 3b8c9f1cdfc5.
If you plan a pull request for 5.0-rc4, please pick this up as well.
Thanks.
arch/arm64/mm/flush.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index 30695a868107..5c9073bace83 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -33,7 +33,11 @@ void sync_icache_aliases(void *kaddr, unsigned long len)
__clean_dcache_area_pou(kaddr, len);
__flush_icache_all();
} else {
- flush_icache_range(addr, addr + len);
+ /*
+ * Don't issue kick_all_cpus_sync() after I-cache invalidation
+ * for user mappings.
+ */
+ __flush_icache_range(addr, addr + len);
}
}
[View Less]
From: Eric Biggers <ebiggers(a)google.com>
The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
skcipher tests because it sometimes produces the wrong ciphertext. The
bug is that the final keystream block isn't returned from the assembly
code when the number of non-final blocks is zero. This can happen if
the input data ends a few bytes after a page boundary. In this case the
last bytes get "encrypted" by XOR'ing them with uninitialized memory.
Fix the assembly code …
[View More]to return the final keystream block when needed.
Fixes: 88a3f582bea9 ("crypto: arm64/aes - don't use IV buffer to return final keystream block")
Cc: <stable(a)vger.kernel.org> # v4.11+
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
arch/arm64/crypto/aes-neonbs-core.S | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-core.S b/arch/arm64/crypto/aes-neonbs-core.S
index e613a87f8b53..8432c8d0dea6 100644
--- a/arch/arm64/crypto/aes-neonbs-core.S
+++ b/arch/arm64/crypto/aes-neonbs-core.S
@@ -971,18 +971,22 @@ CPU_LE( rev x8, x8 )
8: next_ctr v0
st1 {v0.16b}, [x24]
- cbz x23, 0f
+ cbz x23, .Lctr_done
cond_yield_neon 98b
b 99b
-0: frame_pop
+.Lctr_done:
+ frame_pop
ret
/*
* If we are handling the tail of the input (x6 != NULL), return the
* final keystream block back to the caller.
*/
+0: cbz x25, 8b
+ st1 {v0.16b}, [x25]
+ b 8b
1: cbz x25, 8b
st1 {v1.16b}, [x25]
b 8b
--
2.20.1.321.g9e740568ce-goog
[View Less]
Please let me know the status of your photos, waiting to retouching them.
Do your photos need white background? sharpen? retouching? We can do it for
you.
Send us the test photos today and we can start to work on them.
Thanks,
Denna
Hi,
On 21-01-19 06:55, Mogens Jensen wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, January 18, 2019 3:35 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
>
>> Hi,
>>
>> On 1/17/19 8:30 PM, Mogens Jensen wrote:
>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Thursday, January 17, 2019 12:05 PM, Hans de Goede hdegoede(a)redhat.com wrote:
>>>
>>>> Hi,
>>>> On 17-01-19 10:12, Dean Wallace wrote:
>…
[View More]>>>
>>>>> Hi Hans, Mogens,
>>>>> On 17-01-19, Mogens Jensen wrote:
>>>>>
>>>>>> Kernel is compiled with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH and the quirk seems to have fixed the problem caused by commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL"), as sound is now working if running "speaker-test" on my system which is clean ALSA.
>>>>
>>>> Note being "clean ALSA" is really not a good thing now a days,
>>>> for lots of things we depend on pulseaudio (like setting
>>>> up UCM mixer profiles).
>>>
>>> I'm using UCM mixer profile from:
>>> https://github.com/plbossart/UCM/tree/master/chtmax98090
>>> This is enabled with:
>>> alsaucm -c chtmax98090 set _verb HiFi set _enadev Speakers
>>>
>>>>>> Unfortunately, SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver is unusable on Clapper Chromebooks as audio played from everything but "speaker-test" as video players or web browsers is extremly low and sounds like played at 10x speed. At the same time kernel log is spammed with messages like this:
>>>>>> max98090 i2c-193C9890:00: PLL unlocked
>>>>>> intel_sst_acpi 80860F28:00: FW Version 01.0c.00.01
>>>>>> writing to lpe: 00000000: 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 ............U...
>>>>>> writing to lpe: 00000000: 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 ............u...
>>>>>> This is probably not related to the problem discussed in this thread, but the result is that I have to use the legacy driver SND_SOC_INTEL_BYT_MAX98090_MACH and therefore still has to revert commit 648e921888ad for sound to work.
>>>>>> Is it possible to create a fix for SND_SOC_INTEL_BYT_MAX98090_MACH on kernel 4.19? Kernel 4.19 is a long term release so it would be very nice to have fix for this version upstream.
>>>>>
>>>>> I have been reverting "clk: x86: Stop marking clocks as CLK_IS_CRITICAL"
>>>>> and the patch that initially added the quirk for swanky because of sound
>>>>> instability issues as you described. I'm compiling vanilla Archlinux
>>>>> kernel with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH, using pulseaudio,
>>>>> and have sound in all my apps.
>>>>> Baytrail sound has always been a little touchy, especially using headset
>>>>> with mic, but since the clk patch breaking sound and the quirk patch to
>>>>> fix it, there is a lot more instability. Just running pavucontrol, or
>>>>> plugging in headset sets it off. It's a head scratcher.
>>>>
>>>> Mogens, Dean, can you please try the SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH
>>>> driver, without reverting any patches, with the attached patch on top and
>>>> see if that helps?
>>>> Thanks & Regards,
>>>> Hans
>>>
>>> I have applied the patch to kernel 4.19.15 and unfortunately this has not solved the problems.
>>> Audio generated from "speaker-test" is normal, but from everything else is very low and played at 10x speed. However, I'm not seeing the "max98090 i2c-193C9890:00: PLL unlocked" message in kernel log anymore, but it's still spammed with "writing to lpe: ...".
>>
>> Hmm, I've a feeling the problem is your using alsa directly, do you have
>> dmix enabled ? You probably need dmix since the SST sound support
>> only supports 48KHz AFAIK.
>>
>> Can you perhaps give things a try with pulseaudio ?
>>
>> Regards,
>>
>> Hans
>
> You are absolutely correct, software mixing was apparently not enabled on my system and this caused the audio problems. I thought that dmix was enabled by default if hardware mixing was not supported. Thank you very much.
>
> I was completely wrong about "SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH driver seems to be unusable on Clapper Chromebooks". Sorry about that.
>
> To sum up, audio is working perfectly on my Clapper Chromebook running kernel 4.19.15 with SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH + "0001-ASoC-intel-cht_bsw_max98090_ti-Enable-codec-clock-on.patch", even better than before with the legacy driver.
Thank you for testing this. Given that things now work for both you and Dean I've
submitted the patch you both have tested upstream.
Regards,
Hans
[View Less]
Hi Shasha,
On 23.01.19 23:57, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: 2.6.26+
>
> The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94, v4.9.151, v4.4.171, v3.18.132.
>
> v4.20.3: Build OK!
> v4.19.16: Build OK!
> v4.14.94: Build OK!
> v4.9.151: Build OK!
> v4.4.171: Failed to …
[View More]apply! Possible dependencies:
> 2b5f5f5dc114 ("can: bcm: unify bcm_msg_head handling and prepare function parameters")
> 6f3b911d5f29 ("can: bcm: add support for CAN FD frames")
> 72c8a89ad2e4 ("can: bcm: use CAN frame instead of can_frame in comments")
> 95acb490ec51 ("can: bcm: fix indention and other minor style issues")
>
> v3.18.132: Failed to apply! Possible dependencies:
> 069f8457ae52 ("can: fix spelling errors")
> 2b5f5f5dc114 ("can: bcm: unify bcm_msg_head handling and prepare function parameters")
> 6ce8e9ce5989 ("new helper: memcpy_from_msg()")
> 6f3b911d5f29 ("can: bcm: add support for CAN FD frames")
> 72c8a89ad2e4 ("can: bcm: use CAN frame instead of can_frame in comments")
> 95acb490ec51 ("can: bcm: fix indention and other minor style issues")
> ba61a8d9d780 ("can: avoid using timeval for uapi")
>
>
> How should we proceed with this patch?
As we do have a proper upstream commit hash now ...
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git/commit/?h…
... here is the ported patch for kernels pre version 4.8:
https://marc.info/?l=linux-can&m=154832094402622&w=2
Thanks,
Oliver
ps. the pull request to Dave is still hanging here:
https://marc.info/?l=linux-can&m=154831478900596&w=2
[View Less]