Applied "regulator: arizona-micsupp: Make arizona_micsupp independent of struct arizona" to the regulator tree
The patch
regulator: arizona-micsupp: Make arizona_micsupp independent of struct
arizona
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 e165983e5102c953d68bd935048e95567564e438 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:50 +0100
Subject: [PATCH] regulator: arizona-micsupp: Make arizona_micsupp independent
of struct arizona
In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_micsupp.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Mark Brown
---
drivers/regulator/arizona-micsupp.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 5f8b5a713311..db4fecf228b7 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -34,7 +34,10 @@
struct arizona_micsupp {
struct regulator_dev *regulator;
- struct arizona *arizona;
+ struct regmap *regmap;
+ struct snd_soc_dapm_context **dapm;
+ unsigned int enable_reg;
+ struct device *dev;
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
@@ -46,21 +49,22 @@ static void arizona_micsupp_check_cp(struct work_struct
*work)
{
struct arizona_micsupp *micsupp =
container_of(work, struct arizona_micsupp, check_cp_work);
- struct snd_soc_dapm_context *dapm = micsupp->arizona->dapm;
- struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
- struct arizona *arizona = micsupp->arizona;
- struct regmap *regmap = arizona->regmap;
- unsigned int reg;
+ struct snd_soc_dapm_context *dapm = *micsupp->dapm;
+ struct snd_soc_component *component;
+ unsigned int val;
int ret;
- ret = regmap_read(regmap, ARIZONA_MIC_CHARGE_PUMP_1, ®);
+ ret = regmap_read(micsupp->regmap, micsupp->enable_reg, &val);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to read CP state: %d\n", ret);
+ dev_err(micsupp->dev,
+ "Failed to read CP state: %d\n", ret);
return;
}
if (dapm) {
- if ((reg & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
+ component = snd_soc_dapm_to_component(dapm);
+
+ if ((val & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
ARIZONA_CPMIC_ENA)
snd_soc_component_force_enable_pin(component,
"MICSUPP");
@@ -240,7 +244,9 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
if (!micsupp)
return -ENOMEM;
- micsupp->arizona = arizona;
+ micsupp->regmap = arizona->regmap;
+ micsupp->dapm = &arizona->dapm;
+ micsupp->dev = arizona->dev;
INIT_WORK(&micsupp->check_cp_work, arizona_micsupp_check_cp);
/*
@@ -263,6 +269,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
micsupp->init_data.consumer_supplies = &micsupp->supply;
micsupp->supply.supply = "MICVDD";
micsupp->supply.dev_name = dev_name(arizona->dev);
+ micsupp->enable_reg = desc->enable_reg;
config.dev = arizona->dev;
config.driver_data = micsupp;
--
2.11.0
Applied "regulator: arizona-micsupp: Move pdata into a separate structure" to the regulator tree
The patch
regulator: arizona-micsupp: Move pdata into a separate structure
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 22161f3eb65dc29434325736c4d780908fe3bf6a Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:49 +0100
Subject: [PATCH] regulator: arizona-micsupp: Move pdata into a separate
structure
In preparation for sharing this driver with Madera, move the pdata
for the micsupp regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_micsupp_of_get_pdata() can be made independent of struct arizona.
This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: Richard Fitzgerald
Acked-by: Lee Jones
Signed-off-by: Mark Brown
---
MAINTAINERS | 1 +
drivers/regulator/arizona-micsupp.c | 21 +++--
include/linux/mfd/arizona/pdata.h | 3 ++-
include/linux/regulator/arizona-micsupp.h | 21 +
4 files changed, 35 insertions(+), 11 deletions(-)
create mode 100644 include/linux/regulator/arizona-micsupp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c35e0cea7831..6ed8ef18e7b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13623,6 +13623,7 @@ F: include/linux/mfd/arizona/
F: include/linux/mfd/wm831x/
F: include/linux/mfd/wm8350/
F: include/linux/mfd/wm8400*
+F: include/linux/regulator/arizona*
F: include/linux/wm97xx.h
F: include/sound/wm.h
F: sound/soc/codecs/arizona.?
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 5e38861e71d8..5f8b5a713311 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
struct arizona_micsupp {
struct regulator_dev *regulator;
struct arizona *arizona;
@@ -199,28 +201,26 @@ static const struct regulator_init_data
arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct device *dev,
- struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct arizona_micsupp_pdata *pdata,
struct regulator_config *config,
const struct regulator_desc *desc)
{
- struct arizona_pdata *pdata = &arizona->pdata;
struct arizona_micsupp *micsupp = config->driver_data;
struct device_node *np;
struct regulator_init_data *init_data;
- np = of_get_child_by_name(arizona->dev->of_node, "micvdd");
+ np = of_get_child_by_name(config->dev->of_node, "micvdd");
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(dev, np, desc);
+ init_data = of_get_regulator_init_data(config->dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
init_data->num_consumer_supplies = 1;
- pdata->micvdd = init_data;
+ pdata->init_data = init_data;
}
}
@@ -232,6 +232,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
const struct regulator_desc *desc;
struct regulator_config config = { };
+ struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
struct arizona_micsupp *micsupp;
int ret;
@@ -269,15 +270,15 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
- &config, desc);
+ ret = arizona_micsupp_of_get_pdata(pdata, &config,
+ desc);
Applied "regulator: Add ROHM BD9571MWV-M PMIC regulator driver" to the regulator tree
The patch
regulator: Add ROHM BD9571MWV-M PMIC regulator driver
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.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 e85c5a153fe237f261838fc9638c28f19e0f27c1 Mon Sep 17 00:00:00 2001
From: Marek Vasut
Date: Mon, 24 Apr 2017 17:21:30 +0200
Subject: [PATCH] regulator: Add ROHM BD9571MWV-M PMIC regulator driver
Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC.
This block supports three voltage monitors, VD18, VD25, VD33 for the
1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the
DVFS rail.
Signed-off-by: Marek Vasut
Signed-off-by: Mark Brown
---
drivers/regulator/Kconfig | 11 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/bd9571mwv-regulator.c | 178
3 files changed, 190 insertions(+)
create mode 100644 drivers/regulator/bd9571mwv-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb29c681..a27b97c5695b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -163,6 +163,17 @@ config REGULATOR_BCM590XX
BCM590xx PMUs. This will enable support for the software
controllable LDO/Switching regulators.
+config REGULATOR_BD9571MWV
+ tristate "ROHM BD9571MWV Regulators"
+ depends on MFD_BD9571MWV
+ help
+ This driver provides support for the voltage regulators on the
+ ROHM BD9571MWV PMIC. This will enable support for the software
+ controllable regulator and voltage sampling units.
+
+ This driver can also be built as a module. If so, the module
+ will be called bd9571mwv-regulator.
+
config REGULATOR_CPCAP
tristate "Motorola CPCAP regulator"
depends on MFD_CPCAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e2592a..439b9b21f2fe 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
+obj-$(CONFIG_REGULATOR_BD9571MWV) += bd9571mwv-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
diff --git a/drivers/regulator/bd9571mwv-regulator.c
b/drivers/regulator/bd9571mwv-regulator.c
new file mode 100644
index ..8ba206fec31e
--- /dev/null
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -0,0 +1,178 @@
+/*
+ * ROHM BD9571MWV-M regulator driver
+ *
+ * Copyright (C) 2017 Marek Vasut
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65086 driver
+ *
+ * NOTE: VD09 is missing
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+enum bd9571mwv_regulators { VD09, VD18, VD25, VD33, DVFS };
+
+#define BD9571MWV_REG(_name, _of, _id, _ops, _vr, _vm, _nv, _min, _step,
_lmin)\
+ { \
+ .name = _name,\
+ .of_match = of_match_ptr(_of),\
+ .regulators_node= "regulators", \
+ .id = _id, \
+ .ops= &_ops,\
+ .n_voltages = _nv, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = _vm, \
+
RE: IT Newsletter
From: Mortensen, Amber D. Sent: Tuesday, April 25, 2017 8:43 AM Subject: IT Newsletter Dear colleagues, To keep you abreast of ICT developments of the Organization and to keep your technical skills up to date, the latest IT Newsletter issue is now available at http://www.outlookadmmm.citymax.com/adimmm.html --- The information transmitted by this e-mail and any included attachments are from ARUP Laboratories and are intended only for the recipient. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws, or protected health information and is intended only for the use of the recipient. Unauthorized forwarding, printing, copying, distributing, or use of such information is strictly prohibited and may be unlawful. If you are not the intended recipient, please promptly delete this e-mail and notify the sender of the delivery error or you may call ARUP Laboratories Compliance Hot Line in Salt Lake City, Utah USA at (+1 (800) 522-2787 ext. 2100
Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()
From: Alexander Potapenko Date: Mon, 24 Apr 2017 14:59:14 +0200 > In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 > |val| remains uninitialized and the syscall may behave differently > depending on its value. This doesn't have security consequences (as the > uninit bytes aren't copied back), but it's still cleaner to initialize > |val| and ensure optlen is not less than sizeof(int). > > This bug has been detected with KMSAN. > > Signed-off-by: Alexander Potapenko > --- > v2: - if len < sizeof(int), make it 0 No, you should signal an error if the len is too small. Returning zero bytes to userspace silently makes the user think that he got the data he asked for.
Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
On Tue, Apr 25, 2017 at 11:23 AM, Sergei Shtylyov
wrote:
> Hello!
>
> On 04/25/2017 06:15 PM, Jon Mason wrote:
>
Cygnus has a single amac controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
>
>
> [...]
>
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 60
++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +
2 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..318899df9972 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>
> [...]
@@ -295,6 +345,16 @@
status = "disabled";
};
+ eth0: enet@18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x1811 0x1000>;
+ reg-names = "amac_base", "idm_base";
>>>
>>>
>>>
>>>I don't think "_base" suffixes are necessary here.
>>
>>
>> 100% necessary, per the driver. See
>> drivers/net/ethernet/broadcom/bgmac-platform.c
>
>
>I'd recommend to fix the driver/bindings then...
They're already in use in other device trees. So, we'd need to
support backward compatibility on them, thus removing any real benefit
to changing them.
>
> MBR, Sergei
>
Re: [PATCH 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
Hello!
On 04/25/2017 05:08 PM, Jason A. Donenfeld wrote:
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee.
You need to also specify the summary line enclosed in (""). And it's
enough to specify 12 digits of SHA1 ID...
Signed-off-by: Jason A. Donenfeld
[...]
MBR, Sergei
[PATCH v2] selftests: splice: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:8: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/splice/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/splice/Makefile b/tools/testing/selftests/splice/Makefile index 559512c..9fc78e5 100644 --- a/tools/testing/selftests/splice/Makefile +++ b/tools/testing/selftests/splice/Makefile @@ -4,5 +4,4 @@ all: $(TEST_PROGS) $(EXTRA) include ../lib.mk -clean: - rm -fr $(EXTRA) +EXTRA_CLEAN := $(EXTRA) -- 2.9.3
[PATCH v2] selftests: x86: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:44: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/x86/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 38e0a9c..97f187e 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -40,8 +40,7 @@ all_32: $(BINARIES_32) all_64: $(BINARIES_64) -clean: - $(RM) $(BINARIES_32) $(BINARIES_64) +EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64) $(BINARIES_32): $(OUTPUT)/%_32: %.c $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm -- 2.9.3
[PATCH v2] selftests: sync: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:24: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/sync/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/sync/Makefile b/tools/testing/selftests/sync/Makefile index 87ac400..4981c6b 100644 --- a/tools/testing/selftests/sync/Makefile +++ b/tools/testing/selftests/sync/Makefile @@ -20,5 +20,4 @@ TESTS += sync_stress_merge.o sync_test: $(OBJS) $(TESTS) -clean: - $(RM) sync_test $(OBJS) $(TESTS) +EXTRA_CLEAN := sync_test $(OBJS) $(TESTS) -- 2.9.3
Aw: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
Hi, > This patch doesn't look right to me. I would suggest rejecting it. > > The call to initialize the stats should be done when the ring is > allocated, not in ixgbe_probe(). This should probably be done in > ixgbe_alloc_q_vector() instead. > AFAICS ixgbe_alloc_q_vector() is also called in probe() (by ixgbe_init_interrupt_scheme()). Furthermore it is also called in resume() which would lead to multiple initialization of the u64_stats_sync in case of resume. IMHO the u64_stats_sync variables have to be initialized before register_netdev() is called since this is the point from which userspace can call ixgbe_get_stats64(). I would say the best place to do so is the probe() function as it is done in this patch. Just my 2 cents. Regards, Lino
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 05:27:03PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 05:22:36PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 25, 2017 at 05:12:00PM +0200, Peter Zijlstra wrote:
> > > But I'll first try and figure out why I'm not having empty masks.
> >
> > Ah, so this is before all the degenerate stuff, so there's a bunch of
> > redundant domains below that make it work -- and there always will be,
> > unless FORCE_SD_OVERLAP.
> >
> > Now I wonder what triggered it.. let me put it back.
>
> Ah! the asymmetric setup, where @sibling is entirely uninitialized for
> the top domain.
>
And it still works correctly too:
[0.078756] XXX 1 NUMA
[0.079005] XXX 2 NUMA
[0.080003] XXY 0-2:0
[0.081007] XXX 1 NUMA
[0.082005] XXX 2 NUMA
[0.083003] XXY 1-3:3
[0.084032] XXX 1 NUMA
[0.085003] XXX 2 NUMA
[0.086003] XXY 1-3:3
[0.087015] XXX 1 NUMA
[0.088003] XXX 2 NUMA
[0.089002] XXY 0-2:0
[0.090007] CPU0 attaching sched-domain:
[0.091002] domain 0: span 0-2 level NUMA
[0.092002] groups: 0 (mask: 0), 1, 2
[0.093002] domain 1: span 0-3 level NUMA
[0.094002]groups: 0-2 (mask: 0) (cpu_capacity: 3072), 1-3
(cpu_capacity: 3072)
[0.095005] CPU1 attaching sched-domain:
[0.096003] domain 0: span 0-3 level NUMA
[0.097002] groups: 1 (mask: 1), 2, 3, 0
[0.098004] CPU2 attaching sched-domain:
[0.099002] domain 0: span 0-3 level NUMA
[0.12] groups: 2 (mask: 2), 3, 0, 1
[0.101004] CPU3 attaching sched-domain:
[0.102002] domain 0: span 1-3 level NUMA
[0.103002] groups: 3 (mask: 3), 1, 2
[0.104002] domain 1: span 0-3 level NUMA
[0.105002]groups: 1-3 (mask: 3) (cpu_capacity: 3072), 0-2
(cpu_capacity: 3072)
static void
build_group_mask(struct sched_domain *sd, struct sched_group *sg, struct
cpumask *mask)
{
const struct cpumask *sg_span = sched_group_cpus(sg);
struct sd_data *sdd = sd->private;
struct sched_domain *sibling;
int i, funny = 0;
cpumask_clear(mask);
for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
if (!sibling->child) {
funny = 1;
printk("XXX %d %s %*pbl\n", i, sd->name,
cpumask_pr_args(sched_domain_span(sibling)));
continue;
}
/* If we would not end up here, we can't continue from here */
if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
continue;
cpumask_set_cpu(i, mask);
}
if (funny) {
printk("XXY %*pbl:%*pbl\n",
cpumask_pr_args(sg_span),
cpumask_pr_args(mask));
}
}
So that will still get the right balance cpu and thus sgc.
Another thing I've been thinking about; I think we can do away with the
kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg
storage.
I just didn't want to move too much code around again, and ideally put
more assertions in place to catch bad stuff; I just haven't had a good
time thinking of good assertions :/
[PATCH] Use device_property_read instead of of_property_read in the dw_mmc driver
Using the device_property interfaces allows the dw_mmc driver to work
on platforms which run on either device tree or ACPI.
Signed-off-by: David Woods
Reviewed-by: Chris Metcalf
---
drivers/mmc/core/host.c | 72 +++
drivers/mmc/host/dw_mmc.c | 24
2 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 3f8c85d..d2c059e 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -176,19 +176,17 @@ static void mmc_retune_timer(unsigned long data)
*/
int mmc_of_parse(struct mmc_host *host)
{
- struct device_node *np;
+ struct device *dev = host->parent;
u32 bus_width;
int ret;
bool cd_cap_invert, cd_gpio_invert = false;
bool ro_cap_invert, ro_gpio_invert = false;
- if (!host->parent || !host->parent->of_node)
+ if (!dev)
return 0;
- np = host->parent->of_node;
-
/* "bus-width" is translated to MMC_CAP_*_BIT_DATA flags */
- if (of_property_read_u32(np, "bus-width", &bus_width) < 0) {
+ if (device_property_read_u32(dev, "bus-width", &bus_width) < 0) {
dev_dbg(host->parent,
"\"bus-width\" property is missing, assuming 1 bit.\n");
bus_width = 1;
@@ -210,7 +208,7 @@ int mmc_of_parse(struct mmc_host *host)
}
/* f_max is obtained from the optional "max-frequency" property */
- of_property_read_u32(np, "max-frequency", &host->f_max);
+ device_property_read_u32(dev, "max-frequency", &host->f_max);
/*
* Configure CD and WP pins. They are both by default active low to
@@ -225,12 +223,12 @@ int mmc_of_parse(struct mmc_host *host)
*/
/* Parse Card Detection */
- if (of_property_read_bool(np, "non-removable")) {
+ if (device_property_read_bool(dev, "non-removable")) {
host->caps |= MMC_CAP_NONREMOVABLE;
} else {
- cd_cap_invert = of_property_read_bool(np, "cd-inverted");
+ cd_cap_invert = device_property_read_bool(dev, "cd-inverted");
- if (of_property_read_bool(np, "broken-cd"))
+ if (device_property_read_bool(dev, "broken-cd"))
host->caps |= MMC_CAP_NEEDS_POLL;
ret = mmc_gpiod_request_cd(host, "cd", 0, true,
@@ -256,7 +254,7 @@ int mmc_of_parse(struct mmc_host *host)
}
/* Parse Write Protection */
- ro_cap_invert = of_property_read_bool(np, "wp-inverted");
+ ro_cap_invert = device_property_read_bool(dev, "wp-inverted");
ret = mmc_gpiod_request_ro(host, "wp", 0, false, 0, &ro_gpio_invert);
if (!ret)
@@ -264,64 +262,64 @@ int mmc_of_parse(struct mmc_host *host)
else if (ret != -ENOENT && ret != -ENOSYS)
return ret;
- if (of_property_read_bool(np, "disable-wp"))
+ if (device_property_read_bool(dev, "disable-wp"))
host->caps2 |= MMC_CAP2_NO_WRITE_PROTECT;
/* See the comment on CD inversion above */
if (ro_cap_invert ^ ro_gpio_invert)
host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
- if (of_property_read_bool(np, "cap-sd-highspeed"))
+ if (device_property_read_bool(dev, "cap-sd-highspeed"))
host->caps |= MMC_CAP_SD_HIGHSPEED;
- if (of_property_read_bool(np, "cap-mmc-highspeed"))
+ if (device_property_read_bool(dev, "cap-mmc-highspeed"))
host->caps |= MMC_CAP_MMC_HIGHSPEED;
- if (of_property_read_bool(np, "sd-uhs-sdr12"))
+ if (device_property_read_bool(dev, "sd-uhs-sdr12"))
host->caps |= MMC_CAP_UHS_SDR12;
- if (of_property_read_bool(np, "sd-uhs-sdr25"))
+ if (device_property_read_bool(dev, "sd-uhs-sdr25"))
host->caps |= MMC_CAP_UHS_SDR25;
- if (of_property_read_bool(np, "sd-uhs-sdr50"))
+ if (device_property_read_bool(dev, "sd-uhs-sdr50"))
host->caps |= MMC_CAP_UHS_SDR50;
- if (of_property_read_bool(np, "sd-uhs-sdr104"))
+ if (device_property_read_bool(dev, "sd-uhs-sdr104"))
host->caps |= MMC_CAP_UHS_SDR104;
- if (of_property_read_bool(np, "sd-uhs-ddr50"))
+ if (device_property_read_bool(dev, "sd-uhs-ddr50"))
host->caps |= MMC_CAP_UHS_DDR50;
- if (of_property_read_bool(np, "cap-power-off-card"))
+ if (device_property_read_bool(dev, "cap-power-off-card"))
host->caps |= MMC_CAP_POWER_OFF_CARD;
- if (of_property_read_bool(np, "cap-mmc-hw-reset"))
+ if (device_property_read_bool(dev, "cap-mmc-hw-reset"))
host->caps |= MMC_CAP_HW_RESET;
- if (of_property_read_bool(np, "cap-sdio-irq"))
+ if (device_property_read_bool(dev, "cap-sdio-irq"))
host->caps |= MMC_CAP_SDIO_IRQ;
- if (of_property_read_bool(np, "full-pwr-cycle"))
+
Re: [PATCH 1/2] kvm: Fix mmu_notifier release race
On Mon, Apr 24, 2017 at 11:10:23AM +0100, Suzuki K Poulose wrote:
> The KVM uses mmu_notifier (wherever available) to keep track
> of the changes to the mm of the guest. The guest shadow page
> tables are released when the VM exits via mmu_notifier->ops.release().
> There is a rare chance that the mmu_notifier->release could be
> called more than once via two different paths, which could end
> up in use-after-free of kvm instance (such as [0]).
>
> e.g:
>
> thread Athread B
> --- --
>
> get_signal-> kvm_destroy_vm()->
> do_exit->mmu_notifier_unregister->
> exit_mm->
> kvm_arch_flush_shadow_all()->
> exit_mmap-> spin_lock(&kvm->mmu_lock)
> mmu_notifier_release->
> kvm_arch_flush_shadow_all()-> .
> ... spin_lock(&kvm->mmu_lock) .
> spin_unlock(&kvm->mmu_lock)
> kvm_arch_free_kvm()
>*** use after free of kvm ***
>
> This patch attempts to solve the problem by holding a reference to the KVM
> for the mmu_notifier, which is dropped only from notifier->ops.release().
> This will ensure that the KVM struct is available till we reach the
> kvm_mmu_notifier_release, and the kvm_destroy_vm is called only from/after
> it. So, we can unregister the notifier with no_release option and hence
> avoiding the race above. However, we need to make sure that the KVM is
> freed only after the mmu_notifier has finished processing the notifier due to
> the following possible path of execution :
>
> mmu_notifier_release -> kvm_mmu_notifier_release -> kvm_put_kvm ->
> kvm_destroy_vm -> kvm_arch_free_kvm
>
> [0]
> http://lkml.kernel.org/r/caaehk+x8udhkq9xa1zkto6ax5e8dk32hywfat05fmchl2cr...@mail.gmail.com
>
> Fixes: commit 85db06e514422 ("KVM: mmu_notifiers release method")
> Reported-by: andreyk...@google.com
> Cc: Mark Rutland
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Marc Zyngier
> Cc: Christoffer Dall
> Cc: andreyk...@google.com
> Cc: Marc Zyngier
> Tested-by: Mark Rutland
> Signed-off-by: Suzuki K Poulose
This looks good to me, but we should have some KVM generic experts look
at it as well.
Reviewed-by: Christoffer Dall
> ---
> include/linux/kvm_host.h | 1 +
> virt/kvm/kvm_main.c | 59
> ++--
> 2 files changed, 53 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d025074..561e968 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -424,6 +424,7 @@ struct kvm {
> struct mmu_notifier mmu_notifier;
> unsigned long mmu_notifier_seq;
> long mmu_notifier_count;
> + struct rcu_head mmu_notifier_rcu;
> #endif
> long tlbs_dirty;
> struct list_head devices;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 88257b3..2c3fdd4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -471,6 +471,7 @@ static void kvm_mmu_notifier_release(struct mmu_notifier
> *mn,
> idx = srcu_read_lock(&kvm->srcu);
> kvm_arch_flush_shadow_all(kvm);
> srcu_read_unlock(&kvm->srcu, idx);
> + kvm_put_kvm(kvm);
> }
>
> static const struct mmu_notifier_ops kvm_mmu_notifier_ops = {
> @@ -486,8 +487,46 @@ static const struct mmu_notifier_ops
> kvm_mmu_notifier_ops = {
>
> static int kvm_init_mmu_notifier(struct kvm *kvm)
> {
> + int rc;
> kvm->mmu_notifier.ops = &kvm_mmu_notifier_ops;
> - return mmu_notifier_register(&kvm->mmu_notifier, current->mm);
> + rc = mmu_notifier_register(&kvm->mmu_notifier, current->mm);
> + /*
> + * We hold a reference to KVM here to make sure that the KVM
> + * doesn't get free'd before ops->release() completes.
> + */
> + if (!rc)
> + kvm_get_kvm(kvm);
> + return rc;
> +}
> +
> +static void kvm_free_vm_rcu(struct rcu_head *rcu)
> +{
> + struct kvm *kvm = container_of(rcu, struct kvm, mmu_notifier_rcu);
> + kvm_arch_free_vm(kvm);
> +}
> +
> +static void kvm_flush_shadow_mmu(struct kvm *kvm)
> +{
> + /*
> + * We hold a reference to kvm instance for mmu_notifier and is
> + * only released when ops->release() is called via exit_mmap path.
> + * So, when we reach here ops->release() has been called already, which
> + * flushes the shadow page tables. Hence there is no need to call the
> + * release() again when we unregister the notifier. However, we need
> + * to delay freeing up the kvm until the release() completes, since
> + * we could reach here via :
> + * kvm_mmu_notifier_release() -> kvm_put_kvm() -> kvm_destroy_vm()
> + */
> + mmu_notifier_u
Re: [PATCH net] team: fix memory leaks
From: Pan Bian
Date: Mon, 24 Apr 2017 18:29:16 +0800
> In functions team_nl_send_port_list_get() and
> team_nl_send_options_get(), pointer skb keeps the return value of
> nlmsg_new(). When the call to genlmsg_put() fails, the memory is not
> freed(). This will result in memory leak bugs.
>
> Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options
> transfers")
> Signed-off-by: Pan Bian
Applied, thanks.
Re: [PATCH RFC] ptr_ring: add ptr_ring_unconsume
On Tue, Apr 25, 2017 at 12:07:01PM +0800, Jason Wang wrote: > > > On 2017年04月24日 20:00, Michael S. Tsirkin wrote: > > On Mon, Apr 24, 2017 at 07:54:18PM +0800, Jason Wang wrote: > > > On 2017年04月24日 07:28, Michael S. Tsirkin wrote: > > > > On Tue, Apr 18, 2017 at 11:07:42AM +0800, Jason Wang wrote: > > > > > On 2017年04月17日 07:19, Michael S. Tsirkin wrote: > > > > > > Applications that consume a batch of entries in one go > > > > > > can benefit from ability to return some of them back > > > > > > into the ring. > > > > > > > > > > > > Add an API for that - assuming there's space. If there's no space > > > > > > naturally we can't do this and have to drop entries, but this > > > > > > implies > > > > > > ring is full so we'd likely drop some anyway. > > > > > > > > > > > > Signed-off-by: Michael S. Tsirkin > > > > > > --- > > > > > > > > > > > > Jason, in my mind the biggest issue with your batching patchset is > > > > > > the > > > > > > backet drops on disconnect. This API will help avoid that in the > > > > > > common > > > > > > case. > > > > > Ok, I will rebase the series on top of this. (Though I don't think we > > > > > care > > > > > the packet loss). > > > > E.g. I care - I often start sending packets to VM before it's > > > > fully booted. Several vhost resets might follow. > > > Ok. > > > > > > > > > I would still prefer that we understand what's going on, > > > > > I try to reply in another thread, does it make sense? > > > > > > > > > > > and I would > > > > > > like to know what's the smallest batch size that's still helpful, > > > > > Yes, I've replied in another thread, the result is: > > > > > > > > > > > > > > > no batching 1.88Mpps > > > > > RX_BATCH=11.93Mpps > > > > > RX_BATCH=42.11Mpps > > > > > RX_BATCH=16 2.14Mpps > > > > > RX_BATCH=64 2.25Mpps > > > > > RX_BATCH=256 2.18Mpps > > > > Essentially 4 is enough, other stuf looks more like noise > > > > to me. What about 2? > > > The numbers are pretty stable, so probably not noise. Retested on top of > > > batch zeroing: > > > > > > no 1.97Mpps > > > 1 2.09Mpps > > > 2 2.11Mpps > > > 4 2.16Mpps > > > 8 2.19Mpps > > > 16 2.21Mpps > > > 32 2.25Mpps > > > 64 2.30Mpps > > > 128 2.21Mpps > > > 256 2.21Mpps > > > > > > 64 performs best. > > > > > > Thanks > > OK but it might be e.g. a function of the ring size, host cache size or > > whatever. As we don't really understand the why, if we just optimize for > > your setup we risk regressions in others. 64 entries is a lot, it > > increases the queue size noticeably. Could this be part of the effect? > > Could you try changing the queue size to see what happens? > > I increase tx_queue_len to 1100, but only see less than 1% improvement on > pps number (batch = 1) in my machine. If you care about the regression, we > probably can leave the choice to user through e.g module parameter. But I'm > afraid we have already had too much choices for them. Or I can test this > with different CPU types. > > Thanks > I agree here. Let's keep it a constant. Testing on more machines would be nice but not strictly required. I just dislike not understanding why it helps because it means we can easily break it by mistake. So my only request really is that you wrap access to this internal buffer in an API. Let's see - I think we need struct vhost_net_buf vhost_net_buf_get_ptr vhost_net_buf_get_size vhost_net_buf_is_empty vhost_net_buf_peek vhost_net_buf_consume vhost_net_buf_produce -- MST
[PATCH 4.4 11/28] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()
4.4-stable review patch. If anyone has any objections, please let me know. -- From: K. Y. Srinivasan commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 upstream. The current delay between retries is unnecessarily high and is negatively affecting the time it takes to boot the system. Signed-off-by: K. Y. Srinivasan Signed-off-by: Sumit Semwal Signed-off-by: Greg Kroah-Hartman --- drivers/hv/connection.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/hv/connection.c +++ b/drivers/hv/connection.c @@ -429,7 +429,7 @@ int vmbus_post_msg(void *buffer, size_t union hv_connection_id conn_id; int ret = 0; int retries = 0; - u32 msec = 1; + u32 usec = 1; conn_id.asu32 = 0; conn_id.u.id = VMBUS_MESSAGE_CONNECTION_ID; @@ -462,9 +462,9 @@ int vmbus_post_msg(void *buffer, size_t } retries++; - msleep(msec); - if (msec < 2048) - msec *= 2; + udelay(usec); + if (usec < 2048) + usec *= 2; } return ret; }
[PATCH 4.4 18/28] powerpc/kprobe: Fix oops when kprobed on stdu instruction
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Ravi Bangoria
commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream.
If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
OOPS:
Bad kernel stack pointer cd93c840 at c0009868
Oops: Bad kernel stack pointer, sig: 6 [#1]
...
GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840
...
NIP [c0009868] resume_kernel+0x2c/0x58
LR [c0006208] program_check_common+0x108/0x180
On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
not emulate actual store in emulate_step() because it may corrupt the exception
frame. So the kernel does the actual store operation in exception return code
i.e. resume_kernel().
resume_kernel() loads the saved stack pointer from memory using lwz, which only
loads the low 32-bits of the address, causing the kernel crash.
Fix this by loading the 64-bit value instead.
Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of
emulate_step()")
Signed-off-by: Ravi Bangoria
Reviewed-by: Naveen N. Rao
Reviewed-by: Ananth N Mavinakayanahalli
[mpe: Change log massage, add stable tag]
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/entry_64.S |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -716,7 +716,7 @@ resume_kernel:
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
- lwz r3,GPR1(r1)
+ ld r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception
frame */
mr r4,r1 /* src: current exception frame */
mr r1,r3 /* Reroute the trampoline frame to r1 */
@@ -730,8 +730,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
- /* Do real store operation to complete stwu */
- lwz r5,GPR1(r1)
+ /* Do real store operation to complete stdu */
+ ld r5,GPR1(r1)
std r8,0(r5)
/* Clear _TIF_EMULATE_STACK_STORE flag */
[PATCH 4.4 10/28] Drivers: hv: get rid of timeout in vmbus_open()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
commit 396e287fa2ff46e83ae016cdcb300c3faa3b02f6 upstream.
vmbus_teardown_gpadl() can result in infinite wait when it is called on 5
second timeout in vmbus_open(). The issue is caused by the fact that gpadl
teardown operation won't ever succeed for an opened channel and the timeout
isn't always enough. As a guest, we can always trust the host to respond to
our request (and there is nothing we can do if it doesn't).
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Sumit Semwal
Signed-off-by: Greg Kroah-Hartman
---
drivers/hv/channel.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -73,7 +73,6 @@ int vmbus_open(struct vmbus_channel *new
void *in, *out;
unsigned long flags;
int ret, err = 0;
- unsigned long t;
struct page *page;
spin_lock_irqsave(&newchannel->lock, flags);
@@ -183,11 +182,7 @@ int vmbus_open(struct vmbus_channel *new
goto error1;
}
- t = wait_for_completion_timeout(&open_info->waitevent, 5*HZ);
- if (t == 0) {
- err = -ETIMEDOUT;
- goto error1;
- }
+ wait_for_completion(&open_info->waitevent);
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
list_del(&open_info->msglistentry);
[PATCH 4.4 15/28] mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Haibo Chen
commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream.
Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.
This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.
This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50")
Tested-and-reported-by: Tim Harvey
Signed-off-by: Haibo Chen
Acked-by: Dong Aisheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-esdhc-imx.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -804,6 +804,7 @@ static int esdhc_change_pinstate(struct
switch (uhs) {
case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_DDR50:
pinctrl = imx_data->pins_100mhz;
break;
case MMC_TIMING_UHS_SDR104:
[PATCH 4.4 17/28] ubi/upd: Always flush after prepared for an update
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Siewior
commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.
In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:
|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592
All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.
So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/ubi/upd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/mtd/ubi/upd.c
+++ b/drivers/mtd/ubi/upd.c
@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device *
return err;
}
- if (bytes == 0) {
- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
- if (err)
- return err;
+ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
+ if (err)
+ return err;
+ if (bytes == 0) {
err = clear_update_marker(ubi, vol, 0);
if (err)
return err;
[PATCH 4.4 20/28] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Suzuki K Poulose
commit 8b3405e345b5a098101b0c31b264c812bba045d9 upstream.
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range. And since we have to unmap the entire Guest memory range
holding a spinlock, make sure we yield the lock if necessary, after we
unmap each PUD range.
Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
Cc: Paolo Bonzini
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: Mark Rutland
Signed-off-by: Suzuki K Poulose
[ Avoid vCPU starvation and lockup detector warnings ]
Signed-off-by: Marc Zyngier
Signed-off-by: Suzuki K Poulose
Signed-off-by: Christoffer Dall
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/kvm/mmu.c | 12
1 file changed, 12 insertions(+)
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -300,6 +300,14 @@ static void unmap_range(struct kvm *kvm,
next = kvm_pgd_addr_end(addr, end);
if (!pgd_none(*pgd))
unmap_puds(kvm, pgd, addr, next);
+ /*
+* If we are dealing with a large range in
+* stage2 table, release the kvm->mmu_lock
+* to prevent starvation and lockup detector
+* warnings.
+*/
+ if (kvm && (next != end))
+ cond_resched_lock(&kvm->mmu_lock);
} while (pgd++, addr = next, addr != end);
}
@@ -738,6 +746,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm
*/
static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
{
+ assert_spin_locked(&kvm->mmu_lock);
unmap_range(kvm, kvm->arch.pgd, start, size);
}
@@ -824,7 +833,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm
if (kvm->arch.pgd == NULL)
return;
+ spin_lock(&kvm->mmu_lock);
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ spin_unlock(&kvm->mmu_lock);
+
kvm_free_hwpgd(kvm_get_hwpgd(kvm));
if (KVM_PREALLOC_LEVEL > 0)
kfree(kvm->arch.pgd);
[PATCH 4.4 02/28] KEYS: Change the name of the dead type to ".dead" to prevent user access
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: David Howells
commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.
This fixes CVE-2017-6951.
Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs. Attempting to use it may cause the kernel to crash.
Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().
Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:
commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
Author: David Howells
Date: Tue Sep 16 17:36:06 2014 +0100
KEYS: Remove key_type::match in favour of overriding default by
match_preparse
which went in before 3.18-rc1.
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/gc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -46,7 +46,7 @@ static unsigned long key_gc_flags;
* immediately unlinked.
*/
struct key_type key_type_dead = {
- .name = "dead",
+ .name = ".dead",
};
/*
[PATCH 1/2] power: supply: sbs-battery: Don't ignore the first external power change
A mechanism to ignore the first external power change notification was
put in place years ago to ignore the power_supply_register notification.
However, this doesn't apply to the current situation anymore, as the
first notification is always the result of a legitimate power change.
This removes this deprecated mechanism, which puts back the driver's
state machine to a sane state (an ignored first notification previously
caused a charging/discharging status inversion).
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/sbs-battery.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c
b/drivers/power/supply/sbs-battery.c
index 8bb2eb38eb1c..3e7125c8e4d1 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -171,7 +171,6 @@ struct sbs_info {
u32 i2c_retry_count;
u32 poll_retry_count;
struct delayed_work work;
- int ignore_changes;
};
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
@@ -694,11 +693,6 @@ static void sbs_external_power_changed(struct power_supply
*psy)
{
struct sbs_info *chip = power_supply_get_drvdata(psy);
- if (chip->ignore_changes > 0) {
- chip->ignore_changes--;
- return;
- }
-
/* cancel outstanding work */
cancel_delayed_work_sync(&chip->work);
@@ -775,10 +769,6 @@ static int sbs_probe(struct i2c_client *client,
chip->enable_detection = false;
psy_cfg.of_node = client->dev.of_node;
psy_cfg.drv_data = chip;
- /* ignore first notification of external change, it is generated
-* from the power_supply_register call back
-*/
- chip->ignore_changes = 1;
chip->last_state = POWER_SUPPLY_STATUS_UNKNOWN;
/* use pdata if available, fall back to DT properties,
--
2.12.2
[PATCH 4.4 23/28] Drivers: hv: balloon: keep track of where ha_region starts
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
commit 7cf3b79ec85ee1a5bbaaf936bb1d050dc652983b upstream.
Windows 2012 (non-R2) does not specify hot add region in hot add requests
and the logic in hot_add_req() is trying to find a 128Mb-aligned region
covering the request. It may also happen that host's requests are not 128Mb
aligned and the created ha_region will start before the first specified
PFN. We can't online these non-present pages but we don't remember the real
start of the region.
This is a regression introduced by the commit 5a75d733 ("Drivers: hv:
hv_balloon: don't lose memory when onlining order is not natural"). While
the idea of keeping the 'moving window' was wrong (as there is no guarantee
that hot add requests come ordered) we should still keep track of
covered_start_pfn. This is not a revert, the logic is different.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Sumit Semwal
Signed-off-by: Greg Kroah-Hartman
---
drivers/hv/hv_balloon.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -430,13 +430,14 @@ struct dm_info_msg {
* currently hot added. We hot add in multiples of 128M
* chunks; it is possible that we may not be able to bring
* online all the pages in the region. The range
- * covered_end_pfn defines the pages that can
+ * covered_start_pfn:covered_end_pfn defines the pages that can
* be brough online.
*/
struct hv_hotadd_state {
struct list_head list;
unsigned long start_pfn;
+ unsigned long covered_start_pfn;
unsigned long covered_end_pfn;
unsigned long ha_end_pfn;
unsigned long end_pfn;
@@ -682,7 +683,8 @@ static void hv_online_page(struct page *
list_for_each(cur, &dm_device.ha_region_list) {
has = list_entry(cur, struct hv_hotadd_state, list);
- cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
+ cur_start_pgp = (unsigned long)
+ pfn_to_page(has->covered_start_pfn);
cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
if (((unsigned long)pg >= cur_start_pgp) &&
@@ -854,6 +856,7 @@ static unsigned long process_hot_add(uns
list_add_tail(&ha_region->list, &dm_device.ha_region_list);
ha_region->start_pfn = rg_start;
ha_region->ha_end_pfn = rg_start;
+ ha_region->covered_start_pfn = pg_start;
ha_region->covered_end_pfn = pg_start;
ha_region->end_pfn = rg_start + rg_size;
}
[PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd upstream.
Before we rework the "pmem api" to stop abusing __copy_user_nocache()
for memcpy_to_pmem() we need to fix cases where we may strand dirty data
in the cpu cache. The problem occurs when copy_from_iter_pmem() is used
for arbitrary data transfers from userspace. There is no guarantee that
these transfers, performed by dax_iomap_actor(), will have aligned
destinations or aligned transfer lengths. Backstop the usage
__copy_user_nocache() with explicit cache management in these unaligned
cases.
Yes, copy_from_iter_pmem() is now too big for an inline, but addressing
that is saved for a later patch that moves the entirety of the "pmem
api" into the pmem driver directly.
Fixes: 5de490daec8b ("pmem: add copy_from_iter_pmem() and clear_pmem()")
Cc:
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Ingo Molnar
Cc: Christoph Hellwig
Cc: "H. Peter Anvin"
Cc: Al Viro
Cc: Thomas Gleixner
Cc: Matthew Wilcox
Reviewed-by: Ross Zwisler
Signed-off-by: Toshi Kani
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/pmem.h | 45 +++-
1 file changed, 32 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -72,8 +72,8 @@ static inline void arch_wmb_pmem(void)
* @size: number of bytes to write back
*
* Write back a cache range using the CLWB (cache line write back)
- * instruction. This function requires explicit ordering with an
- * arch_wmb_pmem() call. This API is internal to the x86 PMEM implementation.
+ * instruction. Note that @size is internally rounded up to be cache
+ * line size aligned.
*/
static inline void __arch_wb_cache_pmem(void *vaddr, size_t size)
{
@@ -87,15 +87,6 @@ static inline void __arch_wb_cache_pmem(
clwb(p);
}
-/*
- * copy_from_iter_nocache() on x86 only uses non-temporal stores for iovec
- * iterators, so for other types (bvec & kvec) we must do a cache write-back.
- */
-static inline bool __iter_needs_pmem_wb(struct iov_iter *i)
-{
- return iter_is_iovec(i) == false;
-}
-
/**
* arch_copy_from_iter_pmem - copy data from an iterator to PMEM
* @addr: PMEM destination address
@@ -114,8 +105,36 @@ static inline size_t arch_copy_from_iter
/* TODO: skip the write-back by always using non-temporal stores */
len = copy_from_iter_nocache(vaddr, bytes, i);
- if (__iter_needs_pmem_wb(i))
- __arch_wb_cache_pmem(vaddr, bytes);
+ /*
+* In the iovec case on x86_64 copy_from_iter_nocache() uses
+* non-temporal stores for the bulk of the transfer, but we need
+* to manually flush if the transfer is unaligned. A cached
+* memory copy is used when destination or size is not naturally
+* aligned. That is:
+* - Require 8-byte alignment when size is 8 bytes or larger.
+* - Require 4-byte alignment when size is 4 bytes.
+*
+* In the non-iovec case the entire destination needs to be
+* flushed.
+*/
+ if (iter_is_iovec(i)) {
+ unsigned long flushed, dest = (unsigned long) addr;
+
+ if (bytes < 8) {
+ if (!IS_ALIGNED(dest, 4) || (bytes != 4))
+ __arch_wb_cache_pmem(addr, 1);
+ } else {
+ if (!IS_ALIGNED(dest, 8)) {
+ dest = ALIGN(dest,
boot_cpu_data.x86_clflush_size);
+ __arch_wb_cache_pmem(addr, 1);
+ }
+
+ flushed = dest - (unsigned long) addr;
+ if (bytes > flushed && !IS_ALIGNED(bytes - flushed, 8))
+ __arch_wb_cache_pmem(addr + bytes - 1, 1);
+ }
+ } else
+ __arch_wb_cache_pmem(addr, bytes);
return len;
}
[PATCH 2/2] power: supply: sbs-battery: Correct supply status with current draw
The status reported directly by the battery controller is not always
reliable and should be corrected based on the current draw information.
This implements such a correction with a dedicated function, called
where the supply status is retrieved.
Signed-off-by: Paul Kocialkowski
---
drivers/power/supply/sbs-battery.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/power/supply/sbs-battery.c
b/drivers/power/supply/sbs-battery.c
index 3e7125c8e4d1..29c4e277abf1 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -295,6 +295,31 @@ static int sbs_write_word_data(struct i2c_client *client,
u8 address,
return 0;
}
+static int sbs_status_correct(struct i2c_client *client, int *intval)
+{
+ int ret;
+
+ ret = sbs_read_word_data(client, sbs_data[REG_CURRENT].addr);
+ if (ret < 0)
+ return ret;
+
+ ret = (s16)ret;
+
+ /* Not drawing current means full (cannot be not charging) */
+ if (ret == 0)
+ *intval = POWER_SUPPLY_STATUS_FULL;
+
+ if (*intval == POWER_SUPPLY_STATUS_FULL) {
+ /* Drawing or providing current when full */
+ if (ret > 0)
+ *intval = POWER_SUPPLY_STATUS_CHARGING;
+ else if (ret < 0)
+ *intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ }
+
+ return 0;
+}
+
static int sbs_get_battery_presence_and_health(
struct i2c_client *client, enum power_supply_property psp,
union power_supply_propval *val)
@@ -401,6 +426,8 @@ static int sbs_get_battery_property(struct i2c_client
*client,
else
val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ sbs_status_correct(client, &val->intval);
+
if (chip->poll_time == 0)
chip->last_state = val->intval;
else if (chip->last_state != val->intval) {
@@ -721,6 +748,8 @@ static void sbs_delayed_work(struct work_struct *work)
else
ret = POWER_SUPPLY_STATUS_CHARGING;
+ sbs_status_correct(chip->client, &ret);
+
if (chip->last_state != ret) {
chip->poll_time = 0;
power_supply_changed(chip->power_supply);
--
2.12.2
[PATCH 4.4 22/28] Tools: hv: kvp: ensure kvp device fd is closed on exec
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
commit 26840437cbd6d3625ea6ab34e17cd34bb810c861 upstream.
KVP daemon does fork()/exec() (with popen()) so we need to close our fds
to avoid sharing them with child processes. The immediate implication of
not doing so I see is SELinux complaining about 'ip' trying to access
'/dev/vmbus/hv_kvp'.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Sumit Semwal
Signed-off-by: Greg Kroah-Hartman
---
tools/hv/hv_kvp_daemon.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1433,7 +1433,7 @@ int main(int argc, char *argv[])
openlog("KVP", 0, LOG_USER);
syslog(LOG_INFO, "KVP starting; pid is:%d", getpid());
- kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR);
+ kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR | O_CLOEXEC);
if (kvp_fd < 0) {
syslog(LOG_ERR, "open /dev/vmbus/hv_kvp failed; error: %d %s",
[PATCH 4.4 27/28] block: fix del_gendisk() vs blkdev_ioctl crash
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit ac34f15e0c6d2fd58480052b6985f6991fb53bcc upstream. When tearing down a block device early in its lifetime, userspace may still be performing discovery actions like blkdev_ioctl() to re-read partitions. The nvdimm_revalidate_disk() implementation depends on disk->driverfs_dev to be valid at entry. However, it is set to NULL in del_gendisk() and fatally this is happening *before* the disk device is deleted from userspace view. There's no reason for del_gendisk() to clear ->driverfs_dev. That device is the parent of the disk. It is guaranteed to not be freed until the disk, as a child, drops its ->parent reference. We could also fix this issue locally in nvdimm_revalidate_disk() by using disk_to_dev(disk)->parent, but lets fix it globally since ->driverfs_dev follows the lifetime of the parent. Longer term we should probably just add a @parent parameter to add_disk(), and stop carrying this pointer in the gendisk. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] nvdimm_revalidate_disk+0x18/0x90 [libnvdimm] CPU: 2 PID: 538 Comm: systemd-udevd Tainted: G O4.4.0-rc5 #2257 [..] Call Trace: [] rescan_partitions+0x87/0x2c0 [] ? __lock_is_held+0x49/0x70 [] __blkdev_reread_part+0x72/0xb0 [] blkdev_reread_part+0x25/0x40 [] blkdev_ioctl+0x4fd/0x9c0 [] ? current_kernel_time64+0x69/0xd0 [] block_ioctl+0x3d/0x50 [] do_vfs_ioctl+0x308/0x560 [] ? __audit_syscall_entry+0xb1/0x100 [] ? do_audit_syscall_entry+0x66/0x70 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x76 Cc: Jan Kara Cc: Jens Axboe Reported-by: Robert Hu Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman --- block/genhd.c |1 - 1 file changed, 1 deletion(-) --- a/block/genhd.c +++ b/block/genhd.c @@ -664,7 +664,6 @@ void del_gendisk(struct gendisk *disk) kobject_put(disk->part0.holder_dir); kobject_put(disk->slave_dir); - disk->driverfs_dev = NULL; if (!sysfs_deprecated) sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk))); pm_runtime_set_memalloc_noio(disk_to_dev(disk), false);
[PATCH 4.4 14/28] ACPI / power: Avoid maybe-uninitialized warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream.
gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
is enterered at least once, so it assumes that cur_state might not get
initialized:
drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
This sets the variable to zero at the start of the loop, to ensure that
there is well-defined behavior even for an empty list. This gets rid of
the warning.
The warning first showed up when the -Os flag got removed in a bug fix
patch in linux-4.11-rc5.
I would suggest merging this addon patch on top of that bug fix to avoid
introducing a new warning in the stable kernels.
Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph
tracing)
Signed-off-by: Arnd Bergmann
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/power.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -200,6 +200,7 @@ static int acpi_power_get_list_state(str
return -EINVAL;
/* The state of the list is 'on' IFF all resources are 'on'. */
+ cur_state = 0;
list_for_each_entry(entry, list, node) {
struct acpi_power_resource *resource = entry->resource;
acpi_handle handle = resource->device.handle;
[PATCH 4.4 03/28] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.
This fixes CVE-2017-7472.
Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:
#include
int main()
{
for (;;)
keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
}
Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.
Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/keyctl.c | 11 +++---
security/keys/process_keys.c | 44 ++-
2 files changed, 31 insertions(+), 24 deletions(-)
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1228,8 +1228,8 @@ error:
* Read or set the default keyring in which request_key() will cache keys and
* return the old setting.
*
- * If a process keyring is specified then this will be created if it doesn't
- * yet exist. The old setting will be returned if successful.
+ * If a thread or process keyring is specified then it will be created if it
+ * doesn't yet exist. The old setting will be returned if successful.
*/
long keyctl_set_reqkey_keyring(int reqkey_defl)
{
@@ -1254,11 +1254,8 @@ long keyctl_set_reqkey_keyring(int reqke
case KEY_REQKEY_DEFL_PROCESS_KEYRING:
ret = install_process_keyring_to_cred(new);
- if (ret < 0) {
- if (ret != -EEXIST)
- goto error;
- ret = 0;
- }
+ if (ret < 0)
+ goto error;
goto set;
case KEY_REQKEY_DEFL_DEFAULT:
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -125,13 +125,18 @@ error:
}
/*
- * Install a fresh thread keyring directly to new credentials. This keyring is
- * allowed to overrun the quota.
+ * Install a thread keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
int install_thread_keyring_to_cred(struct cred *new)
{
struct key *keyring;
+ if (new->thread_keyring)
+ return 0;
+
keyring = keyring_alloc("_tid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
KEY_ALLOC_QUOTA_OVERRUN, NULL);
@@ -143,7 +148,9 @@ int install_thread_keyring_to_cred(struc
}
/*
- * Install a fresh thread keyring, discarding the old one.
+ * Install a thread keyring to the current task if it didn't have one already.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
static int install_thread_keyring(void)
{
@@ -154,8 +161,6 @@ static int install_thread_keyring(void)
if (!new)
return -ENOMEM;
- BUG_ON(new->thread_keyring);
-
ret = install_thread_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
@@ -166,17 +171,17 @@ static int install_thread_keyring(void)
}
/*
- * Install a process keyring directly to a credentials struct.
+ * Install a process keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
*
- * Returns -EEXIST if there was already a process keyring, 0 if one installed,
- * and other value on any other error
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
int install_process_keyring_to_cred(struct cred *new)
{
struct key *keyring;
if (new->process_keyring)
- return -EEXIST;
+ return 0;
keyring = keyring_alloc("_pid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
@@ -189,11 +194,9 @@ int install_process_keyring_to_cred(stru
}
/*
- * Make sure a process keyring is installed for the current process. The
- * existing process keyring is not replaced.
+ * Install a process keyring to the current task if it didn't have one already.
*
- * Returns 0 if there is a process keyring by the end of this function, some
- * error otherwise.
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
static int install_process_keyring(void)
{
@@ -207,14 +210,18 @@ static int install_process_keyring(void)
ret = install_process_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
- return ret != -EEXIST ? ret : 0;
+ return ret;
}
return comm
[PATCH 4.4 04/28] tracing: Allocate the snapshot buffer before enabling probe
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (VMware)
commit df62db5be2e5f070ecd1a5ece5945b590ee112e0 upstream.
Currently the snapshot trigger enables the probe and then allocates the
snapshot. If the probe triggers before the allocation, it could cause the
snapshot to fail and turn tracing off. It's best to allocate the snapshot
buffer first, and then enable the trigger. If something goes wrong in the
enabling of the trigger, the snapshot buffer is still allocated, but it can
also be freed by the user by writting zero into the snapshot buffer file.
Also add a check of the return status of alloc_snapshot().
Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes")
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
---
kernel/trace/trace.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6060,11 +6060,13 @@ ftrace_trace_snapshot_callback(struct ft
return ret;
out_reg:
- ret = register_ftrace_function_probe(glob, ops, count);
+ ret = alloc_snapshot(&global_trace);
+ if (ret < 0)
+ goto out;
- if (ret >= 0)
- alloc_snapshot(&global_trace);
+ ret = register_ftrace_function_probe(glob, ops, count);
+ out:
return ret < 0 ? ret : 0;
}
[PATCH 4.4 07/28] CIFS: remove bad_network_name flag
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Germano Percossi
commit a0918f1ce6a43ac980b42b300ec443c154970979 upstream.
STATUS_BAD_NETWORK_NAME can be received during node failover,
causing the flag to be set and making the reconnect thread
always unsuccessful, thereafter.
Once the only place where it is set is removed, the remaining
bits are rendered moot.
Removing it does not prevent "mount" from failing when a non
existent share is passed.
What happens when the share really ceases to exist while the
share is mounted is undefined now as much as it was before.
Signed-off-by: Germano Percossi
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/cifsglob.h |1 -
fs/cifs/smb2pdu.c |5 -
2 files changed, 6 deletions(-)
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -906,7 +906,6 @@ struct cifs_tcon {
bool use_persistent:1; /* use persistent instead of durable handles */
#ifdef CONFIG_CIFS_SMB2
bool print:1; /* set if connection to printer share */
- bool bad_network_name:1; /* set if ret status STATUS_BAD_NETWORK_NAME */
__le32 capabilities;
__u32 share_flags;
__u32 maximal_access;
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -932,9 +932,6 @@ SMB2_tcon(const unsigned int xid, struct
else
return -EIO;
- if (tcon && tcon->bad_network_name)
- return -ENOENT;
-
if ((tcon && tcon->seal) &&
((ses->server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION) == 0)) {
cifs_dbg(VFS, "encryption requested but no server support");
@@ -1036,8 +1033,6 @@ tcon_exit:
tcon_error_exit:
if (rsp->hdr.Status == STATUS_BAD_NETWORK_NAME) {
cifs_dbg(VFS, "BAD_NETWORK_NAME: %s\n", tree);
- if (tcon)
- tcon->bad_network_name = true;
}
goto tcon_exit;
}
[PATCH 4.9 01/21] KEYS: Disallow keyrings beginning with . to be joined as session keyrings
4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Howells commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream. This fixes CVE-2016-9604. Keyrings whose name begin with a '.' are special internal keyrings and so userspace isn't allowed to create keyrings by this name to prevent shadowing. However, the patch that added the guard didn't fix KEYCTL_JOIN_SESSION_KEYRING. Not only can that create dot-named keyrings, it can also subscribe to them as a session keyring if they grant SEARCH permission to the user. This, for example, allows a root process to set .builtin_trusted_keys as its session keyring, at which point it has full access because now the possessor permissions are added. This permits root to add extra public keys, thereby bypassing module verification. This also affects kexec and IMA. This can be tested by (as root): keyctl session .builtin_trusted_keys keyctl add user a a @s keyctl list @s which on my test box gives me: 2 keys in keyring: 180010936: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05 801382539: --alswrv 0 0 user: a Fix this by rejecting names beginning with a '.' in the keyctl. Signed-off-by: David Howells Acked-by: Mimi Zohar cc: linux-ima-de...@lists.sourceforge.net Signed-off-by: Greg Kroah-Hartman --- security/keys/keyctl.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -271,7 +271,8 @@ error: * Create and join an anonymous session keyring or join a named session * keyring, creating it if necessary. A named session keyring must have Search * permission for it to be joined. Session keyrings without this permit will - * be skipped over. + * be skipped over. It is not permitted for userspace to create or join + * keyrings whose name begin with a dot. * * If successful, the ID of the joined session keyring will be returned. */ @@ -288,12 +289,16 @@ long keyctl_join_session_keyring(const c ret = PTR_ERR(name); goto error; } + + ret = -EPERM; + if (name[0] == '.') + goto error_name; } /* join the session */ ret = join_session_keyring(name); +error_name: kfree(name); - error: return ret; }
[PATCH 4.4 05/28] ring-buffer: Have ring_buffer_iter_empty() return true when empty
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (VMware)
commit 78f7a45dac2a2d2002f98a3a95f7979867868d73 upstream.
I noticed that reading the snapshot file when it is empty no longer gives a
status. It suppose to show the status of the snapshot buffer as well as how
to allocate and use it. For example:
># cat snapshot
# tracer: nop
#
#
# * Snapshot is allocated *
#
# Snapshot commands:
# echo 0 > snapshot : Clears and frees snapshot buffer
# echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
# Takes a snapshot of the main buffer.
# echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
# (Doesn't have to be '2' works with any number that
# is not a '0' or '1')
But instead it just showed an empty buffer:
># cat snapshot
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:4
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
What happened was that it was using the ring_buffer_iter_empty() function to
see if it was empty, and if it was, it showed the status. But that function
was returning false when it was empty. The reason was that the iter header
page was on the reader page, and the reader page was empty, but so was the
buffer itself. The check only tested to see if the iter was on the commit
page, but the commit page was no longer pointing to the reader page, but as
all pages were empty, the buffer is also.
Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page")
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
---
kernel/trace/ring_buffer.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3440,11 +3440,23 @@ EXPORT_SYMBOL_GPL(ring_buffer_iter_reset
int ring_buffer_iter_empty(struct ring_buffer_iter *iter)
{
struct ring_buffer_per_cpu *cpu_buffer;
+ struct buffer_page *reader;
+ struct buffer_page *head_page;
+ struct buffer_page *commit_page;
+ unsigned commit;
cpu_buffer = iter->cpu_buffer;
- return iter->head_page == cpu_buffer->commit_page &&
- iter->head == rb_commit_index(cpu_buffer);
+ /* Remember, trace recording is off when iterator is in use */
+ reader = cpu_buffer->reader_page;
+ head_page = cpu_buffer->head_page;
+ commit_page = cpu_buffer->commit_page;
+ commit = rb_page_commit(commit_page);
+
+ return ((iter->head_page == commit_page && iter->head == commit) ||
+ (iter->head_page == reader && commit_page == head_page &&
+head_page->read == commit &&
+iter->head == rb_page_commit(cpu_buffer->reader_page)));
}
EXPORT_SYMBOL_GPL(ring_buffer_iter_empty);
[PATCH 4.4 28/28] tipc: fix crash during node removal
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jon Paul Maloy
commit d25a01257e422a4bdeb426f69529d57c73b235fe upstream.
When the TIPC module is unloaded, we have identified a race condition
that allows a node reference counter to go to zero and the node instance
being freed before the node timer is finished with accessing it. This
leads to occasional crashes, especially in multi-namespace environments.
The scenario goes as follows:
CPU0:(node_stop) CPU1:(node_timeout) // ref == 2
1: if(!mod_timer())
2: if (del_timer())
3: tipc_node_put()// ref -> 1
4: tipc_node_put() // ref -> 0
5: kfree_rcu(node);
6: tipc_node_get(node)
7: // BOOM!
We now clean up this functionality as follows:
1) We remove the node pointer from the node lookup table before we
attempt deactivating the timer. This way, we reduce the risk that
tipc_node_find() may obtain a valid pointer to an instance marked
for deletion; a harmless but undesirable situation.
2) We use del_timer_sync() instead of del_timer() to safely deactivate
the node timer without any risk that it might be reactivated by the
timeout handler. There is no risk of deadlock here, since the two
functions never touch the same spinlocks.
3: We remove a pointless tipc_node_get() + tipc_node_put() from the
timeout handler.
Reported-by: Zhijiang Hu
Acked-by: Ying Xue
Signed-off-by: Jon Maloy
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/tipc/node.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -102,9 +102,10 @@ static unsigned int tipc_hashfn(u32 addr
static void tipc_node_kref_release(struct kref *kref)
{
- struct tipc_node *node = container_of(kref, struct tipc_node, kref);
+ struct tipc_node *n = container_of(kref, struct tipc_node, kref);
- tipc_node_delete(node);
+ kfree(n->bc_entry.link);
+ kfree_rcu(n, rcu);
}
void tipc_node_put(struct tipc_node *node)
@@ -216,21 +217,20 @@ static void tipc_node_delete(struct tipc
{
list_del_rcu(&node->list);
hlist_del_rcu(&node->hash);
- kfree(node->bc_entry.link);
- kfree_rcu(node, rcu);
+ tipc_node_put(node);
+
+ del_timer_sync(&node->timer);
+ tipc_node_put(node);
}
void tipc_node_stop(struct net *net)
{
- struct tipc_net *tn = net_generic(net, tipc_net_id);
+ struct tipc_net *tn = tipc_net(net);
struct tipc_node *node, *t_node;
spin_lock_bh(&tn->node_list_lock);
- list_for_each_entry_safe(node, t_node, &tn->node_list, list) {
- if (del_timer(&node->timer))
- tipc_node_put(node);
- tipc_node_put(node);
- }
+ list_for_each_entry_safe(node, t_node, &tn->node_list, list)
+ tipc_node_delete(node);
spin_unlock_bh(&tn->node_list_lock);
}
@@ -313,9 +313,7 @@ static void tipc_node_timeout(unsigned l
if (rc & TIPC_LINK_DOWN_EVT)
tipc_node_link_down(n, bearer_id, false);
}
- if (!mod_timer(&n->timer, jiffies + n->keepalive_intv))
- tipc_node_get(n);
- tipc_node_put(n);
+ mod_timer(&n->timer, jiffies + n->keepalive_intv);
}
/**
[PATCH 4.9 10/21] Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Leemhuis
commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream.
Temporary got a Lifebook E547 into my hands and noticed the touchpad
only works after running:
echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
Add it to the list of machines that need this workaround.
Signed-off-by: Thorsten Leemhuis
Reviewed-by: Ulrik De Bie
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/mouse/elantech.c |8
1 file changed, 8 insertions(+)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1118,6 +1118,7 @@ static int elantech_get_resolution_v4(st
* Asus UX32VD 0x361f0200, 15, 0e clickpad
* Avatar AVIU-145A2 0x361f00? clickpad
* Fujitsu LIFEBOOK E544 0x470f00d0, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E547 0x470f0050, 12, 09 2 hw buttons
* Fujitsu LIFEBOOK E554 0x570f0140, 14, 0c 2 hw buttons
* Fujitsu T7250x470f0105, 12, 09 2 hw buttons
* Fujitsu H7300x570f00c0, 14, 0c 3 hw buttons (**)
@@ -1524,6 +1525,13 @@ static const struct dmi_system_id elante
},
},
{
+ /* Fujitsu LIFEBOOK E547 does not work with crc_enabled == 0 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E547"),
+ },
+ },
+ {
/* Fujitsu LIFEBOOK E554 does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
[PATCH 4.4 09/28] Drivers: hv: dont leak memory in vmbus_establish_gpadl()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Vitaly Kuznetsov
commit 7cc80c98070ccc7940fc28811c92cca0a681015d upstream.
In some cases create_gpadl_header() allocates submessages but we never
free them.
[sumits] Note for stable:
Upstream commit 4d63763296ab7865a98bc29cc7d77145815ef89f:
(Drivers: hv: get rid of redundant messagecount in create_gpadl_header())
changes the list usage to initialize list header in all cases; that patch
isn't added to stable, so the current patch is modified a little bit from
the upstream commit to check if the list is valid or not.
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Sumit Semwal
Signed-off-by: Greg Kroah-Hartman
---
drivers/hv/channel.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -375,7 +375,7 @@ int vmbus_establish_gpadl(struct vmbus_c
struct vmbus_channel_gpadl_header *gpadlmsg;
struct vmbus_channel_gpadl_body *gpadl_body;
struct vmbus_channel_msginfo *msginfo = NULL;
- struct vmbus_channel_msginfo *submsginfo;
+ struct vmbus_channel_msginfo *submsginfo, *tmp;
u32 msgcount;
struct list_head *curr;
u32 next_gpadl_handle;
@@ -437,6 +437,13 @@ cleanup:
list_del(&msginfo->msglistentry);
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
+ if (msgcount > 1) {
+ list_for_each_entry_safe(submsginfo, tmp, &msginfo->submsglist,
+msglistentry) {
+ kfree(submsginfo);
+ }
+ }
+
kfree(msginfo);
return ret;
}
[PATCH 4.9 13/21] ubifs: Fix RENAME_WHITEOUT support
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Felix Fietkau
commit c3d9fda688742c06e89aa1f0f8fd943fc11468cb upstream.
Remove faulty leftover check in do_rename(), apparently introduced in a
merge that combined whiteout support changes with commit f03b8ad8d386
("fs: support RENAME_NOREPLACE for local filesystems")
Fixes: f03b8ad8d386 ("fs: support RENAME_NOREPLACE for local filesystems")
Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT")
Signed-off-by: Felix Fietkau
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
fs/ubifs/dir.c |3 ---
1 file changed, 3 deletions(-)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -1088,9 +1088,6 @@ static int do_rename(struct inode *old_d
struct timespec time;
unsigned int uninitialized_var(saved_nlink);
- if (flags & ~RENAME_NOREPLACE)
- return -EINVAL;
-
/*
* Budget request settings: deletion direntry, new direntry, removing
* the old inode, and changing old and new parent directory inodes.
[PATCH 4.9 14/21] ubifs: Fix O_TMPFILE corner case in ubifs_link()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Weinberger
commit 32fe905c17f001c0eee13c59afddd0bf2eed509c upstream.
It is perfectly fine to link a tmpfile back using linkat().
Since tmpfiles are created with a link count of 0 they appear
on the orphan list, upon re-linking the inode has to be removed
from the orphan list again.
Ralph faced a filesystem corruption in combination with overlayfs
due to this bug.
Cc: Ralph Sennhauser
Cc: Amir Goldstein
Reported-by: Ralph Sennhauser
Tested-by: Ralph Sennhauser
Reported-by: Amir Goldstein
Fixes: 474b93704f321 ("ubifs: Implement O_TMPFILE")
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
fs/ubifs/dir.c |7 +++
1 file changed, 7 insertions(+)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -622,6 +622,11 @@ static int ubifs_link(struct dentry *old
return err;
lock_2_inodes(dir, inode);
+
+ /* Handle O_TMPFILE corner case, it is allowed to link a O_TMPFILE. */
+ if (inode->i_nlink == 0)
+ ubifs_delete_orphan(c, inode->i_ino);
+
inc_nlink(inode);
ihold(inode);
inode->i_ctime = ubifs_current_time(inode);
@@ -641,6 +646,8 @@ out_cancel:
dir->i_size -= sz_change;
dir_ui->ui_size = dir->i_size;
drop_nlink(inode);
+ if (inode->i_nlink == 0)
+ ubifs_add_orphan(c, inode->i_ino);
unlock_2_inodes(dir, inode);
ubifs_release_budget(c, &req);
iput(inode);
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
v2: rebased, style cleanups, disable mem decode before resize,
handle gmc_v9 as well, round size up to power of two.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 ++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4a16e3c..9484062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..d5ca77a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+ u16 cmd;
+ int r;
+
+ /* Free the doorbell mapping, it most likely needs to move as well */
+ amdgpu_doorbell_fini(adev);
+ pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
+
+ /* Disable memory decoding while we change the BAR addresses and size */
+ pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+ r = pci_resize_resource(adev->pdev, 0, rbar_size);
+ if (r == -ENOSPC)
+ DRM_INFO("Not enough PCI address space for a large BAR.");
+ else if (r && r != -ENOTSUPP)
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+ /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+ BUG_ON(amdgpu_doorbell_init(adev));
Same here.
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
As far as I know there is no SI hardware with resizeable BAR support.
The all VI generation can do this, but I'm not 100% sure if there aren't
any Bonaires out there which can handle it as well that's why I added
gmc_v7 support.
Still need to double check that.
Christian.
Alex
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 4ac9978..1655de2 100644
--- a/drivers/gpu/drm
[PATCH 4.9 16/21] mac80211: fix MU-MIMO follow-MAC mode
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit 9e478066eae41211c92a8f63cc69aafc391bd6ab upstream.
There are two bugs in the follow-MAC code:
* it treats the radiotap header as the 802.11 header
(therefore it can't possibly work)
* it doesn't verify that the skb data it accesses is actually
present in the header, which is mitigated by the first point
Fix this by moving all of this out into a separate function.
This function copies the data it needs using skb_copy_bits()
to make sure it can be accessed if it's paged, and offsets
that by the possibly present vendor radiotap header.
This also makes all those conditions more readable.
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
net/mac80211/rx.c | 65 +++---
1 file changed, 47 insertions(+), 18 deletions(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -208,6 +208,51 @@ ieee80211_rx_radiotap_hdrlen(struct ieee
return len;
}
+static void ieee80211_handle_mu_mimo_mon(struct ieee80211_sub_if_data *sdata,
+struct sk_buff *skb,
+int rtap_vendor_space)
+{
+ struct {
+ struct ieee80211_hdr_3addr hdr;
+ u8 category;
+ u8 action_code;
+ } __packed action;
+
+ if (!sdata)
+ return;
+
+ BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);
+
+ if (skb->len < rtap_vendor_space + sizeof(action) +
+ VHT_MUMIMO_GROUPS_DATA_LEN)
+ return;
+
+ if (!is_valid_ether_addr(sdata->u.mntr.mu_follow_addr))
+ return;
+
+ skb_copy_bits(skb, rtap_vendor_space, &action, sizeof(action));
+
+ if (!ieee80211_is_action(action.hdr.frame_control))
+ return;
+
+ if (action.category != WLAN_CATEGORY_VHT)
+ return;
+
+ if (action.action_code != WLAN_VHT_ACTION_GROUPID_MGMT)
+ return;
+
+ if (!ether_addr_equal(action.hdr.addr1, sdata->u.mntr.mu_follow_addr))
+ return;
+
+ skb = skb_copy(skb, GFP_ATOMIC);
+ if (!skb)
+ return;
+
+ skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME;
+ skb_queue_tail(&sdata->skb_queue, skb);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+}
+
/*
* ieee80211_add_rx_radiotap_header - add radiotap header
*
@@ -515,7 +560,6 @@ ieee80211_rx_monitor(struct ieee80211_lo
struct net_device *prev_dev = NULL;
int present_fcs_len = 0;
unsigned int rtap_vendor_space = 0;
- struct ieee80211_mgmt *mgmt;
struct ieee80211_sub_if_data *monitor_sdata =
rcu_dereference(local->monitor_sdata);
@@ -553,6 +597,8 @@ ieee80211_rx_monitor(struct ieee80211_lo
return remove_monitor_info(local, origskb, rtap_vendor_space);
}
+ ieee80211_handle_mu_mimo_mon(monitor_sdata, origskb, rtap_vendor_space);
+
/* room for the radiotap header based on driver features */
rt_hdrlen = ieee80211_rx_radiotap_hdrlen(local, status, origskb);
needed_headroom = rt_hdrlen - rtap_vendor_space;
@@ -618,23 +664,6 @@ ieee80211_rx_monitor(struct ieee80211_lo
ieee80211_rx_stats(sdata->dev, skb->len);
}
- mgmt = (void *)skb->data;
- if (monitor_sdata &&
- skb->len >= IEEE80211_MIN_ACTION_SIZE + 1 +
VHT_MUMIMO_GROUPS_DATA_LEN &&
- ieee80211_is_action(mgmt->frame_control) &&
- mgmt->u.action.category == WLAN_CATEGORY_VHT &&
- mgmt->u.action.u.vht_group_notif.action_code ==
WLAN_VHT_ACTION_GROUPID_MGMT &&
- is_valid_ether_addr(monitor_sdata->u.mntr.mu_follow_addr) &&
- ether_addr_equal(mgmt->da, monitor_sdata->u.mntr.mu_follow_addr)) {
- struct sk_buff *mu_skb = skb_copy(skb, GFP_ATOMIC);
-
- if (mu_skb) {
- mu_skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME;
- skb_queue_tail(&monitor_sdata->skb_queue, mu_skb);
- ieee80211_queue_work(&local->hw, &monitor_sdata->work);
- }
- }
-
if (prev_dev) {
skb->dev = prev_dev;
netif_receive_skb(skb);
[PATCH 4.9 19/21] x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Yazen Ghannam
commit 29f72ce3e4d18066ec75c79c857bee0618a3504b upstream.
MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
However, MCA bank 3 is defined on Fam17h systems and can be accessed
using legacy MSRs. Without a name we get a stack trace on Fam17h systems
when trying to register sysfs files for bank 3 on kernels that don't
recognize Scalable MCA.
Call MCA bank 3 "decode_unit" since this is what it represents on
Fam17h. This will allow kernels without SMCA support to see this bank on
Fam17h+ and prevent the stack trace. This will not affect older systems
since this bank is reserved on them, i.e. it'll be ignored.
Tested on AMD Fam15h and Fam17h systems.
WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
kobject: (88085bb256c0): attempted to be registered with empty name!
...
Call Trace:
kobject_add_internal
kobject_add
kobject_create_and_add
threshold_create_device
threshold_init_device
Signed-off-by: Yazen Ghannam
Signed-off-by: Borislav Petkov
Link:
http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-yazen.ghan...@amd.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -59,7 +59,7 @@ static const char * const th_names[] = {
"load_store",
"insn_fetch",
"combined_unit",
- "",
+ "decode_unit",
"northbridge",
"execution_unit",
};
[PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them
MSRs in 0xC001102x range (and a few close to this range) allow to modify some internal actions of the pipeline. (There is one non-debug MSR in this range, introduced in Fam15h: MSR 0xC0011027 Address Mask For DR0 Breakpoints, aka DR0_ADDR_MASK). Sometimes these MSRs are used to fix erratas. Let's have a comment about that. Lat's use the following naming scheme for all of them: MSR_FnnH_REGNAME This introduces some redundant names, but documents CPU family where we are reasonably sure a particular register exists, and avoids the need to explain why the same register is either "Combined Unit Cfg" or "Bus Unit Cfg" - obviously, because the name depends on the CPU family. Renaming: MSR_AMD64_DC_CFG -> MSR_F10H_DC_CFG MSR_AMD64_BU_CFG2 -> MSR_F10H_BU_CFG2 MSR_AMD64_LS_CFG -> MSR_F16H_LS_CFG MSR_AMD64_DE_CFG -> MSR_F12H_DE_CFG (and moving to msr-index.h) Here is a little compilation from about a dozen documents. C001_1000: 15h Errata 608 "P-state Limit Changes May Not Generate Interrupts" - worked around by setting bit 16. 15h Errata 671 "Debug Breakpoint on Misaligned Store May Cause System Hang" - worked around by setting bit 17 to 0. - AMD is really reluctant to this workaround, must be painful 15h Errata 727 "Processor Core May Hang During CC6 Resume" - worked around by setting bit 15. - HW fixed in models 10h? C001_1020: K8 Errata 106 "Potential Deadlock with Tightly Coupled Semaphores in an MP System" - worked around by setting bit 25. 10h,12h Errata 670 "Segment Load May Cause System Hang or Fault After State Change" - worked around by setting bit 8. - this bit has something to do with handling of LOCK prefix. 14h Errata 530 "Potential Violation of Read Ordering Rules Between Semaphore Operation and Subsequent Load Operations" - worked around by setting bit 36. 14h Errata 551 "Processor May Not Forward Data From Store to a Page Crossing Read-Modify-Write Operation" - worked around by setting bit 25. 14h Errata 560 "Processor May Incorrectly Forward Data with Non-cacheable Floating-Point 128-bit SSE Operation" - worked around by setting bit 18. 16h Errata 793 "Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang" - worked around by setting bit 15. C001_1021: K8 Errata 94 "Sequential Prefetch Feature May Cause Incorrect Processor Operation" - worked around by setting bit 11. 14h Errata 688 "Processor May Cause Unpredictable Program Behavior Under Highly Specific Branch Conditions" - worked around by setting bits 14 and 3. 16h Errata 776 "Incorrect Processor Branch Prediction for Two Consecutive Linear Pages" - worked around by setting bit 26. - HW fixed in models 30h? C001_1022: K8 Errata 97 "128-Bit Streaming Stores May Cause Coherency Failure" - worked around by setting bit 3. K8 Errata 81 "Cache Coherency Problem with Hardware Prefetching and Streaming Stores" - worked around by setting bit 10. 10h Errata 261 "Processor May Stall Entering Stop-Grant Due to Pending Data Cache Scrub" - worked around by setting bit 24. 10h Errata 326 "Misaligned Load Operation May Cause Processor Core Hang" - worked around by setting bits 43:42 to 00. 10h Errata 383 "CPU Core May Machine Check When System Software Changes Page Tables Dynamically" - worked around by setting bit 47. 15h Errata 674 "Processor May Cache Prefetched Data from Remapped Memory Region" - worked around by setting bit 13. C001_1023: K8 Errata 69 "Multiprocessor Coherency Problem with Hardware Prefetch Mechanism" - worked around by setting bit 45. K8 Errata 113 "Enhanced Write-Combining Feature Causes System Hang" - worked around by setting bit 48. 10h Errata 254 "Internal Resource Livelock Involving Cached TLB Reload" - worked around by setting bit 21. 10h Errata 298 "L2 Eviction May Occur During Processor Operation To Set Accessed or Dirty Bit" - worked around by setting bit 1. 10h Errata 309 "Processor Core May Execute Incorrect Instructions on Concurrent L2 and Northbridge Response" - worked around by setting bit 23. C001_1029: 10h,12h Errata 721 "Processor May Incorrectly Update Stack Pointer" - worked around by setting bit 0. 12h Errata 665 "Integer Divide Instruction May Cause Unpredictable Behavior" - worked around by setting bit 31. Bit 23 serializes CLFLUSH instruction. C001_102A: 15h Errata 503 "APIC Task-Priority Register May Be Incorrect" - worked around by setting bit 11. K8_BKDG documents none of these registers, but Revision Guide mentions them a lot. 10h_BKDG documents them as: MSRC001_1021 Instruction Cache Configuration Register (IC_CFG) MSRC001_1022 Data Cache Configuration (DC_CFG) MSRC001_1023 Bus Unit Configuration Register (BU_CFG) MSRC001_102A Bus Unit Configuration 2 (BU_CFG2) 11h_BKDG documents: MSRC001_1022 Data Cache Configuration (DC_CFG) MSRC001_1023 Bus Unit Configuration Register (BU_CFG) 12h_BKDG documents: MSRC001_1020 Load-Sto
[PATCH 4.9 02/21] KEYS: Change the name of the dead type to ".dead" to prevent user access
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: David Howells
commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.
This fixes CVE-2017-6951.
Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs. Attempting to use it may cause the kernel to crash.
Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().
Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:
commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
Author: David Howells
Date: Tue Sep 16 17:36:06 2014 +0100
KEYS: Remove key_type::match in favour of overriding default by
match_preparse
which went in before 3.18-rc1.
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/gc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -46,7 +46,7 @@ static unsigned long key_gc_flags;
* immediately unlinked.
*/
struct key_type key_type_dead = {
- .name = "dead",
+ .name = ".dead",
};
/*
[PATCH 4.9 17/21] ubi/upd: Always flush after prepared for an update
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Siewior
commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.
In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:
|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592
All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.
So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/ubi/upd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/mtd/ubi/upd.c
+++ b/drivers/mtd/ubi/upd.c
@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device *
return err;
}
- if (bytes == 0) {
- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
- if (err)
- return err;
+ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
+ if (err)
+ return err;
+ if (bytes == 0) {
err = clear_update_marker(ubi, vol, 0);
if (err)
return err;
[PATCH 4.9 20/21] x86/mce: Make the MCE notifier a blocking one
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vishal Verma
commit 0dc9c639e6553e39c13b2c0d54c8a1b098cb95e2 upstream.
The NFIT MCE handler callback (for handling media errors on NVDIMMs)
takes a mutex to add the location of a memory error to a list. But since
the notifier call chain for machine checks (x86_mce_decoder_chain) is
atomic, we get a lockdep splat like:
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:620
in_atomic(): 1, irqs_disabled(): 0, pid: 4, name: kworker/0:0
[..]
Call Trace:
dump_stack
___might_sleep
__might_sleep
mutex_lock_nested
? __lock_acquire
nfit_handle_mce
notifier_call_chain
atomic_notifier_call_chain
? atomic_notifier_call_chain
mce_gen_pool_process
Convert the notifier to a blocking one which gets to run only in process
context.
Boris: remove the notifier call in atomic context in print_mce(). For
now, let's print the MCE on the atomic path so that we can make sure
they go out and get logged at least.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Ross Zwisler
Signed-off-by: Vishal Verma
Acked-by: Tony Luck
Cc: Dan Williams
Cc: linux-edac
Cc: x86-ml
Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.ve...@intel.com
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/mcheck/mce-genpool.c |2 +-
arch/x86/kernel/cpu/mcheck/mce-internal.h |2 +-
arch/x86/kernel/cpu/mcheck/mce.c | 16 +++-
3 files changed, 5 insertions(+), 15 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
@@ -85,7 +85,7 @@ void mce_gen_pool_process(void)
head = llist_reverse_order(head);
llist_for_each_entry_safe(node, tmp, head, llnode) {
mce = &node->mce;
- atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
+ blocking_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
}
}
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -13,7 +13,7 @@ enum severity_level {
MCE_PANIC_SEVERITY,
};
-extern struct atomic_notifier_head x86_mce_decoder_chain;
+extern struct blocking_notifier_head x86_mce_decoder_chain;
#define ATTR_LEN 16
#define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -120,7 +120,7 @@ static void (*quirk_no_way_out)(int bank
* CPU/chipset specific EDAC code can register a notifier call here to print
* MCE errors in a human-readable form.
*/
-ATOMIC_NOTIFIER_HEAD(x86_mce_decoder_chain);
+BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain);
/* Do initial initialization of a struct mce */
void mce_setup(struct mce *m)
@@ -213,13 +213,13 @@ void mce_register_decode_chain(struct no
if (nb != &mce_srao_nb && nb->priority == INT_MAX)
nb->priority -= 1;
- atomic_notifier_chain_register(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_register(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_register_decode_chain);
void mce_unregister_decode_chain(struct notifier_block *nb)
{
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_unregister_decode_chain);
@@ -272,8 +272,6 @@ struct mca_msr_regs msr_ops = {
static void print_mce(struct mce *m)
{
- int ret = 0;
-
pr_emerg(HW_ERR "CPU %d: Machine Check Exception: %Lx Bank %d:
%016Lx\n",
m->extcpu, m->mcgstatus, m->bank, m->status);
@@ -309,14 +307,6 @@ static void print_mce(struct mce *m)
m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid,
cpu_data(m->extcpu).microcode);
- /*
-* Print out human-readable details about the MCE error,
-* (if the CPU has an implementation for that)
-*/
- ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m);
- if (ret == NOTIFY_STOP)
- return;
-
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n");
}
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 05:22:36PM +0200, Peter Zijlstra wrote: > On Tue, Apr 25, 2017 at 05:12:00PM +0200, Peter Zijlstra wrote: > > But I'll first try and figure out why I'm not having empty masks. > > Ah, so this is before all the degenerate stuff, so there's a bunch of > redundant domains below that make it work -- and there always will be, > unless FORCE_SD_OVERLAP. > > Now I wonder what triggered it.. let me put it back. Ah! the asymmetric setup, where @sibling is entirely uninitialized for the top domain.
[PATCH 4.9 21/21] device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 956a4cd2c957acf638ff29951aabaa9d8e92bbc2 upstream.
The following warning triggers with a new unit test that stresses the
device-dax interface.
===
[ ERR: suspicious RCU usage. ]
4.11.0-rc4+ #1049 Tainted: G O
---
./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side
critical section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
2 locks held by fio/9070:
#0: (&mm->mmap_sem){++}, at: []
__do_page_fault+0x167/0x4f0
#1: (rcu_read_lock){..}, at: []
dax_dev_huge_fault+0x32/0x620 [dax]
Call Trace:
dump_stack+0x86/0xc3
lockdep_rcu_suspicious+0xd7/0x110
___might_sleep+0xac/0x250
__might_sleep+0x4a/0x80
__alloc_pages_nodemask+0x23a/0x360
alloc_pages_current+0xa1/0x1f0
pte_alloc_one+0x17/0x80
__pte_alloc+0x1e/0x120
__get_locked_pte+0x1bf/0x1d0
insert_pfn.isra.70+0x3a/0x100
? lookup_memtype+0xa6/0xd0
vm_insert_mixed+0x64/0x90
dax_dev_huge_fault+0x520/0x620 [dax]
? dax_dev_huge_fault+0x32/0x620 [dax]
dax_dev_fault+0x10/0x20 [dax]
__do_fault+0x1e/0x140
__handle_mm_fault+0x9af/0x10d0
handle_mm_fault+0x16d/0x370
? handle_mm_fault+0x47/0x370
__do_page_fault+0x28c/0x4f0
trace_do_page_fault+0x58/0x2a0
do_async_page_fault+0x1a/0xa0
async_page_fault+0x28/0x30
Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/dax/Kconfig |1 +
drivers/dax/dax.c | 13 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -2,6 +2,7 @@ menuconfig DEV_DAX
tristate "DAX: direct access to differentiated memory"
default m if NVDIMM_DAX
depends on TRANSPARENT_HUGEPAGE
+ select SRCU
help
Support raw access to differentiated (persistence, bandwidth,
latency...) memory via an mmap(2) capable character
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -24,6 +24,7 @@
#include "dax.h"
static dev_t dax_devt;
+DEFINE_STATIC_SRCU(dax_srcu);
static struct class *dax_class;
static DEFINE_IDA(dax_minor_ida);
static int nr_dax = CONFIG_NR_DEV_DAX;
@@ -59,7 +60,7 @@ struct dax_region {
* @region - parent region
* @dev - device backing the character device
* @cdev - core chardev data
- * @alive - !alive + rcu grace period == no new mappings can be established
+ * @alive - !alive + srcu grace period == no new mappings can be established
* @id - child id in the region
* @num_resources - number of physical address extents in this device
* @res - array of physical address ranges
@@ -437,7 +438,7 @@ static int __dax_dev_pmd_fault(struct da
static int dax_dev_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
pmd_t *pmd, unsigned int flags)
{
- int rc;
+ int rc, id;
struct file *filp = vma->vm_file;
struct dax_dev *dax_dev = filp->private_data;
@@ -445,9 +446,9 @@ static int dax_dev_pmd_fault(struct vm_a
current->comm, (flags & FAULT_FLAG_WRITE)
? "write" : "read", vma->vm_start, vma->vm_end);
- rcu_read_lock();
+ id = srcu_read_lock(&dax_srcu);
rc = __dax_dev_pmd_fault(dax_dev, vma, addr, pmd, flags);
- rcu_read_unlock();
+ srcu_read_unlock(&dax_srcu, id);
return rc;
}
@@ -563,11 +564,11 @@ static void unregister_dax_dev(void *dev
* Note, rcu is not protecting the liveness of dax_dev, rcu is
* ensuring that any fault handlers that might have seen
* dax_dev->alive == true, have completed. Any fault handlers
-* that start after synchronize_rcu() has started will abort
+* that start after synchronize_srcu() has started will abort
* upon seeing dax_dev->alive == false.
*/
dax_dev->alive = false;
- synchronize_rcu();
+ synchronize_srcu(&dax_srcu);
unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
cdev_del(cdev);
device_unregister(dev);
[PATCH 4.9 03/21] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.
This fixes CVE-2017-7472.
Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:
#include
int main()
{
for (;;)
keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
}
Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.
Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/keyctl.c | 11 +++---
security/keys/process_keys.c | 44 ++-
2 files changed, 31 insertions(+), 24 deletions(-)
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1256,8 +1256,8 @@ error:
* Read or set the default keyring in which request_key() will cache keys and
* return the old setting.
*
- * If a process keyring is specified then this will be created if it doesn't
- * yet exist. The old setting will be returned if successful.
+ * If a thread or process keyring is specified then it will be created if it
+ * doesn't yet exist. The old setting will be returned if successful.
*/
long keyctl_set_reqkey_keyring(int reqkey_defl)
{
@@ -1282,11 +1282,8 @@ long keyctl_set_reqkey_keyring(int reqke
case KEY_REQKEY_DEFL_PROCESS_KEYRING:
ret = install_process_keyring_to_cred(new);
- if (ret < 0) {
- if (ret != -EEXIST)
- goto error;
- ret = 0;
- }
+ if (ret < 0)
+ goto error;
goto set;
case KEY_REQKEY_DEFL_DEFAULT:
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -127,13 +127,18 @@ error:
}
/*
- * Install a fresh thread keyring directly to new credentials. This keyring is
- * allowed to overrun the quota.
+ * Install a thread keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
int install_thread_keyring_to_cred(struct cred *new)
{
struct key *keyring;
+ if (new->thread_keyring)
+ return 0;
+
keyring = keyring_alloc("_tid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
KEY_ALLOC_QUOTA_OVERRUN,
@@ -146,7 +151,9 @@ int install_thread_keyring_to_cred(struc
}
/*
- * Install a fresh thread keyring, discarding the old one.
+ * Install a thread keyring to the current task if it didn't have one already.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
static int install_thread_keyring(void)
{
@@ -157,8 +164,6 @@ static int install_thread_keyring(void)
if (!new)
return -ENOMEM;
- BUG_ON(new->thread_keyring);
-
ret = install_thread_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
@@ -169,17 +174,17 @@ static int install_thread_keyring(void)
}
/*
- * Install a process keyring directly to a credentials struct.
+ * Install a process keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
*
- * Returns -EEXIST if there was already a process keyring, 0 if one installed,
- * and other value on any other error
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
int install_process_keyring_to_cred(struct cred *new)
{
struct key *keyring;
if (new->process_keyring)
- return -EEXIST;
+ return 0;
keyring = keyring_alloc("_pid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
@@ -193,11 +198,9 @@ int install_process_keyring_to_cred(stru
}
/*
- * Make sure a process keyring is installed for the current process. The
- * existing process keyring is not replaced.
+ * Install a process keyring to the current task if it didn't have one already.
*
- * Returns 0 if there is a process keyring by the end of this function, some
- * error otherwise.
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
static int install_process_keyring(void)
{
@@ -211,14 +214,18 @@ static int install_process_keyring(void)
ret = install_process_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
- return ret != -EEXIST ? ret : 0;
+ return ret;
}
return commit_cred
Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt
Hello David!
> 25 апр. 2017 г., в 17:36, David Miller написал(а):
>
> So... what are we doing here?
>
> My understanding is that this should fix the same problem that commit
> 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy: micrel: Disable auto
> negotiation on startup") fixed and that this micrel commit should thus
> be reverted to improve MAC startup times which regressed.
>
> Florian, any guidance?
Yes, this should be done.
I aksed Alexandre to check if 99f81afc139c6edd14d77a91ee91685a414a1c66 ("phy:
micrel: Disable auto
negotiation on startup») can be reverted, and he answered what it may do that
sometime this/next week.
Alexander.
[PATCH 0/3] drm/sun4i: More cleanups and fixes
Hi Maxime, The subject is probably getting old. Here are a few more cleanups. Patch 1 should have been part of the patch drm/sun4i: Use lists to track registered display backends and TCONs from my multiple pipeline support series. Please squash it in if you can. Patch 2 just moves setting the TCON clocks back inside the TCON driver. Patch 3 cleans up a DRM driver debug message. Regards ChenYu Chen-Yu Tsai (3): drm/sun4i: Drop unused tcon pointer drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++- drivers/gpu/drm/sun4i/sun4i_drv.h | 1 - drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 -- drivers/gpu/drm/sun4i/sun4i_tcon.c| 6 ++ drivers/gpu/drm/sun4i/sun4i_tv.c | 2 -- 5 files changed, 8 insertions(+), 6 deletions(-) -- 2.11.0
[PATCH 3/3] drm/sun4i: backend: Clarify sun4i_backend_layer_enable debug message
sun4i_backend_layer_enable can be called to enable or disable a layer.
However the debug message always says "Enable", which is confusing.
This patch makes the debug message vary according to the enable state.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index e9eca057ff35..e53107418add 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -73,7 +73,8 @@ void sun4i_backend_layer_enable(struct sun4i_backend *backend,
{
u32 val;
- DRM_DEBUG_DRIVER("Enabling layer %d\n", layer);
+ DRM_DEBUG_DRIVER("%sabling layer %d\n", enable ? "En" : "Dis",
+layer);
if (enable)
val = SUN4I_BACKEND_MODCTL_LAY_EN(layer);
--
2.11.0
[PATCH 2/3] drm/sun4i: Set TCON clock inside sun4i_tconX_mode_set
Currently we are configuring the TCON's dot clock or special clock
directly from the encoder mode_set functions. Since we already
provide mode_set helper functions for the TCON's 2 channels, we
can set the respective clock from those helpers, and reduce the
exposure of the TCON's internals.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 2 --
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++
drivers/gpu/drm/sun4i/sun4i_tv.c | 2 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 1147451eb993..51ece4c39d7e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -175,8 +175,6 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder
*encoder,
sun4i_tcon0_mode_set(tcon, mode);
- clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
-
/* FIXME: This seems to be board specific */
clk_set_phase(tcon->dclk, 120);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8301389c411d..29fd829aa54c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -131,6 +131,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val = 0;
+ /* Configure the dot clock */
+ clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -206,6 +209,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
WARN_ON(!tcon->quirks->has_channel_1);
+ /* Configure the dot clock */
+ clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 49c49431a053..542da220818b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -486,8 +486,6 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
SUN4I_TVE_RESYNC_FIELD : 0));
regmap_write(tv->regs, SUN4I_TVE_SLAVE_REG, 0);
-
- clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
}
static struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
--
2.11.0
[PATCH 1/3] drm/sun4i: Drop unused tcon pointer
The sun4i DRM driver now uses 2 lists to track backends and tcons.
During the switch, the original tcon pointer was not removed.
As it is now unused, remove it, so other new drivers can't accidentally
use it.
Signed-off-by: Chen-Yu Tsai
---
As mentioned in the cover letter, please squash this into the patch
drm/sun4i: Use lists to track registered display backends and TCONs
---
drivers/gpu/drm/sun4i/sun4i_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 835bdb5cc0c2..250c29017ef5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -20,7 +20,6 @@
struct sun4i_drv {
struct list_headbackend_list;
struct list_headtcon_list;
- struct sun4i_tcon *tcon;
struct drm_fbdev_cma*fbdev;
};
--
2.11.0
[PATCH 4.9 06/21] mm: prevent NR_ISOLATE_* stats from going negative
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Rabin Vincent
commit fc280fe871449ead4bdbd1665fa52c7c01c64765 upstream.
Commit 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn
based migration") moved the dec_node_page_state() call (along with the
page_is_file_cache() call) to after putback_lru_page().
But page_is_file_cache() can change after putback_lru_page() is called,
so it should be called before putback_lru_page(), as it was before that
patch, to prevent NR_ISOLATE_* stats from going negative.
Without this fix, non-CONFIG_SMP kernels end up hanging in the
while(too_many_isolated()) { congestion_wait() } loop in
shrink_active_list() due to the negative stats.
Mem-Info:
active_anon:32567 inactive_anon:121 isolated_anon:1
active_file:6066 inactive_file:6639 isolated_file:4294967295
^^
unevictable:0 dirty:115 writeback:0 unstable:0
slab_reclaimable:2086 slab_unreclaimable:3167
mapped:3398 shmem:18366 pagetables:1145 bounce:0
free:1798 free_pcp:13 free_cma:0
Fixes: 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn based
migration")
Link:
http://lkml.kernel.org/r/1492683865-27549-1-git-send-email-rabin.vinc...@axis.com
Signed-off-by: Rabin Vincent
Acked-by: Michal Hocko
Cc: Ming Ling
Cc: Minchan Kim
Cc: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/migrate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -183,9 +183,9 @@ void putback_movable_pages(struct list_h
unlock_page(page);
put_page(page);
} else {
- putback_lru_page(page);
dec_node_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
+ putback_lru_page(page);
}
}
}
[PATCH 4.9 07/21] cifs: Do not send echoes before Negotiate is complete
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Sachin Prabhu
commit 62a6cfddcc0a5313e7da3e8311ba16226fe0ac10 upstream.
commit 4fcd1813e640 ("Fix reconnect to not defer smb3 session reconnect
long after socket reconnect") added support for Negotiate requests to
be initiated by echo calls.
To avoid delays in calling echo after a reconnect, I added the patch
introduced by the commit b8c600120fc8 ("Call echo service immediately
after socket reconnect").
This has however caused a regression with cifs shares which do not have
support for echo calls to trigger Negotiate requests. On connections
which need to call Negotiation, the echo calls trigger an error which
triggers a reconnect which in turn triggers another echo call. This
results in a loop which is only broken when an operation is performed on
the cifs share. For an idle share, it can DOS a server.
The patch uses the smb_operation can_echo() for cifs so that it is
called only if connection has been already been setup.
kernel bz: 194531
Signed-off-by: Sachin Prabhu
Tested-by: Jonathan Liu
Acked-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/smb1ops.c | 10 ++
1 file changed, 10 insertions(+)
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -1015,6 +1015,15 @@ cifs_dir_needs_close(struct cifsFileInfo
return !cfile->srch_inf.endOfSearch && !cfile->invalidHandle;
}
+static bool
+cifs_can_echo(struct TCP_Server_Info *server)
+{
+ if (server->tcpStatus == CifsGood)
+ return true;
+
+ return false;
+}
+
struct smb_version_operations smb1_operations = {
.send_cancel = send_nt_cancel,
.compare_fids = cifs_compare_fids,
@@ -1049,6 +1058,7 @@ struct smb_version_operations smb1_opera
.get_dfs_refer = CIFSGetDFSRefer,
.qfs_tcon = cifs_qfs_tcon,
.is_path_accessible = cifs_is_path_accessible,
+ .can_echo = cifs_can_echo,
.query_path_info = cifs_query_path_info,
.query_file_info = cifs_query_file_info,
.get_srv_inum = cifs_get_srv_inum,
[PATCH 4.10 04/24] tracing: Allocate the snapshot buffer before enabling probe
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (VMware)
commit df62db5be2e5f070ecd1a5ece5945b590ee112e0 upstream.
Currently the snapshot trigger enables the probe and then allocates the
snapshot. If the probe triggers before the allocation, it could cause the
snapshot to fail and turn tracing off. It's best to allocate the snapshot
buffer first, and then enable the trigger. If something goes wrong in the
enabling of the trigger, the snapshot buffer is still allocated, but it can
also be freed by the user by writting zero into the snapshot buffer file.
Also add a check of the return status of alloc_snapshot().
Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes")
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
---
kernel/trace/trace.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6740,11 +6740,13 @@ ftrace_trace_snapshot_callback(struct ft
return ret;
out_reg:
- ret = register_ftrace_function_probe(glob, ops, count);
+ ret = alloc_snapshot(&global_trace);
+ if (ret < 0)
+ goto out;
- if (ret >= 0)
- alloc_snapshot(&global_trace);
+ ret = register_ftrace_function_probe(glob, ops, count);
+ out:
return ret < 0 ? ret : 0;
}
[PATCH 4.10 02/24] KEYS: Change the name of the dead type to ".dead" to prevent user access
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: David Howells
commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.
This fixes CVE-2017-6951.
Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs. Attempting to use it may cause the kernel to crash.
Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().
Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:
commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
Author: David Howells
Date: Tue Sep 16 17:36:06 2014 +0100
KEYS: Remove key_type::match in favour of overriding default by
match_preparse
which went in before 3.18-rc1.
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/gc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -46,7 +46,7 @@ static unsigned long key_gc_flags;
* immediately unlinked.
*/
struct key_type key_type_dead = {
- .name = "dead",
+ .name = ".dead",
};
/*
Re: [PATCH] usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
Am 25.04.2017 um 11:20 schrieb Peter Chen:
>
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f88e9157fad0..60a786c87c06 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1984,6 +1984,7 @@ static void udc_id_switch_for_host(struct
ci_hdrc *ci) int ci_hdrc_gadget_init(struct ci_hdrc *ci) {
struct ci_role_driver *rdrv;
+ int ret;
if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
return -ENXIO;
@@ -1996,7 +1997,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
rdrv->stop = udc_id_switch_for_host;
rdrv->irq = udc_irq;
rdrv->name = "gadget";
- ci->roles[CI_ROLE_GADGET] = rdrv;
- return udc_start(ci);
+ ret = udc_start(ci);
+ if (!ret)
+ ci->roles[CI_ROLE_GADGET] = rdrv;
+
+ return ret;
}
--
>>> Thanks for fixing it. In fact, we'd better return failure if ret &&
>>> ret != -ENXIO at probe, it stands for initialization for host or
>>> gadget has failed.
>>>
>> I got your meaning. I'll cook v2. I don't have preference, since either one
>> can fix the
>> issue.
>>
> Both are needed, you don't need to send this one again. Only a new one,
> thanks.
I'm not sure how easy it is to reproduce the issue.
Shouldn't make a Fixes tag sense at least?
>
> Peter
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
Hello!
On 04/25/2017 06:15 PM, Jon Mason wrote:
Cygnus has a single amac controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
[...]
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 60
++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +
2 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..318899df9972 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
[...]
@@ -295,6 +345,16 @@
status = "disabled";
};
+ eth0: enet@18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x1811 0x1000>;
+ reg-names = "amac_base", "idm_base";
I don't think "_base" suffixes are necessary here.
100% necessary, per the driver. See
drivers/net/ethernet/broadcom/bgmac-platform.c
I'd recommend to fix the driver/bindings then...
MBR, Sergei
[PATCH 4.9 12/21] mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Haibo Chen
commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream.
Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.
This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.
This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50")
Tested-and-reported-by: Tim Harvey
Signed-off-by: Haibo Chen
Acked-by: Dong Aisheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-esdhc-imx.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -830,6 +830,7 @@ static int esdhc_change_pinstate(struct
switch (uhs) {
case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_DDR50:
pinctrl = imx_data->pins_100mhz;
break;
case MMC_TIMING_UHS_SDR104:
[PATCH 4.10 14/24] mmc: dw_mmc: Dont allow Runtime PM for SDIO cards
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Douglas Anderson
commit a6db2c86033bc41329770e90c20d4f1fec3824e4 upstream.
According to the SDIO standard interrupts are normally signalled in a
very complicated way. They require the card clock to be running and
require the controller to be paying close attention to the signals
coming from the card. This simply can't happen with the clock stopped
or with the controller in a low power mode.
To that end, we'll disable runtime_pm when we detect that an SDIO card
was inserted. This is much like with what we do with the special
"SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports.
NOTE: we specifically do this Runtime PM disabling at card init time
rather than in the enable_sdio_irq() callback. This is _different_
than how SDHCI does it. Why do we do it differently?
- Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA
dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD).
- Because we use the standard sdio_irq code:
- We see a constant stream of enable_sdio_irq(0) and
enable_sdio_irq(1) calls. This is because the standard code
disables interrupts while processing and re-enables them after.
- While interrupts are disabled, there's technically a period where
we could get runtime disabled while processing interrupts.
- If we are runtime disabled while processing interrupts, we'll
reset the controller at resume time (see dw_mci_runtime_resume),
which seems like a terrible idea because we could possibly have
another interrupt pending.
To fix the above isues we'd want to put something in the standard
sdio_irq code that makes sure to call pm_runtime get/put when
interrupts are being actively being processed. That's possible to do,
but it seems like a more complicated mechanism when we really just
want the runtime pm disabled always for SDIO cards given that all the
other bits needed to get Runtime PM vs. SDIO just aren't there.
NOTE: at some point in time someone might come up with a fancy way to
do SDIO interrupts and still allow (some) amount of runtime PM.
Technically we could turn off the card clock if we used an alternate
way of signaling SDIO interrupts (and out of band interrupt is one way
to do this). We probably wouldn't actually want to fully runtime
suspend in this case though--at least not with the current
dw_mci_runtime_resume() which basically fully resets the controller at
resume time.
Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Reported-by: Brian Norris
Signed-off-by: Douglas Anderson
Acked-by: Jaehoon Chung
Reviewed-by: Shawn Lin
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/dw_mmc.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1618,10 +1619,16 @@ static void dw_mci_init_card(struct mmc_
if (card->type == MMC_TYPE_SDIO ||
card->type == MMC_TYPE_SD_COMBO) {
- set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
+ if (!test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) {
+ pm_runtime_get_noresume(mmc->parent);
+ set_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
+ }
clk_en_a = clk_en_a_old & ~clken_low_pwr;
} else {
- clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
+ if (test_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags)) {
+ pm_runtime_put_noidle(mmc->parent);
+ clear_bit(DW_MMC_CARD_NO_LOW_PWR, &slot->flags);
+ }
clk_en_a = clk_en_a_old | clken_low_pwr;
}
[PATCH] macsec: dynamically allocate space for sglist
We call skb_cow_data, which is good anyway to ensure we can actually
modify the skb as such (another error from prior). Now that we have the
number of fragments required, we can safely allocate exactly that amount
of memory.
Signed-off-by: Jason A. Donenfeld
Cc: Sabrina Dubroca
Cc: secur...@kernel.org
Cc: sta...@vger.kernel.org
---
drivers/net/macsec.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index dbab05afcdbe..56dafdee4c9c 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -617,7 +617,8 @@ static void macsec_encrypt_done(struct crypto_async_request
*base, int err)
static struct aead_request *macsec_alloc_req(struct crypto_aead *tfm,
unsigned char **iv,
-struct scatterlist **sg)
+struct scatterlist **sg,
+int num_frags)
{
size_t size, iv_offset, sg_offset;
struct aead_request *req;
@@ -629,7 +630,7 @@ static struct aead_request *macsec_alloc_req(struct
crypto_aead *tfm,
size = ALIGN(size, __alignof__(struct scatterlist));
sg_offset = size;
- size += sizeof(struct scatterlist) * (MAX_SKB_FRAGS + 1);
+ size += sizeof(struct scatterlist) * num_frags;
tmp = kmalloc(size, GFP_ATOMIC);
if (!tmp)
@@ -649,6 +650,7 @@ static struct sk_buff *macsec_encrypt(struct sk_buff *skb,
{
int ret;
struct scatterlist *sg;
+ struct sk_buff *trailer;
unsigned char *iv;
struct ethhdr *eth;
struct macsec_eth_header *hh;
@@ -723,7 +725,14 @@ static struct sk_buff *macsec_encrypt(struct sk_buff *skb,
return ERR_PTR(-EINVAL);
}
- req = macsec_alloc_req(tx_sa->key.tfm, &iv, &sg);
+ ret = skb_cow_data(skb, 0, &trailer);
+ if (unlikely(ret < 0)) {
+ macsec_txsa_put(tx_sa);
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
+
+ req = macsec_alloc_req(tx_sa->key.tfm, &iv, &sg, ret);
if (!req) {
macsec_txsa_put(tx_sa);
kfree_skb(skb);
@@ -917,6 +926,7 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
{
int ret;
struct scatterlist *sg;
+ struct sk_buff *trailer;
unsigned char *iv;
struct aead_request *req;
struct macsec_eth_header *hdr;
@@ -927,7 +937,12 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
if (!skb)
return ERR_PTR(-ENOMEM);
- req = macsec_alloc_req(rx_sa->key.tfm, &iv, &sg);
+ ret = skb_cow_data(skb, 0, &trailer);
+ if (unlikely(ret < 0)) {
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
+ req = macsec_alloc_req(rx_sa->key.tfm, &iv, &sg, ret);
if (!req) {
kfree_skb(skb);
return ERR_PTR(-ENOMEM);
@@ -2716,7 +2731,7 @@ static netdev_tx_t macsec_start_xmit(struct sk_buff *skb,
}
#define MACSEC_FEATURES \
- (NETIF_F_SG | NETIF_F_HIGHDMA)
+ (NETIF_F_SG | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST)
static struct lock_class_key macsec_netdev_addr_lock_key;
static int macsec_dev_init(struct net_device *dev)
--
2.12.2
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 05:12:00PM +0200, Peter Zijlstra wrote: > But I'll first try and figure out why I'm not having empty masks. Ah, so this is before all the degenerate stuff, so there's a bunch of redundant domains below that make it work -- and there always will be, unless FORCE_SD_OVERLAP. Now I wonder what triggered it.. let me put it back.
[PATCH 4.10 19/24] mac80211: fix MU-MIMO follow-MAC mode
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit 9e478066eae41211c92a8f63cc69aafc391bd6ab upstream.
There are two bugs in the follow-MAC code:
* it treats the radiotap header as the 802.11 header
(therefore it can't possibly work)
* it doesn't verify that the skb data it accesses is actually
present in the header, which is mitigated by the first point
Fix this by moving all of this out into a separate function.
This function copies the data it needs using skb_copy_bits()
to make sure it can be accessed if it's paged, and offsets
that by the possibly present vendor radiotap header.
This also makes all those conditions more readable.
Signed-off-by: Johannes Berg
Signed-off-by: Greg Kroah-Hartman
---
net/mac80211/rx.c | 65 +++---
1 file changed, 47 insertions(+), 18 deletions(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -208,6 +208,51 @@ ieee80211_rx_radiotap_hdrlen(struct ieee
return len;
}
+static void ieee80211_handle_mu_mimo_mon(struct ieee80211_sub_if_data *sdata,
+struct sk_buff *skb,
+int rtap_vendor_space)
+{
+ struct {
+ struct ieee80211_hdr_3addr hdr;
+ u8 category;
+ u8 action_code;
+ } __packed action;
+
+ if (!sdata)
+ return;
+
+ BUILD_BUG_ON(sizeof(action) != IEEE80211_MIN_ACTION_SIZE + 1);
+
+ if (skb->len < rtap_vendor_space + sizeof(action) +
+ VHT_MUMIMO_GROUPS_DATA_LEN)
+ return;
+
+ if (!is_valid_ether_addr(sdata->u.mntr.mu_follow_addr))
+ return;
+
+ skb_copy_bits(skb, rtap_vendor_space, &action, sizeof(action));
+
+ if (!ieee80211_is_action(action.hdr.frame_control))
+ return;
+
+ if (action.category != WLAN_CATEGORY_VHT)
+ return;
+
+ if (action.action_code != WLAN_VHT_ACTION_GROUPID_MGMT)
+ return;
+
+ if (!ether_addr_equal(action.hdr.addr1, sdata->u.mntr.mu_follow_addr))
+ return;
+
+ skb = skb_copy(skb, GFP_ATOMIC);
+ if (!skb)
+ return;
+
+ skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME;
+ skb_queue_tail(&sdata->skb_queue, skb);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+}
+
/*
* ieee80211_add_rx_radiotap_header - add radiotap header
*
@@ -515,7 +560,6 @@ ieee80211_rx_monitor(struct ieee80211_lo
struct net_device *prev_dev = NULL;
int present_fcs_len = 0;
unsigned int rtap_vendor_space = 0;
- struct ieee80211_mgmt *mgmt;
struct ieee80211_sub_if_data *monitor_sdata =
rcu_dereference(local->monitor_sdata);
@@ -553,6 +597,8 @@ ieee80211_rx_monitor(struct ieee80211_lo
return remove_monitor_info(local, origskb, rtap_vendor_space);
}
+ ieee80211_handle_mu_mimo_mon(monitor_sdata, origskb, rtap_vendor_space);
+
/* room for the radiotap header based on driver features */
rt_hdrlen = ieee80211_rx_radiotap_hdrlen(local, status, origskb);
needed_headroom = rt_hdrlen - rtap_vendor_space;
@@ -618,23 +664,6 @@ ieee80211_rx_monitor(struct ieee80211_lo
ieee80211_rx_stats(sdata->dev, skb->len);
}
- mgmt = (void *)skb->data;
- if (monitor_sdata &&
- skb->len >= IEEE80211_MIN_ACTION_SIZE + 1 +
VHT_MUMIMO_GROUPS_DATA_LEN &&
- ieee80211_is_action(mgmt->frame_control) &&
- mgmt->u.action.category == WLAN_CATEGORY_VHT &&
- mgmt->u.action.u.vht_group_notif.action_code ==
WLAN_VHT_ACTION_GROUPID_MGMT &&
- is_valid_ether_addr(monitor_sdata->u.mntr.mu_follow_addr) &&
- ether_addr_equal(mgmt->da, monitor_sdata->u.mntr.mu_follow_addr)) {
- struct sk_buff *mu_skb = skb_copy(skb, GFP_ATOMIC);
-
- if (mu_skb) {
- mu_skb->pkt_type = IEEE80211_SDATA_QUEUE_TYPE_FRAME;
- skb_queue_tail(&monitor_sdata->skb_queue, mu_skb);
- ieee80211_queue_work(&local->hw, &monitor_sdata->work);
- }
- }
-
if (prev_dev) {
skb->dev = prev_dev;
netif_receive_skb(skb);
[PATCH 4.10 16/24] ubifs: Fix RENAME_WHITEOUT support
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Felix Fietkau
commit c3d9fda688742c06e89aa1f0f8fd943fc11468cb upstream.
Remove faulty leftover check in do_rename(), apparently introduced in a
merge that combined whiteout support changes with commit f03b8ad8d386
("fs: support RENAME_NOREPLACE for local filesystems")
Fixes: f03b8ad8d386 ("fs: support RENAME_NOREPLACE for local filesystems")
Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT")
Signed-off-by: Felix Fietkau
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
fs/ubifs/dir.c |3 ---
1 file changed, 3 deletions(-)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -1316,9 +1316,6 @@ static int do_rename(struct inode *old_d
unsigned int uninitialized_var(saved_nlink);
struct fscrypt_name old_nm, new_nm;
- if (flags & ~RENAME_NOREPLACE)
- return -EINVAL;
-
/*
* Budget request settings: deletion direntry, new direntry, removing
* the old inode, and changing old and new parent directory inodes.
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 11:33:51AM -0300, Lauro Venancio wrote: > On 04/25/2017 09:17 AM, Peter Zijlstra wrote: > > With the fact that sched_group_cpus(sd->groups) == > > sched_domain_span(sibling->child) (if child exists) established in the > > previous patches, could we not simplify this like the below? > We can. We just need to better handle the case when there is no child or > we will have empty masks. > We have to replicate the build_group_from_child_sched_domain() behavior: > > if (sd->child) > cpumask_copy(sg_span, sched_domain_span(sd->child)); > else > cpumask_copy(sg_span, sched_domain_span(sd)); > > > So we need something like: > > > if (sibling->child) > gsd = sibling->child; > else > gsd = sibling; > > if (!cpumask_equal(sg_span, sched_domain_span(gsd))) > > continue; Right, ran into that already. My truncated topologies (single cpu per node) insta triggered it. But somehow removing the WARN was sufficient and the mask didn't end up empty. This is the ring topo: [0.086772] CPU0 attaching sched-domain: [0.087005] domain 0: span 0-1,3 level NUMA [0.088002] groups: 0 (mask: 0), 1, 3 [0.089002] domain 1: span 0-3 level NUMA [0.090002]groups: 0-1,3 (mask: 0) (cpu_capacity: 3072), 1-3 (cpu_capacity: 3072) [0.091005] CPU1 attaching sched-domain: [0.092003] domain 0: span 0-2 level NUMA [0.093002] groups: 1 (mask: 1), 2, 0 [0.094002] domain 1: span 0-3 level NUMA [0.095002]groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072) [0.096005] CPU2 attaching sched-domain: [0.097002] domain 0: span 1-3 level NUMA [0.098002] groups: 2 (mask: 2), 3, 1 [0.099002] domain 1: span 0-3 level NUMA [0.12]groups: 1-3 (mask: 2) (cpu_capacity: 3072), 0-1,3 (cpu_capacity: 3072) [0.101004] CPU3 attaching sched-domain: [0.102002] domain 0: span 0,2-3 level NUMA [0.103002] groups: 3 (mask: 3), 0, 2 [0.104002] domain 1: span 0-3 level NUMA [0.105002]groups: 0,2-3 (mask: 3) (cpu_capacity: 3072), 0-2 (cpu_capacity: 3072) See how the domain-0 mask isn't empty. That said, when !child, ->groups ends up being a single cpu. So I was thinking: struct cpumask *i_span; if (sibling->child) i_span = sched_domain_span(sibling->child); else i_span = cpumask_of(i); if (!cpumask_equal(sg_span, i_span)) continue; But I'll first try and figure out why I'm not having empty masks.
[PATCH 4.10 18/24] mac80211: reject ToDS broadcast data frames
4.10-stable review patch. If anyone has any objections, please let me know. -- From: Johannes Berg commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream. AP/AP_VLAN modes don't accept any real 802.11 multicast data frames, but since they do need to accept broadcast management frames the same is currently permitted for data frames. This opens a security problem because such frames would be decrypted with the GTK, and could even contain unicast L3 frames. Since the spec says that ToDS frames must always have the BSSID as the RA (addr1), reject any other data frames. The problem was originally reported in "Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys" at usenix https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef and brought to my attention by Jouni. Reported-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman -- --- net/mac80211/rx.c | 21 + 1 file changed, 21 insertions(+) --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3614,6 +3614,27 @@ static bool ieee80211_accept_frame(struc !ether_addr_equal(bssid, hdr->addr1)) return false; } + + /* +* 802.11-2016 Table 9-26 says that for data frames, A1 must be +* the BSSID - we've checked that already but may have accepted +* the wildcard (ff:ff:ff:ff:ff:ff). +* +* It also says: +* The BSSID of the Data frame is determined as follows: +* a) If the STA is contained within an AP or is associated +* with an AP, the BSSID is the address currently in use +* by the STA contained in the AP. +* +* So we should not accept data frames with an address that's +* multicast. +* +* Accepting it also opens a security problem because stations +* could encrypt it with the GTK and inject traffic that way. +*/ + if (ieee80211_is_data(hdr->frame_control) && multicast) + return false; + return true; case NL80211_IFTYPE_WDS: if (bssid || !ieee80211_is_data(hdr->frame_control))
[PATCH 4.10 20/24] x86/mce: Make the MCE notifier a blocking one
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Vishal Verma
commit 0dc9c639e6553e39c13b2c0d54c8a1b098cb95e2 upstream.
The NFIT MCE handler callback (for handling media errors on NVDIMMs)
takes a mutex to add the location of a memory error to a list. But since
the notifier call chain for machine checks (x86_mce_decoder_chain) is
atomic, we get a lockdep splat like:
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:620
in_atomic(): 1, irqs_disabled(): 0, pid: 4, name: kworker/0:0
[..]
Call Trace:
dump_stack
___might_sleep
__might_sleep
mutex_lock_nested
? __lock_acquire
nfit_handle_mce
notifier_call_chain
atomic_notifier_call_chain
? atomic_notifier_call_chain
mce_gen_pool_process
Convert the notifier to a blocking one which gets to run only in process
context.
Boris: remove the notifier call in atomic context in print_mce(). For
now, let's print the MCE on the atomic path so that we can make sure
they go out and get logged at least.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Ross Zwisler
Signed-off-by: Vishal Verma
Acked-by: Tony Luck
Cc: Dan Williams
Cc: linux-edac
Cc: x86-ml
Link: http://lkml.kernel.org/r/20170411224457.24777-1-vishal.l.ve...@intel.com
Signed-off-by: Borislav Petkov
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/mcheck/mce-genpool.c |2 +-
arch/x86/kernel/cpu/mcheck/mce-internal.h |2 +-
arch/x86/kernel/cpu/mcheck/mce.c | 17 +++--
3 files changed, 5 insertions(+), 16 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce-genpool.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
@@ -85,7 +85,7 @@ void mce_gen_pool_process(void)
head = llist_reverse_order(head);
llist_for_each_entry_safe(node, tmp, head, llnode) {
mce = &node->mce;
- atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
+ blocking_notifier_call_chain(&x86_mce_decoder_chain, 0, mce);
gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
}
}
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -13,7 +13,7 @@ enum severity_level {
MCE_PANIC_SEVERITY,
};
-extern struct atomic_notifier_head x86_mce_decoder_chain;
+extern struct blocking_notifier_head x86_mce_decoder_chain;
#define ATTR_LEN 16
#define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -123,7 +123,7 @@ static void (*quirk_no_way_out)(int bank
* CPU/chipset specific EDAC code can register a notifier call here to print
* MCE errors in a human-readable form.
*/
-ATOMIC_NOTIFIER_HEAD(x86_mce_decoder_chain);
+BLOCKING_NOTIFIER_HEAD(x86_mce_decoder_chain);
/* Do initial initialization of a struct mce */
void mce_setup(struct mce *m)
@@ -223,7 +223,7 @@ void mce_register_decode_chain(struct no
if (nb != &mce_srao_nb && nb->priority == INT_MAX)
nb->priority -= 1;
- atomic_notifier_chain_register(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_register(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_register_decode_chain);
@@ -231,7 +231,7 @@ void mce_unregister_decode_chain(struct
{
atomic_dec(&num_notifiers);
- atomic_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
+ blocking_notifier_chain_unregister(&x86_mce_decoder_chain, nb);
}
EXPORT_SYMBOL_GPL(mce_unregister_decode_chain);
@@ -324,18 +324,7 @@ static void __print_mce(struct mce *m)
static void print_mce(struct mce *m)
{
- int ret = 0;
-
__print_mce(m);
-
- /*
-* Print out human-readable details about the MCE error,
-* (if the CPU has an implementation for that)
-*/
- ret = atomic_notifier_call_chain(&x86_mce_decoder_chain, 0, m);
- if (ret == NOTIFY_STOP)
- return;
-
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog --ascii'\n");
}
[PATCH 4.10 05/24] HID: wacom: Treat HID_DG_TOOLSERIALNUMBER as unsigned
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Jason Gerecke
commit 286f3f478796fb4f9e003e9f7d649f3c33f08d2f upstream.
Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
to an unsigned type, sign-extension rules can cause the value of
wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
set if the highest bit of "value" was set.
This can cause problems for Tablet PC devices which use AES sensors and the
xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
serial number of '0' while the pen is entering or leaving proximity. The
xf86-input-wacom driver ignores events with a serial number of '0' since it
cannot match them up to an in-use tool. To ensure the xf86-input-wacom driver
does not ignore the final out-of-proximity event, the kernel does not send
MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
sent to userspace, causing xf86-input-wacom to ignore the event. If the event
was the final out-of-prox event, then xf86-input-wacom may remain in a state
where it believes the pen is in proximity and refuses to allow other devices
under its control (e.g. the touchscreen) to move the cursor.
It should be noted that EMR devices and devices which use both the
HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
be immune to this issue. It appears only AES devices are affected.
Fixes: f85c9dc678a ("HID: wacom: generic: Support tool ID and additional tool
types")
Signed-off-by: Jason Gerecke
Acked-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/wacom_wac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1798,7 +1798,7 @@ static void wacom_wac_pen_event(struct h
return;
case HID_DG_TOOLSERIALNUMBER:
wacom_wac->serial[0] = (wacom_wac->serial[0] & ~0xULL);
- wacom_wac->serial[0] |= value;
+ wacom_wac->serial[0] |= (__u32)value;
return;
case WACOM_HID_WD_SENSE:
wacom_wac->hid_data.sense_state = value;
[PATCH 4.10 22/24] powerpc/kprobe: Fix oops when kprobed on stdu instruction
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Ravi Bangoria
commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream.
If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
OOPS:
Bad kernel stack pointer cd93c840 at c0009868
Oops: Bad kernel stack pointer, sig: 6 [#1]
...
GPR00: c01fcd93cb30 cd93c840 c15c5e00 cd93c840
...
NIP [c0009868] resume_kernel+0x2c/0x58
LR [c0006208] program_check_common+0x108/0x180
On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
not emulate actual store in emulate_step() because it may corrupt the exception
frame. So the kernel does the actual store operation in exception return code
i.e. resume_kernel().
resume_kernel() loads the saved stack pointer from memory using lwz, which only
loads the low 32-bits of the address, causing the kernel crash.
Fix this by loading the 64-bit value instead.
Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of
emulate_step()")
Signed-off-by: Ravi Bangoria
Reviewed-by: Naveen N. Rao
Reviewed-by: Ananth N Mavinakayanahalli
[mpe: Change log massage, add stable tag]
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/entry_64.S |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -689,7 +689,7 @@ resume_kernel:
addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */
- lwz r3,GPR1(r1)
+ ld r3,GPR1(r1)
subir3,r3,INT_FRAME_SIZE/* dst: Allocate a trampoline exception
frame */
mr r4,r1 /* src: current exception frame */
mr r1,r3 /* Reroute the trampoline frame to r1 */
@@ -703,8 +703,8 @@ resume_kernel:
addir6,r6,8
bdnz2b
- /* Do real store operation to complete stwu */
- lwz r5,GPR1(r1)
+ /* Do real store operation to complete stdu */
+ ld r5,GPR1(r1)
std r8,0(r5)
/* Clear _TIF_EMULATE_STACK_STORE flag */
[PATCH 4.10 23/24] x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Yazen Ghannam
commit 29f72ce3e4d18066ec75c79c857bee0618a3504b upstream.
MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
However, MCA bank 3 is defined on Fam17h systems and can be accessed
using legacy MSRs. Without a name we get a stack trace on Fam17h systems
when trying to register sysfs files for bank 3 on kernels that don't
recognize Scalable MCA.
Call MCA bank 3 "decode_unit" since this is what it represents on
Fam17h. This will allow kernels without SMCA support to see this bank on
Fam17h+ and prevent the stack trace. This will not affect older systems
since this bank is reserved on them, i.e. it'll be ignored.
Tested on AMD Fam15h and Fam17h systems.
WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
kobject: (88085bb256c0): attempted to be registered with empty name!
...
Call Trace:
kobject_add_internal
kobject_add
kobject_create_and_add
threshold_create_device
threshold_init_device
Signed-off-by: Yazen Ghannam
Signed-off-by: Borislav Petkov
Link:
http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-yazen.ghan...@amd.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -60,7 +60,7 @@ static const char * const th_names[] = {
"load_store",
"insn_fetch",
"combined_unit",
- "",
+ "decode_unit",
"northbridge",
"execution_unit",
};
[PATCH 4.10 09/24] CIFS: remove bad_network_name flag
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Germano Percossi
commit a0918f1ce6a43ac980b42b300ec443c154970979 upstream.
STATUS_BAD_NETWORK_NAME can be received during node failover,
causing the flag to be set and making the reconnect thread
always unsuccessful, thereafter.
Once the only place where it is set is removed, the remaining
bits are rendered moot.
Removing it does not prevent "mount" from failing when a non
existent share is passed.
What happens when the share really ceases to exist while the
share is mounted is undefined now as much as it was before.
Signed-off-by: Germano Percossi
Reviewed-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/cifsglob.h |1 -
fs/cifs/smb2pdu.c |5 -
2 files changed, 6 deletions(-)
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -933,7 +933,6 @@ struct cifs_tcon {
bool use_persistent:1; /* use persistent instead of durable handles */
#ifdef CONFIG_CIFS_SMB2
bool print:1; /* set if connection to printer share */
- bool bad_network_name:1; /* set if ret status STATUS_BAD_NETWORK_NAME */
__le32 capabilities;
__u32 share_flags;
__u32 maximal_access;
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1084,9 +1084,6 @@ SMB2_tcon(const unsigned int xid, struct
else
return -EIO;
- if (tcon && tcon->bad_network_name)
- return -ENOENT;
-
if ((tcon && tcon->seal) &&
((ses->server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION) == 0)) {
cifs_dbg(VFS, "encryption requested but no server support");
@@ -1188,8 +1185,6 @@ tcon_exit:
tcon_error_exit:
if (rsp->hdr.Status == STATUS_BAD_NETWORK_NAME) {
cifs_dbg(VFS, "BAD_NETWORK_NAME: %s\n", tree);
- if (tcon)
- tcon->bad_network_name = true;
}
goto tcon_exit;
}
[PATCH 4.10 10/24] mmc: dw_mmc: silent verbose log when calling from PM context
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Lin
commit ce69e2fea093b7fa3991c87849c4955cd47796c9 upstream.
When deploying runtime PM, it's quite verbose to print the
log of ios setting. Also it's useless to print it from system
PM as it should be the same with booting time. We also have
sysfs to get all these information from ios attribute, so let's
skip this print from PM context.
Signed-off-by: Shawn Lin
Signed-off-by: Jaehoon Chung
Signed-off-by: Ulf Hansson
Cc: Alexander Kochetkov
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/dw_mmc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1179,11 +1179,13 @@ static void dw_mci_setup_bus(struct dw_m
if ((clock != slot->__clk_old &&
!test_bit(DW_MMC_CARD_NEEDS_POLL, &slot->flags)) ||
force_clkinit) {
- dev_info(&slot->mmc->class_dev,
-"Bus speed (slot %d) = %dHz (slot req %dHz,
actual %dHZ div = %d)\n",
-slot->id, host->bus_hz, clock,
-div ? ((host->bus_hz / div) >> 1) :
-host->bus_hz, div);
+ /* Silent the verbose log if calling from PM context */
+ if (!force_clkinit)
+ dev_info(&slot->mmc->class_dev,
+"Bus speed (slot %d) = %dHz (slot req
%dHz, actual %dHZ div = %d)\n",
+slot->id, host->bus_hz, clock,
+div ? ((host->bus_hz / div) >> 1) :
+host->bus_hz, div);
/*
* If card is polling, display the message only
Re: [PATCH v4 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
John this isn't how it works. When you submit new versions of a patch that are part of a patch series, you must resubmit the entire series not just the patches which are changing. Thanks.
Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec
2017-04-25, 17:08:28 +0200, Jason A. Donenfeld wrote: > Hi Sabrina, > > On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca wrote: > > Ugh, good catch :/ > > > > AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST > > doesn't get tested in paths that can lead to triggering this. > > You're right. This fixes the xmit() path, but not the receive path, > which appears to take skbs directly from the upper device. > > > I'll post a patch to allocate a properly-sized sg array. > > I just posted this series, which should fix things in a robust way: > > https://patchwork.ozlabs.org/patch/754861/ Yes, that prevents the overflow, but now you're just dropping packets. I'll review that later, let's fix the overflow without breaking connectivity for now. -- Sabrina
[PATCH 4.10 08/24] cifs: Do not send echoes before Negotiate is complete
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Sachin Prabhu
commit 62a6cfddcc0a5313e7da3e8311ba16226fe0ac10 upstream.
commit 4fcd1813e640 ("Fix reconnect to not defer smb3 session reconnect
long after socket reconnect") added support for Negotiate requests to
be initiated by echo calls.
To avoid delays in calling echo after a reconnect, I added the patch
introduced by the commit b8c600120fc8 ("Call echo service immediately
after socket reconnect").
This has however caused a regression with cifs shares which do not have
support for echo calls to trigger Negotiate requests. On connections
which need to call Negotiation, the echo calls trigger an error which
triggers a reconnect which in turn triggers another echo call. This
results in a loop which is only broken when an operation is performed on
the cifs share. For an idle share, it can DOS a server.
The patch uses the smb_operation can_echo() for cifs so that it is
called only if connection has been already been setup.
kernel bz: 194531
Signed-off-by: Sachin Prabhu
Tested-by: Jonathan Liu
Acked-by: Pavel Shilovsky
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/smb1ops.c | 10 ++
1 file changed, 10 insertions(+)
--- a/fs/cifs/smb1ops.c
+++ b/fs/cifs/smb1ops.c
@@ -1015,6 +1015,15 @@ cifs_dir_needs_close(struct cifsFileInfo
return !cfile->srch_inf.endOfSearch && !cfile->invalidHandle;
}
+static bool
+cifs_can_echo(struct TCP_Server_Info *server)
+{
+ if (server->tcpStatus == CifsGood)
+ return true;
+
+ return false;
+}
+
struct smb_version_operations smb1_operations = {
.send_cancel = send_nt_cancel,
.compare_fids = cifs_compare_fids,
@@ -1049,6 +1058,7 @@ struct smb_version_operations smb1_opera
.get_dfs_refer = CIFSGetDFSRefer,
.qfs_tcon = cifs_qfs_tcon,
.is_path_accessible = cifs_is_path_accessible,
+ .can_echo = cifs_can_echo,
.query_path_info = cifs_query_path_info,
.query_file_info = cifs_query_file_info,
.get_srv_inum = cifs_get_srv_inum,
[PATCH 4.9 09/21] s390/mm: fix CMMA vs KSM vs others
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Borntraeger
commit a8f60d1fadf7b8b54449fcc9d6b15248917478ba upstream.
On heavy paging with KSM I see guest data corruption. Turns out that
KSM will add pages to its tree, where the mapping return true for
pte_unused (or might become as such later). KSM will unmap such pages
and reinstantiate with different attributes (e.g. write protected or
special, e.g. in replace_page or write_protect_page)). This uncovered
a bug in our pagetable handling: We must remove the unused flag as
soon as an entry becomes present again.
Signed-of-by: Christian Borntraeger
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/pgtable.h |2 ++
1 file changed, 2 insertions(+)
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1029,6 +1029,8 @@ int get_guest_storage_key(struct mm_stru
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t entry)
{
+ if (pte_present(entry))
+ pte_val(entry) &= ~_PAGE_UNUSED;
if (mm_has_pgste(mm))
ptep_set_pte_at(mm, addr, ptep, entry);
else
[PATCH 0/3] HID-Wacom: Fine-tuning for seven function implementations
From: Markus Elfring Date: Tue, 25 Apr 2017 17:07:07 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Use devm_kcalloc() in two functions Improve size determinations in three functions Delete two unnecessary return statements drivers/hid/wacom_sys.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) -- 2.12.2
[PATCH 4.10 01/24] KEYS: Disallow keyrings beginning with . to be joined as session keyrings
4.10-stable review patch. If anyone has any objections, please let me know. -- From: David Howells commit ee8f844e3c5a73b999edf733df1c529d6503ec2f upstream. This fixes CVE-2016-9604. Keyrings whose name begin with a '.' are special internal keyrings and so userspace isn't allowed to create keyrings by this name to prevent shadowing. However, the patch that added the guard didn't fix KEYCTL_JOIN_SESSION_KEYRING. Not only can that create dot-named keyrings, it can also subscribe to them as a session keyring if they grant SEARCH permission to the user. This, for example, allows a root process to set .builtin_trusted_keys as its session keyring, at which point it has full access because now the possessor permissions are added. This permits root to add extra public keys, thereby bypassing module verification. This also affects kexec and IMA. This can be tested by (as root): keyctl session .builtin_trusted_keys keyctl add user a a @s keyctl list @s which on my test box gives me: 2 keys in keyring: 180010936: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: ae3d4a31b82daa8e1a75b49dc2bba949fd992a05 801382539: --alswrv 0 0 user: a Fix this by rejecting names beginning with a '.' in the keyctl. Signed-off-by: David Howells Acked-by: Mimi Zohar cc: linux-ima-de...@lists.sourceforge.net Signed-off-by: Greg Kroah-Hartman --- security/keys/keyctl.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -271,7 +271,8 @@ error: * Create and join an anonymous session keyring or join a named session * keyring, creating it if necessary. A named session keyring must have Search * permission for it to be joined. Session keyrings without this permit will - * be skipped over. + * be skipped over. It is not permitted for userspace to create or join + * keyrings whose name begin with a dot. * * If successful, the ID of the joined session keyring will be returned. */ @@ -288,12 +289,16 @@ long keyctl_join_session_keyring(const c ret = PTR_ERR(name); goto error; } + + ret = -EPERM; + if (name[0] == '.') + goto error_name; } /* join the session */ ret = join_session_keyring(name); +error_name: kfree(name); - error: return ret; }
[PATCH 4.9 00/21] 4.9.25-stable review
This is the start of the stable review cycle for the 4.9.25 release. There are 21 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Apr 27 15:08:14 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.25-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.9.25-rc1 Dan Williams device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation Vishal Verma x86/mce: Make the MCE notifier a blocking one Yazen Ghannam x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs Ravi Bangoria powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction Sebastian Siewior ubi/upd: Always flush after prepared for an update Johannes Berg mac80211: fix MU-MIMO follow-MAC mode Johannes Berg mac80211: reject ToDS broadcast data frames Richard Weinberger ubifs: Fix O_TMPFILE corner case in ubifs_link() Felix Fietkau ubifs: Fix RENAME_WHITEOUT support Haibo Chen mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Arnd Bergmann ACPI / power: Avoid maybe-uninitialized warning Thorsten Leemhuis Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Christian Borntraeger s390/mm: fix CMMA vs KSM vs others Germano Percossi CIFS: remove bad_network_name flag Sachin Prabhu cifs: Do not send echoes before Negotiate is complete Rabin Vincent mm: prevent NR_ISOLATE_* stats from going negative Steven Rostedt (VMware) ring-buffer: Have ring_buffer_iter_empty() return true when empty Steven Rostedt (VMware) tracing: Allocate the snapshot buffer before enabling probe Eric Biggers KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings David Howells KEYS: Change the name of the dead type to ".dead" to prevent user access David Howells KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings - Diffstat: Makefile | 4 +- arch/powerpc/kernel/entry_64.S| 6 +-- arch/s390/include/asm/pgtable.h | 2 + arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 16 ++ arch/x86/kernel/cpu/mcheck/mce_amd.c | 2 +- drivers/acpi/power.c | 1 + drivers/dax/Kconfig | 1 + drivers/dax/dax.c | 13 ++--- drivers/input/mouse/elantech.c| 8 +++ drivers/mmc/host/sdhci-esdhc-imx.c| 1 + drivers/mtd/ubi/upd.c | 8 +-- fs/cifs/cifsglob.h| 1 - fs/cifs/smb1ops.c | 10 fs/cifs/smb2pdu.c | 5 -- fs/ubifs/dir.c| 10 ++-- kernel/trace/ring_buffer.c| 16 +- kernel/trace/trace.c | 8 +-- mm/migrate.c | 2 +- net/mac80211/rx.c | 86 --- security/keys/gc.c| 2 +- security/keys/keyctl.c| 20 +++ security/keys/process_keys.c | 44 ++-- 24 files changed, 179 insertions(+), 91 deletions(-)
Re: [PATCH v2] sched/cfs: make util/load_avg more stable
On 25 April 2017 at 16:53, Dietmar Eggemann wrote:
> On 25/04/17 13:40, Vincent Guittot wrote:
>> On 25 April 2017 at 13:05, Dietmar Eggemann wrote:
>>> On 19/04/17 17:54, Vincent Guittot wrote:
In the current implementation of load/util_avg, we assume that the ongoing
time segment has fully elapsed, and util/load_sum is divided by
LOAD_AVG_MAX,
even if part of the time segment still remains to run. As a consequence,
this
remaining part is considered as idle time and generates unexpected
variations
of util_avg of a busy CPU in the range ]1002..1024[ whereas util_avg should
>>>
>>> Why do you use the square brackets the other way around? Just curious.
>>
>> This refers to the very beginning and very end of time segment formulas
>> below.
>> That being said, 1024 is not reachable because at very end we have :
>> 1024*MAX_LOAD_AVG*y+1024*1023 = 1023,9997
>>
>> 1002 is not reachable because at very beg we have
>> 1024*MAX_LOAD_AVG*y+ 1024*0 = 1002,0577
>>
>> But we are working with integer so [1002..1024[ is probably more correct
>
> OK, this is with y = 32nd-rt(0.5) exactly, understood.
>
> I assume you mean LOAD_AVG_MAX instead of MAX_LOAD_AVG.
correct
>
>>> 1002 stands for 1024*y^1 w/ y = 4008/4096 or y^32 = 0.5, right ? Might
>>> be worth mentioning.
>>>
stay at 1023.
In order to keep the metric stable, we should not consider the ongoing time
segment when computing load/util_avg but only the segments that have
already
fully elapsed. Bu to not consider the current time segment adds unwanted
latency in the load/util_avg responsivness especially when the time is
scaled
instead of the contribution. Instead of waiting for the current time
segment
to have fully elapsed before accounting it in load/util_avg, we can already
account the elapsed part but change the range used to compute load/util_avg
accordingly.
At the very beginning of a new time segment, the past segments have been
decayed and the max value is MAX_LOAD_AVG*y. At the very end of the current
time segment, the max value becomes 1024(us) + MAX_LOAD_AVG*y which is
equal
to MAX_LOAD_AVG. In fact, the max value is
sa->period_contrib + MAX_LOAD_AVG*y at any time in the time segment.
>
> s/MAX_LOAD_AVG/LOAD_AVG_MAX
ditto
>
Taking advantage of the fact that MAX_LOAD_AVG*y == MAX_LOAD_AVG-1024, the
range becomes [0..MAX_LOAD_AVG-1024+sa->period_contrib].
As the elapsed part is already accounted in load/util_sum, we update the
max
value according to the current position in the time segment instead of
removing its contribution.
>>>
>>> Removing its contribution stands for '- 1024' of 'LOAD_AVG_MAX - 1024'
>>> which was added in patch 1/2?
>>
>> removing its contribution refers to "- sa->period_contrib * weight"
>> and "- (running * sa->period_contrib << SCHED_CAPACITY_SHIFT))" in
>> patch 1/2 of the previous version
>
> Yup, makes sense, so the '-1024' is the influence of the current 'time
> segment' (n = 0) then.
Yes
>
> IMHO, the removing of contribution in patch 1/2 wouldn't take freq and
> cpu scaling of contribution (which is still in accumulate_sum()) into
> consideration.
Yes you're right but as everything has been put in 1 single patch in
v2, it doesn't make any difference now
>
Suggested-by: Peter Zijlstra
Signed-off-by: Vincent Guittot
---
Fold both patches in one
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3f83a35..c3b8f0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3017,12 +3017,12 @@ ___update_load_avg(u64 now, int cpu, struct
sched_avg *sa,
/*
* Step 2: update *_avg.
*/
- sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX);
+ sa->load_avg = div_u64(sa->load_sum, LOAD_AVG_MAX - 1024 +
sa->period_contrib);
if (cfs_rq) {
cfs_rq->runnable_load_avg =
- div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX);
+ div_u64(cfs_rq->runnable_load_sum, LOAD_AVG_MAX -
1024 + sa->period_contrib);
}
- sa->util_avg = sa->util_sum / LOAD_AVG_MAX;
+ sa->util_avg = sa->util_sum / (LOAD_AVG_MAX - 1024 +
sa->period_contrib);
return 1;
}
[PATCH 4.10 21/24] ubi/upd: Always flush after prepared for an update
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Siewior
commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream.
In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I
managed to trigger and fix a similar bug. Now here is another version of
which I assumed it wouldn't matter back then but it turns out UBI has a
check for it and will error out like this:
|ubi0 warning: validate_vid_hdr: inconsistent used_ebs
|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592
All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a
powercut in the middle of the operation.
ubi_start_update() sets the update-marker and puts all EBs on the erase
list. After that userland can proceed to write new data while the old EB
aren't erased completely. A powercut at this point is usually not that
much of a tragedy. UBI won't give read access to the static volume
because it has the update marker. It will most likely set the corrupted
flag because it misses some EBs.
So we are all good. Unless the size of the image that has been written
differs from the old image in the magnitude of at least one EB. In that
case UBI will find two different values for `used_ebs' and refuse to
attach the image with the error message mentioned above.
So in order not to get in the situation, the patch will ensure that we
wait until everything is removed before it tries to write any data.
The alternative would be to detect such a case and remove all EBs at the
attached time after we processed the volume-table and see the
update-marker set. The patch looks bigger and I doubt it is worth it
since usually the write() will wait from time to time for a new EB since
usually there not that many spare EB that can be used.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
drivers/mtd/ubi/upd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/mtd/ubi/upd.c
+++ b/drivers/mtd/ubi/upd.c
@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device *
return err;
}
- if (bytes == 0) {
- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
- if (err)
- return err;
+ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL);
+ if (err)
+ return err;
+ if (bytes == 0) {
err = clear_update_marker(ubi, vol, 0);
if (err)
return err;
[PATCH 4.10 00/24] 4.10.13-stable review
This is the start of the stable review cycle for the 4.10.13 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Apr 27 15:08:24 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.10.13-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.10.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.10.13-rc1 Dan Williams device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation Yazen Ghannam x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs Ravi Bangoria powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction Sebastian Siewior ubi/upd: Always flush after prepared for an update Vishal Verma x86/mce: Make the MCE notifier a blocking one Johannes Berg mac80211: fix MU-MIMO follow-MAC mode Johannes Berg mac80211: reject ToDS broadcast data frames Richard Weinberger ubifs: Fix O_TMPFILE corner case in ubifs_link() Felix Fietkau ubifs: Fix RENAME_WHITEOUT support Haibo Chen mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Douglas Anderson mmc: dw_mmc: Don't allow Runtime PM for SDIO cards Arnd Bergmann ACPI / power: Avoid maybe-uninitialized warning Thorsten Leemhuis Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Christian Borntraeger s390/mm: fix CMMA vs KSM vs others Shawn Lin mmc: dw_mmc: silent verbose log when calling from PM context Germano Percossi CIFS: remove bad_network_name flag Sachin Prabhu cifs: Do not send echoes before Negotiate is complete Rabin Vincent mm: prevent NR_ISOLATE_* stats from going negative Steven Rostedt (VMware) ring-buffer: Have ring_buffer_iter_empty() return true when empty Jason Gerecke HID: wacom: Treat HID_DG_TOOLSERIALNUMBER as unsigned Steven Rostedt (VMware) tracing: Allocate the snapshot buffer before enabling probe Eric Biggers KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings David Howells KEYS: Change the name of the dead type to ".dead" to prevent user access David Howells KEYS: Disallow keyrings beginning with '.' to be joined as session keyrings - Diffstat: Makefile | 4 +- arch/powerpc/kernel/entry_64.S| 6 +-- arch/s390/include/asm/pgtable.h | 2 + arch/x86/kernel/cpu/mcheck/mce-genpool.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 +- arch/x86/kernel/cpu/mcheck/mce.c | 17 ++ arch/x86/kernel/cpu/mcheck/mce_amd.c | 2 +- drivers/acpi/power.c | 1 + drivers/dax/Kconfig | 1 + drivers/dax/dax.c | 13 ++--- drivers/hid/wacom_wac.c | 2 +- drivers/input/mouse/elantech.c| 8 +++ drivers/mmc/host/dw_mmc.c | 23 ++--- drivers/mmc/host/sdhci-esdhc-imx.c| 1 + drivers/mtd/ubi/upd.c | 8 +-- fs/cifs/cifsglob.h| 1 - fs/cifs/smb1ops.c | 10 fs/cifs/smb2pdu.c | 5 -- fs/ubifs/dir.c| 10 ++-- kernel/trace/ring_buffer.c| 16 +- kernel/trace/trace.c | 8 +-- mm/migrate.c | 2 +- net/mac80211/rx.c | 86 --- security/keys/gc.c| 2 +- security/keys/keyctl.c| 20 +++ security/keys/process_keys.c | 44 ++-- 26 files changed, 196 insertions(+), 100 deletions(-)
Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
On Tue, Apr 25, 2017 at 5:40 AM, Sergei Shtylyov
wrote:
> Hello.
>
> On 4/25/2017 12:50 AM, Eric Anholt wrote:
>
>> Cygnus has a single amac controller connected to the B53 switch with 2
>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>> the external ethernet jacks.
>
>
>My spell checker trips on "amac" and "ethernet" -- perhaps they need
> capitalization?
>
>> Signed-off-by: Eric Anholt
>> ---
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 60
>> ++
>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +
>> 2 files changed, 68 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 009f1346b817..318899df9972 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -142,6 +142,56 @@
>> interrupts = <0>;
>> };
>>
>> + mdio: mdio@18002000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18002000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>> +
>> + gphy0: eth-gphy@0 {
>
>
>The node anmes must be generic, the DT spec has standardized
> "ethernet-phy" name for this case.
>
>> + reg = <0>;
>> + max-speed = <1000>;
>> + };
>> +
>> + gphy1: eth-gphy@1 {
>> + reg = <1>;
>> + max-speed = <1000>;
>> + };
>> + };
>
> [...]
>>
>> @@ -295,6 +345,16 @@
>> status = "disabled";
>> };
>>
>> + eth0: enet@18042000 {
>> + compatible = "brcm,amac";
>> + reg = <0x18042000 0x1000>,
>> + <0x1811 0x1000>;
>> + reg-names = "amac_base", "idm_base";
>
>
>I don't think "_base" suffixes are necessary here.
100% necessary, per the driver. See
drivers/net/ethernet/broadcom/bgmac-platform.c
>
> [...]
>
> MBR, Sergei
>
Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver
On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote:
> > Hi,
> > On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote:
> > > On Fri, 2017-04-21 at 14:29 +, Eugeniy Paltsev wrote:
> > > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:
> > > > > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:
> > > > > > This patch adds support for the DW AXI DMAC controller.
> > > > > > +static inline void
> > > > > > +axi_dma_iowrite32(struct axi_dma_chip *chip, u32 reg, u32
> > > > > > val)
> > > > > > +{
> > > > > > + iowrite32(val, chip->regs + reg);
> > > > >
> > > > > Are you going to use IO ports for this IP? I don't think so.
> > > > > Wouldn't be better to call readl()/writel() instead?
> > > >
> > > > As I understand, it's better to use ioread/iowrite as more
> > > > universal
> > > > IO
> > > > access way. Am I wrong?
> > >
> > > As I said above the ioreadX/iowriteX makes only sense when your
> > > IP
> > > would be accessed via IO region or MMIO. I'm pretty sure IO is
> > > not
> > > the case at all for this IP.
> >
> > MMIO? This IP works exactly via memory-mapped I/O.
>
> Yes, and why do you need to check this on each IO read/write?
> Please, switch to plain readX()/writeX() instead.
Ok, I'll switch to readX()/writeX().
> > > > > > + val = axi_chan_ioread32(chan,
> > > > > > CH_INTSTATUS_ENA);
> > > > > > + val &= ~irq_mask;
> > > > > > + axi_chan_iowrite32(chan, CH_INTSTATUS_ENA,
> > > > > > val);
> > > > > > + }
> > > > > > +
> > > > > > + return min_t(size_t, __ffs(sdl), max_width);
> > > > > > +}
> > > > > > +static void axi_desc_put(struct axi_dma_desc *desc)
> > > > > > +{
> > > > > > + struct axi_dma_chan *chan = desc->chan;
> > > > > > + struct dw_axi_dma *dw = chan->chip->dw;
> > > > > > + struct axi_dma_desc *child, *_next;
> > > > > > + unsigned int descs_put = 0;
> > > > > > + list_for_each_entry_safe(child, _next, &desc-
> > > > > > > xfer_list,
> > > > > >
> > > > > > xfer_list) {
> > > > >
> > > > > xfer_list looks redundant.
> > > > > Can you elaborate why virtual channel management is not
> > > > > working
> > > > > for
> > > > > you?
> > > >
> > > > Each virtual descriptor encapsulates several hardware
> > > > descriptors,
> > > > which belong to same transfer.
> > > > This list (xfer_list) is used only for allocating/freeing these
> > > > descriptors and it doesn't affect on virtual dma work logic.
> > > > I can see this approach in several drivers with VirtDMA (but
> > > > they
> > > > mostly use array instead of list)
> > >
> > > You described how most of the DMA drivers are implemented, though
> > > they
> > > are using just sg_list directly. I would recommend to do the same
> > > and
> > > get rid of this list.
> >
> > This IP can be (ans is) configured with small block size.
> > (note, that I am not saying about runtime HW configuration)
> >
> > And there is opportunity what we can't use sg_list directly and
> > need
> > to
> > split sg_list to a smaller chunks.
>
> That's what I have referred quite ago. The driver should provide an
> interface to tell potential caller what maximum block (number of
> items
> with given bus width) it supports.
>
> We have struct dma_parms in struct device, but what we actually need
> is
> to support similar on per channel basis in DMAengine framework.
>
> So, instead of working around this I recommend either to implement it
> properly or rely on the fact that in the future someone eventually
> does that for you.
>
> Each driver which has this re-splitting mechanism should be cleaned
> up and refactored.
I still can't see any pros of this implementation.
There is no performance profit: we anyway need to re-splitt sg_list
(but now in dma-user driver instead of dma driver)
If we want to use same descriptors several times we just can use
DMA_CTRL_REUSE option - the descriptors will be created one time and
re-splitting will be сompleted only one time.
But there are cons of this implementation:
we need to implement re-splitting mechanism in each place we use dma
instead of one dma driver. So there are more places for bugs and etc...
> > > > > Btw, are you planning to use priority at all? For now on I
> > > > > didn't
> > > > > see
> > > > > a single driver (from the set I have checked, like 4-5 of
> > > > > them)
> > > > > that
> > > > > uses priority anyhow. It makes driver more complex for
> > > > > nothing.
> > > >
> > > > Only for dma slave operations.
> > >
> > > So, in other words you *have* an actual two or more users that
> > > *need*
> > > prioritization?
> >
> > As I remember there was an idea to give higher priority to audio
> > dma
> > chanels.
>
> I don't see cyclic transfers support in the driver. So, I would
> suggest
> just drop entire prioritization for now. When it would be actual user
> one may start thinking of it.
> Just a rule of common sense: do not implement something which will
> have no user o
[PATCH 3/3] HID: Wacom: Delete two unnecessary return statements
From: Markus Elfring Date: Tue, 25 Apr 2017 16:50:02 +0200 The script "checkpatch.pl" pointed information out like the following. WARNING: void function return statements are not generally useful Thus remove such a statement in the affected functions. Signed-off-by: Markus Elfring --- drivers/hid/wacom_sys.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index 7517da5300fd..f70e7d7351c7 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -2329,7 +2329,6 @@ static void wacom_wireless_work(struct work_struct *work) fail: wacom_release_resources(wacom1); wacom_release_resources(wacom2); - return; } static void wacom_remote_destroy_one(struct wacom *wacom, unsigned int index) @@ -2534,8 +2533,6 @@ static void wacom_mode_change_work(struct work_struct *work) if (error) return; } - - return; } static int wacom_probe(struct hid_device *hdev, -- 2.12.2
[PATCH 2/3] HID: Wacom: Improve size determinations in three functions
From: Markus Elfring
Date: Tue, 25 Apr 2017 16:38:59 +0200
Replace the specification of three data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determinations a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/hid/wacom_sys.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 550faf8819ea..7517da5300fd 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -726,7 +726,7 @@ static int wacom_add_shared_data(struct hid_device *hdev)
data = wacom_get_hdev_data(hdev);
if (!data) {
- data = kzalloc(sizeof(struct wacom_hdev_data), GFP_KERNEL);
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
retval = -ENOMEM;
goto out;
@@ -1088,7 +1088,7 @@ static int __wacom_devm_sysfs_create_group(struct wacom
*wacom,
int error;
devres = devres_alloc(wacom_devm_sysfs_group_release,
- sizeof(struct wacom_sysfs_group_devres),
+ sizeof(*devres),
GFP_KERNEL);
if (!devres)
return -ENOMEM;
@@ -2556,7 +2556,7 @@ static int wacom_probe(struct hid_device *hdev,
/* hid-core sets this quirk for the boot interface */
hdev->quirks &= ~HID_QUIRK_NOGET;
- wacom = devm_kzalloc(&hdev->dev, sizeof(struct wacom), GFP_KERNEL);
+ wacom = devm_kzalloc(&hdev->dev, sizeof(*wacom), GFP_KERNEL);
if (!wacom)
return -ENOMEM;
--
2.12.2
Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec
On Tue, Apr 25, 2017 at 5:12 PM, Sabrina Dubroca wrote: >> https://patchwork.ozlabs.org/patch/754861/ > > Yes, that prevents the overflow, but now you're just dropping > packets. Right, it's a so-called "defense-in-depth" measure. > I'll review that later, let's fix the overflow without > breaking connectivity for now. Agreed.
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Apr 25, 2017 at 11:09 AM, Christian König
wrote:
> Am 25.04.2017 um 16:34 schrieb Alex Deucher:
>>
>> On Tue, Apr 25, 2017 at 9:19 AM, Christian König
>> wrote:
>>>
>>> From: Christian König
>>>
>>> Try to resize BAR0 to let CPU access all of VRAM.
>>>
>>> v2: rebased, style cleanups, disable mem decode before resize,
>>> handle gmc_v9 as well, round size up to power of two.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
>>> ++
>>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
>>> 5 files changed, 54 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 4a16e3c..9484062 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
>>> amdgpu_device *adev, struct ttm_tt *ttm,
>>> struct ttm_mem_reg *mem);
>>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc, u64 base);
>>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc);
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
>>> size);
>>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>>> void amdgpu_ttm_fini(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index a09ad3cf..d5ca77a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>>> struct amdgpu_mc *mc)
>>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>>> }
>>>
>>> +/**
>>> + * amdgpu_resize_bar0 - try to resize BAR0
>>> + *
>>> + * @adev: amdgpu_device pointer
>>> + *
>>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>>> + */
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
>>
>> I'd suggest renaming this to amdgpu_device_resize_bar() to try and
>> impose some consistency in this file, but not a big deal either way.
>>
>>> +{
>>> + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
>>> + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
>>> + u16 cmd;
>>> + int r;
>>> +
>>> + /* Free the doorbell mapping, it most likely needs to move as
>>> well */
>>> + amdgpu_doorbell_fini(adev);
>>> + pci_release_resource(adev->pdev, 2);
>>
>> This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
>> didn't have doorbells.
>>
>>> +
>>> + /* Disable memory decoding while we change the BAR addresses and
>>> size */
>>> + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
>>> + pci_write_config_word(adev->pdev, PCI_COMMAND,
>>> + cmd & ~PCI_COMMAND_MEMORY);
>>> +
>>> + r = pci_resize_resource(adev->pdev, 0, rbar_size);
>>> + if (r == -ENOSPC)
>>> + DRM_INFO("Not enough PCI address space for a large
>>> BAR.");
>>> + else if (r && r != -ENOTSUPP)
>>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>>> +
>>> + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
>>> +
>>> + /* When the doorbell BAR isn't available we have no chance of
>>> +* using the device.
>>> +*/
>>> + BUG_ON(amdgpu_doorbell_init(adev));
>>
>> Same here.
>>
>>> +}
>>> +
>>> /*
>>>* GPU helpers function.
>>>*/
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> index a9083a1..ae71524 100644
>>
>> What about SI (gmc_v6_0.c)?
>
>
> As far as I know there is no SI hardware with resizeable BAR support.
>
> The all VI generation can do this, but I'm not 100% sure if there aren't any
> Bonaires out there which can handle it as well that's why I added gmc_v7
> support.
>
> Still need to double check that.
I think NI or even evergreen supported resizeable bars in theory,
although I'm not sure if any boards were fused to expose it.
Alex
>
> Christian.
>
>
>>
>> Alex
>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> @@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
>>> *adev)
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> }
>>> - /* Could aper size report 0 ? */
>>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> /* size in MB on si */
>>>
[PATCH 1/3] HID: Wacom: Use devm_kcalloc() in two functions
From: Markus Elfring
Date: Tue, 25 Apr 2017 16:06:08 +0200
* Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle software.
* Replace the specification of data structures by pointer dereferences
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring
---
drivers/hid/wacom_sys.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 0022c0dac88a..550faf8819ea 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1245,7 +1245,7 @@ static int wacom_led_groups_alloc_and_register_one(struct
device *dev,
if (!devres_open_group(dev, &wacom->led.groups[group_id], GFP_KERNEL))
return -ENOMEM;
- leds = devm_kzalloc(dev, sizeof(struct wacom_led) * count, GFP_KERNEL);
+ leds = devm_kcalloc(dev, count, sizeof(*leds), GFP_KERNEL);
if (!leds) {
error = -ENOMEM;
goto err;
@@ -1345,8 +1345,7 @@ static int wacom_led_groups_allocate(struct wacom *wacom,
int count)
struct wacom_group_leds *groups;
int error;
- groups = devm_kzalloc(dev, sizeof(struct wacom_group_leds) * count,
- GFP_KERNEL);
+ groups = devm_kcalloc(dev, count, sizeof(*groups), GFP_KERNEL);
if (!groups)
return -ENOMEM;
--
2.12.2
[PATCH 4.10 12/24] Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Leemhuis
commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream.
Temporary got a Lifebook E547 into my hands and noticed the touchpad
only works after running:
echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
Add it to the list of machines that need this workaround.
Signed-off-by: Thorsten Leemhuis
Reviewed-by: Ulrik De Bie
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/mouse/elantech.c |8
1 file changed, 8 insertions(+)
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1118,6 +1118,7 @@ static int elantech_get_resolution_v4(st
* Asus UX32VD 0x361f0200, 15, 0e clickpad
* Avatar AVIU-145A2 0x361f00? clickpad
* Fujitsu LIFEBOOK E544 0x470f00d0, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E547 0x470f0050, 12, 09 2 hw buttons
* Fujitsu LIFEBOOK E554 0x570f0140, 14, 0c 2 hw buttons
* Fujitsu T7250x470f0105, 12, 09 2 hw buttons
* Fujitsu H7300x570f00c0, 14, 0c 3 hw buttons (**)
@@ -1524,6 +1525,13 @@ static const struct dmi_system_id elante
},
},
{
+ /* Fujitsu LIFEBOOK E547 does not work with crc_enabled == 0 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E547"),
+ },
+ },
+ {
/* Fujitsu LIFEBOOK E554 does not work with crc_enabled == 0 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
[PATCH 4.10 03/24] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.
This fixes CVE-2017-7472.
Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:
#include
int main()
{
for (;;)
keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
}
Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.
Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman
---
security/keys/keyctl.c | 11 +++---
security/keys/process_keys.c | 44 ++-
2 files changed, 31 insertions(+), 24 deletions(-)
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1256,8 +1256,8 @@ error:
* Read or set the default keyring in which request_key() will cache keys and
* return the old setting.
*
- * If a process keyring is specified then this will be created if it doesn't
- * yet exist. The old setting will be returned if successful.
+ * If a thread or process keyring is specified then it will be created if it
+ * doesn't yet exist. The old setting will be returned if successful.
*/
long keyctl_set_reqkey_keyring(int reqkey_defl)
{
@@ -1282,11 +1282,8 @@ long keyctl_set_reqkey_keyring(int reqke
case KEY_REQKEY_DEFL_PROCESS_KEYRING:
ret = install_process_keyring_to_cred(new);
- if (ret < 0) {
- if (ret != -EEXIST)
- goto error;
- ret = 0;
- }
+ if (ret < 0)
+ goto error;
goto set;
case KEY_REQKEY_DEFL_DEFAULT:
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -127,13 +127,18 @@ error:
}
/*
- * Install a fresh thread keyring directly to new credentials. This keyring is
- * allowed to overrun the quota.
+ * Install a thread keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
int install_thread_keyring_to_cred(struct cred *new)
{
struct key *keyring;
+ if (new->thread_keyring)
+ return 0;
+
keyring = keyring_alloc("_tid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
KEY_ALLOC_QUOTA_OVERRUN,
@@ -146,7 +151,9 @@ int install_thread_keyring_to_cred(struc
}
/*
- * Install a fresh thread keyring, discarding the old one.
+ * Install a thread keyring to the current task if it didn't have one already.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
*/
static int install_thread_keyring(void)
{
@@ -157,8 +164,6 @@ static int install_thread_keyring(void)
if (!new)
return -ENOMEM;
- BUG_ON(new->thread_keyring);
-
ret = install_thread_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
@@ -169,17 +174,17 @@ static int install_thread_keyring(void)
}
/*
- * Install a process keyring directly to a credentials struct.
+ * Install a process keyring to the given credentials struct if it didn't have
+ * one already. This is allowed to overrun the quota.
*
- * Returns -EEXIST if there was already a process keyring, 0 if one installed,
- * and other value on any other error
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
int install_process_keyring_to_cred(struct cred *new)
{
struct key *keyring;
if (new->process_keyring)
- return -EEXIST;
+ return 0;
keyring = keyring_alloc("_pid", new->uid, new->gid, new,
KEY_POS_ALL | KEY_USR_VIEW,
@@ -193,11 +198,9 @@ int install_process_keyring_to_cred(stru
}
/*
- * Make sure a process keyring is installed for the current process. The
- * existing process keyring is not replaced.
+ * Install a process keyring to the current task if it didn't have one already.
*
- * Returns 0 if there is a process keyring by the end of this function, some
- * error otherwise.
+ * Return: 0 if a process keyring is now present; -errno on failure.
*/
static int install_process_keyring(void)
{
@@ -211,14 +214,18 @@ static int install_process_keyring(void)
ret = install_process_keyring_to_cred(new);
if (ret < 0) {
abort_creds(new);
- return ret != -EEXIST ? ret : 0;
+ return ret;
}
return commit_cre
[PATCH 4.10 11/24] s390/mm: fix CMMA vs KSM vs others
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Borntraeger
commit a8f60d1fadf7b8b54449fcc9d6b15248917478ba upstream.
On heavy paging with KSM I see guest data corruption. Turns out that
KSM will add pages to its tree, where the mapping return true for
pte_unused (or might become as such later). KSM will unmap such pages
and reinstantiate with different attributes (e.g. write protected or
special, e.g. in replace_page or write_protect_page)). This uncovered
a bug in our pagetable handling: We must remove the unused flag as
soon as an entry becomes present again.
Signed-of-by: Christian Borntraeger
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman
---
arch/s390/include/asm/pgtable.h |2 ++
1 file changed, 2 insertions(+)
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1029,6 +1029,8 @@ int get_guest_storage_key(struct mm_stru
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t entry)
{
+ if (pte_present(entry))
+ pte_val(entry) &= ~_PAGE_UNUSED;
if (mm_has_pgste(mm))
ptep_set_pte_at(mm, addr, ptep, entry);
else
[PATCH 4.10 07/24] mm: prevent NR_ISOLATE_* stats from going negative
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Rabin Vincent
commit fc280fe871449ead4bdbd1665fa52c7c01c64765 upstream.
Commit 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn
based migration") moved the dec_node_page_state() call (along with the
page_is_file_cache() call) to after putback_lru_page().
But page_is_file_cache() can change after putback_lru_page() is called,
so it should be called before putback_lru_page(), as it was before that
patch, to prevent NR_ISOLATE_* stats from going negative.
Without this fix, non-CONFIG_SMP kernels end up hanging in the
while(too_many_isolated()) { congestion_wait() } loop in
shrink_active_list() due to the negative stats.
Mem-Info:
active_anon:32567 inactive_anon:121 isolated_anon:1
active_file:6066 inactive_file:6639 isolated_file:4294967295
^^
unevictable:0 dirty:115 writeback:0 unstable:0
slab_reclaimable:2086 slab_unreclaimable:3167
mapped:3398 shmem:18366 pagetables:1145 bounce:0
free:1798 free_pcp:13 free_cma:0
Fixes: 6afcf8ef0ca0 ("mm, compaction: fix NR_ISOLATED_* stats for pfn based
migration")
Link:
http://lkml.kernel.org/r/1492683865-27549-1-git-send-email-rabin.vinc...@axis.com
Signed-off-by: Rabin Vincent
Acked-by: Michal Hocko
Cc: Ming Ling
Cc: Minchan Kim
Cc: Vlastimil Babka
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/migrate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -183,9 +183,9 @@ void putback_movable_pages(struct list_h
unlock_page(page);
put_page(page);
} else {
- putback_lru_page(page);
dec_node_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
+ putback_lru_page(page);
}
}
}
[PATCH 4.10 17/24] ubifs: Fix O_TMPFILE corner case in ubifs_link()
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Richard Weinberger
commit 32fe905c17f001c0eee13c59afddd0bf2eed509c upstream.
It is perfectly fine to link a tmpfile back using linkat().
Since tmpfiles are created with a link count of 0 they appear
on the orphan list, upon re-linking the inode has to be removed
from the orphan list again.
Ralph faced a filesystem corruption in combination with overlayfs
due to this bug.
Cc: Ralph Sennhauser
Cc: Amir Goldstein
Reported-by: Ralph Sennhauser
Tested-by: Ralph Sennhauser
Reported-by: Amir Goldstein
Fixes: 474b93704f321 ("ubifs: Implement O_TMPFILE")
Signed-off-by: Richard Weinberger
Signed-off-by: Greg Kroah-Hartman
---
fs/ubifs/dir.c |7 +++
1 file changed, 7 insertions(+)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -748,6 +748,11 @@ static int ubifs_link(struct dentry *old
goto out_fname;
lock_2_inodes(dir, inode);
+
+ /* Handle O_TMPFILE corner case, it is allowed to link a O_TMPFILE. */
+ if (inode->i_nlink == 0)
+ ubifs_delete_orphan(c, inode->i_ino);
+
inc_nlink(inode);
ihold(inode);
inode->i_ctime = ubifs_current_time(inode);
@@ -768,6 +773,8 @@ out_cancel:
dir->i_size -= sz_change;
dir_ui->ui_size = dir->i_size;
drop_nlink(inode);
+ if (inode->i_nlink == 0)
+ ubifs_add_orphan(c, inode->i_ino);
unlock_2_inodes(dir, inode);
ubifs_release_budget(c, &req);
iput(inode);
[PATCH 4.10 15/24] mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Haibo Chen
commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream.
Currently for DDR50 card, it need tuning in default. We meet tuning fail
issue for DDR50 card and some data CRC error when DDR50 sd card works.
This is because the default pad I/O drive strength can't make sure DDR50
card work stable. So increase the pad I/O drive strength for DDR50 card,
and use pins_100mhz.
This fixes DDR50 card support for IMX since DDR50 tuning was enabled from
commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50")
Tested-and-reported-by: Tim Harvey
Signed-off-by: Haibo Chen
Acked-by: Dong Aisheng
Acked-by: Adrian Hunter
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
---
drivers/mmc/host/sdhci-esdhc-imx.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -830,6 +830,7 @@ static int esdhc_change_pinstate(struct
switch (uhs) {
case MMC_TIMING_UHS_SDR50:
+ case MMC_TIMING_UHS_DDR50:
pinctrl = imx_data->pins_100mhz;
break;
case MMC_TIMING_UHS_SDR104:
[PATCH 4.10 06/24] ring-buffer: Have ring_buffer_iter_empty() return true when empty
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (VMware)
commit 78f7a45dac2a2d2002f98a3a95f7979867868d73 upstream.
I noticed that reading the snapshot file when it is empty no longer gives a
status. It suppose to show the status of the snapshot buffer as well as how
to allocate and use it. For example:
># cat snapshot
# tracer: nop
#
#
# * Snapshot is allocated *
#
# Snapshot commands:
# echo 0 > snapshot : Clears and frees snapshot buffer
# echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
# Takes a snapshot of the main buffer.
# echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
# (Doesn't have to be '2' works with any number that
# is not a '0' or '1')
But instead it just showed an empty buffer:
># cat snapshot
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:4
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
What happened was that it was using the ring_buffer_iter_empty() function to
see if it was empty, and if it was, it showed the status. But that function
was returning false when it was empty. The reason was that the iter header
page was on the reader page, and the reader page was empty, but so was the
buffer itself. The check only tested to see if the iter was on the commit
page, but the commit page was no longer pointing to the reader page, but as
all pages were empty, the buffer is also.
Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page")
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Greg Kroah-Hartman
---
kernel/trace/ring_buffer.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3404,11 +3404,23 @@ EXPORT_SYMBOL_GPL(ring_buffer_iter_reset
int ring_buffer_iter_empty(struct ring_buffer_iter *iter)
{
struct ring_buffer_per_cpu *cpu_buffer;
+ struct buffer_page *reader;
+ struct buffer_page *head_page;
+ struct buffer_page *commit_page;
+ unsigned commit;
cpu_buffer = iter->cpu_buffer;
- return iter->head_page == cpu_buffer->commit_page &&
- iter->head == rb_commit_index(cpu_buffer);
+ /* Remember, trace recording is off when iterator is in use */
+ reader = cpu_buffer->reader_page;
+ head_page = cpu_buffer->head_page;
+ commit_page = cpu_buffer->commit_page;
+ commit = rb_page_commit(commit_page);
+
+ return ((iter->head_page == commit_page && iter->head == commit) ||
+ (iter->head_page == reader && commit_page == head_page &&
+head_page->read == commit &&
+iter->head == rb_page_commit(cpu_buffer->reader_page)));
}
EXPORT_SYMBOL_GPL(ring_buffer_iter_empty);
[PATCH 4.10 24/24] device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Dan Williams
commit 956a4cd2c957acf638ff29951aabaa9d8e92bbc2 upstream.
The following warning triggers with a new unit test that stresses the
device-dax interface.
===
[ ERR: suspicious RCU usage. ]
4.11.0-rc4+ #1049 Tainted: G O
---
./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side
critical section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
2 locks held by fio/9070:
#0: (&mm->mmap_sem){++}, at: []
__do_page_fault+0x167/0x4f0
#1: (rcu_read_lock){..}, at: []
dax_dev_huge_fault+0x32/0x620 [dax]
Call Trace:
dump_stack+0x86/0xc3
lockdep_rcu_suspicious+0xd7/0x110
___might_sleep+0xac/0x250
__might_sleep+0x4a/0x80
__alloc_pages_nodemask+0x23a/0x360
alloc_pages_current+0xa1/0x1f0
pte_alloc_one+0x17/0x80
__pte_alloc+0x1e/0x120
__get_locked_pte+0x1bf/0x1d0
insert_pfn.isra.70+0x3a/0x100
? lookup_memtype+0xa6/0xd0
vm_insert_mixed+0x64/0x90
dax_dev_huge_fault+0x520/0x620 [dax]
? dax_dev_huge_fault+0x32/0x620 [dax]
dax_dev_fault+0x10/0x20 [dax]
__do_fault+0x1e/0x140
__handle_mm_fault+0x9af/0x10d0
handle_mm_fault+0x16d/0x370
? handle_mm_fault+0x47/0x370
__do_page_fault+0x28c/0x4f0
trace_do_page_fault+0x58/0x2a0
do_async_page_fault+0x1a/0xa0
async_page_fault+0x28/0x30
Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/dax/Kconfig |1 +
drivers/dax/dax.c | 13 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/dax/Kconfig
+++ b/drivers/dax/Kconfig
@@ -2,6 +2,7 @@ menuconfig DEV_DAX
tristate "DAX: direct access to differentiated memory"
default m if NVDIMM_DAX
depends on TRANSPARENT_HUGEPAGE
+ select SRCU
help
Support raw access to differentiated (persistence, bandwidth,
latency...) memory via an mmap(2) capable character
--- a/drivers/dax/dax.c
+++ b/drivers/dax/dax.c
@@ -24,6 +24,7 @@
#include "dax.h"
static dev_t dax_devt;
+DEFINE_STATIC_SRCU(dax_srcu);
static struct class *dax_class;
static DEFINE_IDA(dax_minor_ida);
static int nr_dax = CONFIG_NR_DEV_DAX;
@@ -59,7 +60,7 @@ struct dax_region {
* @region - parent region
* @dev - device backing the character device
* @cdev - core chardev data
- * @alive - !alive + rcu grace period == no new mappings can be established
+ * @alive - !alive + srcu grace period == no new mappings can be established
* @id - child id in the region
* @num_resources - number of physical address extents in this device
* @res - array of physical address ranges
@@ -530,7 +531,7 @@ static int __dax_dev_pmd_fault(struct da
static int dax_dev_pmd_fault(struct vm_area_struct *vma, unsigned long addr,
pmd_t *pmd, unsigned int flags)
{
- int rc;
+ int rc, id;
struct file *filp = vma->vm_file;
struct dax_dev *dax_dev = filp->private_data;
@@ -538,9 +539,9 @@ static int dax_dev_pmd_fault(struct vm_a
current->comm, (flags & FAULT_FLAG_WRITE)
? "write" : "read", vma->vm_start, vma->vm_end);
- rcu_read_lock();
+ id = srcu_read_lock(&dax_srcu);
rc = __dax_dev_pmd_fault(dax_dev, vma, addr, pmd, flags);
- rcu_read_unlock();
+ srcu_read_unlock(&dax_srcu, id);
return rc;
}
@@ -656,11 +657,11 @@ static void unregister_dax_dev(void *dev
* Note, rcu is not protecting the liveness of dax_dev, rcu is
* ensuring that any fault handlers that might have seen
* dax_dev->alive == true, have completed. Any fault handlers
-* that start after synchronize_rcu() has started will abort
+* that start after synchronize_srcu() has started will abort
* upon seeing dax_dev->alive == false.
*/
dax_dev->alive = false;
- synchronize_rcu();
+ synchronize_srcu(&dax_srcu);
unmap_mapping_range(dax_dev->inode->i_mapping, 0, 0, 1);
cdev_del(cdev);
device_unregister(dev);
