The patch titled
Subject: drivers/block/zram/zram_drv.c: fix bug storing backing_dev
has been added to the -mm tree. Its filename is
zram-fix-bug-storing-backing_dev.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zram-fix-bug-storing-backing_dev.p…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zram-fix-bug-storing-backing_dev.p…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Peter Kalauskas <peskal(a)google.com>
Subject: drivers/block/zram/zram_drv.c: fix bug storing backing_dev
The call to strlcpy in backing_dev_store is incorrect. It should take
the size of the destination buffer instead of the size of the source
buffer. Additionally, ignore the newline character (\n) when reading
the new file_name buffer. This makes it possible to set the backing_dev
as follows:
echo /dev/sdX > /sys/block/zram0/backing_dev
The reason it worked before was the fact that strlcpy() copies 'len - 1'
bytes, which is strlen(buf) - 1 in our case, so it accidentally didn't
copy the trailing new line symbol. Which also means that "echo -n
/dev/sdX" most likely was broken.
Signed-off-by: Peter Kalauskas <peskal(a)google.com>
Link: http://lkml.kernel.org/r/20180813061623.GC64836@rodete-desktop-imager.corp.…
Acked-by: Minchan Kim <minchan(a)kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/block/zram/zram_drv.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/block/zram/zram_drv.c~zram-fix-bug-storing-backing_dev
+++ a/drivers/block/zram/zram_drv.c
@@ -337,6 +337,7 @@ static ssize_t backing_dev_store(struct
struct device_attribute *attr, const char *buf, size_t len)
{
char *file_name;
+ size_t sz;
struct file *backing_dev = NULL;
struct inode *inode;
struct address_space *mapping;
@@ -357,7 +358,11 @@ static ssize_t backing_dev_store(struct
goto out;
}
- strlcpy(file_name, buf, len);
+ strlcpy(file_name, buf, PATH_MAX);
+ /* ignore trailing newline */
+ sz = strlen(file_name);
+ if (sz > 0 && file_name[sz - 1] == '\n')
+ file_name[sz - 1] = 0x00;
backing_dev = filp_open(file_name, O_RDWR|O_LARGEFILE, 0);
if (IS_ERR(backing_dev)) {
_
Patches currently in -mm which might be from peskal(a)google.com are
zram-fix-bug-storing-backing_dev.patch
These patches are needed for kasan+clang support. I confirmed they
apply cleanly in order (top to bottom):
4.9:
commit c5caf21ab0cf8 ("kasan: turn on -fsanitize-address-use-after-scope")
commit 0e410e158e5b ("kasan: don't emit builtin calls when sanitization is off")
4.4:
commit c5caf21ab0cf8 ("kasan: turn on -fsanitize-address-use-after-scope")
===
0e410e158e5b is the one I'm interested in. Looks like it landed in
4.16, and got backported to 4.14-stable.
===
c5caf21ab0cf8 depends on c6d308534aef6 ("UBSAN: run-time undefined
behavior sanity checker"), and I don't want to bring in all of UBSAN
to 4.4. I'll send a patch for 0e410e158e5b.
--
Thanks,
~Nick Desaulniers
The function has an inline "return false;" definition with CONFIG_SMP=n but the
"real" definition is also visible leading to "redefinition of
‘apic_id_is_primary_thread’" compiler error. Guard it with #ifdef CONFIG_SMP
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Fixes: 6a4d2657e048 ("x86/smp: Provide topology_is_primary_thread()")
Cc: stable(a)vger.kernel.org
---
arch/x86/kernel/apic/apic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 87ff6235bbfe..84132eddb5a8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2193,6 +2193,7 @@ static int cpuid_to_apicid[] = {
[0 ... NR_CPUS - 1] = -1,
};
+#ifdef CONFIG_SMP
/**
* apic_id_is_primary_thread - Check whether APIC ID belongs to a primary thread
* @id: APIC ID to check
@@ -2207,6 +2208,7 @@ bool apic_id_is_primary_thread(unsigned int apicid)
mask = (1U << (fls(smp_num_siblings) - 1)) - 1;
return !(apicid & mask);
}
+#endif
/*
* Should use this API to allocate logical CPU IDs to keep nr_logical_cpuids
--
2.18.0
From: Andrey Konovalov <andreyknvl(a)google.com>
commit 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 upstream.
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.
The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.
The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.
Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459…
Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[ Nick : Backported to 4.4 avoiding KUBSAN ]
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
---
Makefile | 3 ++-
scripts/Makefile.kasan | 3 +++
scripts/Makefile.lib | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index ee92a12e3a4b..4fdd43dd14aa 100644
--- a/Makefile
+++ b/Makefile
@@ -418,7 +418,8 @@ export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KASAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 37323b0df374..2624d4bf9a45 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -28,4 +28,7 @@ else
CFLAGS_KASAN := $(CFLAGS_KASAN_MINIMAL)
endif
endif
+
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 24914e7de944..a2d0e6d32659 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -126,7 +126,7 @@ endif
ifeq ($(CONFIG_KASAN),y)
_c_flags += $(if $(patsubst n%,, \
$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
- $(CFLAGS_KASAN))
+ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
endif
# If building the kernel in a separate objtree expand all occurrences
--
2.18.0.865.gffc8e1a3cd6-goog
These are already defined higher up in the file.
Cc: stable(a)vger.kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
---
arch/x86/kvm/vmx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 58bba7a7572a..e7691e666479 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9725,9 +9725,6 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu)
* information but as all relevant affected CPUs have 32KiB L1D cache size
* there is no point in doing so.
*/
-#define L1D_CACHE_ORDER 4
-static void *vmx_l1d_flush_pages;
-
static void vmx_l1d_flush(struct kvm_vcpu *vcpu)
{
int size = PAGE_SIZE << L1D_CACHE_ORDER;
--
2.17.1
Dear Friend, My sincere apologies for this unsolicited mail to you, my name is Barrister Luis Carlos Delgado, theCEO/founder of (LCD ABOGADOS) with offices in Madrid and Portugal. We consult for NGOs, Companiesand individuals on Family Law, Intellectual Property, Real Estate, and Wills. I am consulting you on business grounds: I know that it may surprise you receiving this mail from me since therewas no previous correspondence between us. I have an urgent and very confidential business proposal of(USD$9,500,000.00) (Nine Million Five Hundred Thousand US Dollars only) which I believe that will be a verygood opportunity for both of us, so I decided to contact you on the business. Further details; get back me on my direct contact number below: Tel: +351920414587Fax: +34917692994E-mail: Luis_carlos.delgado(a)consultant.comYour swift response will be highly recommended and appreciated, and I shall provide you with more detailsabout my urgent business proposal.Note: If my approach offends your moral ethics do accept my sincere apology, if on the contrary you wish towork with me on this, kindly get back to me with your interest for more details on my direct private contact.Best Regards, Luis Carlos Delgado Esq.(LCD ABOGADOS) Av. de Burgos 20, 28036 Madrid EspanaRua Sarmento de Beires 30 1�E, 1900-221 Lisboa PortugalTel: +351920414587Fax: +34917692994E-mail: Luis_carlos.delgado(a)consultant.co
The patch
ASoC: wm9712: fix replace codec to component
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 5e4cfadaf5b73a0801b2fa7fb007f98400ebfe6e Mon Sep 17 00:00:00 2001
From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com>
Date: Tue, 14 Aug 2018 00:35:56 +0200
Subject: [PATCH] ASoC: wm9712: fix replace codec to component
Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
"wm9712-codec" got renamed to "wm9712-component", however, this change
never got propagated down to the actual board/platform drivers. E.g. on
Colibri T20 this lead to the following spew upon boot with sound/touch
being broken:
[ 2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
[ 2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
[ 2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
[ 2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
[ 3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not registered
[ 3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 14.970443] ALSA device list:
[ 14.996628] No soundcards found.
This commit finally fixes this again.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com>
Acked-by: Charles Keepax <ckeepax(a)opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/codecs/wm9712.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c
index 953d94d50586..ade34c26ad2f 100644
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -719,7 +719,7 @@ static int wm9712_probe(struct platform_device *pdev)
static struct platform_driver wm9712_component_driver = {
.driver = {
- .name = "wm9712-component",
+ .name = "wm9712-codec",
},
.probe = wm9712_probe,
--
2.18.0
Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.
Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae847991a43 ("drm/i915: add
intel_ddi_set_pipe_settings").
Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.
Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.
After all these years, the fix boils down to flipping one bit.
[Per testing reports, this fixes DP sinks, but not the LSPCON. My
educated guess is that the LSPCON fails to turn the CEA range MSA into
AVI infoframes for HDMI.]
Reported-by: Michał Kopeć <mkopec12(a)gmail.com>
Reported-by: N. W. <nw9165-3201(a)yahoo.com>
Reported-by: Nicholas Stommel <nicholas.stommel(a)gmail.com>
Reported-by: Tom Yan <tom.ty89(a)gmail.com>
Tested-by: Nicholas Stommel <nicholas.stommel(a)gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni <paulo.r.zanoni(a)intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # v3.9+
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 17575cfc22b5..0c9f03dda569 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9246,6 +9246,7 @@ enum skl_power_gate {
#define TRANS_MSA_10_BPC (2 << 5)
#define TRANS_MSA_12_BPC (3 << 5)
#define TRANS_MSA_16_BPC (4 << 5)
+#define TRANS_MSA_CEA_RANGE (1 << 3)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0adc043529f2..6f7be066c8f2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1685,6 +1685,10 @@ void intel_ddi_set_pipe_settings(const struct intel_crtc_state *crtc_state)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
temp = TRANS_MSA_SYNC_CLK;
+
+ if (crtc_state->limited_color_range)
+ temp |= TRANS_MSA_CEA_RANGE;
+
switch (crtc_state->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
--
2.11.0