Re: [RFC] Second attempt at kernel secure boot support
* Eric W. Biederman: > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Interesting idea. Unfortunately, it is very hard to detect reliably that Windows is not present from the bootloader, so it's not possible to use this approach to simplify matters. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. That's not necessarily true. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. As already explained, I don't think that user presence accomplishes anything. You need informed consent, and it's impossible to cram that on a 80x25 screen. You also need to make sure that you aren't unnecessarily alarmist. We don't want a "Linux may harm your computer" warning. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. I don't like this approach, either. > Furthermore no matter how hard we try with current techniques there will > eventually be kernel bugs that allow attackers to inject code into the > kernel. So attempting to fully close that attack vector is > questionable. I suspect we'd need to revoke old binaries after a grace period. I guess the Microsoft approach is to revoke only what's actually used for attacks, but that leads to a lot of unpredictability for our users. It's also annoying if we figure out after release that we have to disable additional kernel functionality because it can be used to compromise the boot path. Users will not like that, especially if they do not use Windows at all. Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] mfd: max8925: add dts
From: Qing Xu
add max8925 dts support into mmp2 brownstone platform
Signed-off-by: Qing Xu
---
arch/arm/boot/dts/mmp2-brownstone.dts | 166 +
arch/arm/boot/dts/mmp2.dtsi |4 +-
2 files changed, 169 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts
b/arch/arm/boot/dts/mmp2-brownstone.dts
index c9b4f27..e22f58c 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -29,6 +29,172 @@
};
twsi1: i2c@d4011000 {
status = "okay";
+ pmic: max8925@3c {
+ compatible = "marvell,max8925";
+ reg = <0x3c>;
+ interrupts = <1 0>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ SDV1 {
+ regulator-min-microvolt
= <637500>;
+ regulator-max-microvolt
= <1425000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ SDV2 {
+ regulator-min-microvolt
= <65>;
+ regulator-max-microvolt
= <2225000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ SDV3 {
+ regulator-min-microvolt
= <75>;
+ regulator-max-microvolt
= <390>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO1 {
+ regulator-min-microvolt
= <75>;
+ regulator-max-microvolt
= <390>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO2 {
+ regulator-min-microvolt
= <65>;
+ regulator-max-microvolt
= <225>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO3 {
+ regulator-min-microvolt
= <65>;
+ regulator-max-microvolt
= <225>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO4 {
+ regulator-min-microvolt
= <75>;
+ regulator-max-microvolt
= <390>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO5 {
+ regulator-min-microvolt
= <75>;
+ regulator-max-microvolt
= <390>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO6 {
+ regulator-min-microvolt
= <75>;
+ regulator-max-microvolt
= <390>;
+ regulator-boot-on;
+
[PATCH 6/7] mfd: max8925: support dt for backlight
From: Qing Xu
Signed-off-by: Qing Xu
---
drivers/video/backlight/max8925_bl.c | 31 ++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/drivers/video/backlight/max8925_bl.c
b/drivers/video/backlight/max8925_bl.c
index f72ba54..7de02ed 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -101,6 +101,29 @@ static const struct backlight_ops max8925_backlight_ops = {
.get_brightness = max8925_backlight_get_brightness,
};
+#ifdef CONFIG_OF
+static int max8925_backlight_dt_init(struct platform_device *pdev,
+ struct max8925_backlight_pdata *pdata)
+{
+ struct device_node *nproot = pdev->dev.parent->of_node, *np;
+ int dual_string;
+
+ if (!nproot)
+ return -ENODEV;
+ np = of_find_node_by_name(nproot, "backlight");
+ if (!np) {
+ dev_err(>dev, "failed to find backlight node\n");
+ return -ENODEV;
+ }
+
+ of_property_read_u32(np, "dual-string", _string);
+ pdata->dual_string = dual_string;
+ return 0;
+}
+#else
+#define max8925_backlight_dt_init(x, y)(-1)
+#endif
+
static int __devinit max8925_backlight_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
@@ -150,6 +173,13 @@ static int __devinit max8925_backlight_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, bl);
value = 0;
+ if (pdev->dev.parent->of_node && !pdata) {
+ pdata = devm_kzalloc(>dev,
+sizeof(struct max8925_backlight_pdata),
+GFP_KERNEL);
+ max8925_backlight_dt_init(pdev, pdata);
+ }
+
if (pdata) {
if (pdata->lxw_scl)
value |= (1 << 7);
@@ -161,7 +191,6 @@ static int __devinit max8925_backlight_probe(struct
platform_device *pdev)
ret = max8925_set_bits(chip->i2c, data->reg_mode_cntl, 0xfe, value);
if (ret < 0)
goto out_brt;
-
backlight_update_status(bl);
return 0;
out_brt:
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] memory: davinci - add aemif controller platform driver
On 11/6/2012 2:38 AM, Murali Karicheri wrote: > On 11/04/2012 08:52 AM, Rob Herring wrote: >> OMAP GPMC > Could you send me a link please? https://www.google.com/search?q=RFC+OMAP+GPMC+DT+bindings The patches series is sent by Daniel Mack. v3 was the last version sent. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] mfd: max8925: support dt for regulator
From: Qing Xu
Signed-off-by: Qing Xu
---
drivers/regulator/max8925-regulator.c | 35 -
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/max8925-regulator.c
b/drivers/regulator/max8925-regulator.c
index 9bb0be3..16d9457 100644
--- a/drivers/regulator/max8925-regulator.c
+++ b/drivers/regulator/max8925-regulator.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#define SD1_DVM_VMIN 85
#define SD1_DVM_VMAX 100
@@ -214,6 +216,34 @@ static struct max8925_regulator_info
max8925_regulator_info[] = {
MAX8925_LDO(20, 750, 3900, 50),
};
+#ifdef CONFIG_OF
+static int max8925_regulator_dt_init(struct platform_device *pdev,
+ struct max8925_regulator_info *info,
+ struct regulator_config *config)
+{
+ struct device_node *nproot, *np;
+ nproot = pdev->dev.parent->of_node;
+ if (!nproot)
+ return -ENODEV;
+ nproot = of_find_node_by_name(nproot, "regulators");
+ if (!nproot) {
+ dev_err(>dev, "failed to find regulators node\n");
+ return -ENODEV;
+ }
+ for_each_child_of_node(nproot, np) {
+ if (!of_node_cmp(np->name, info->desc.name)) {
+ config->init_data =
+ of_get_regulator_init_data(>dev, np);
+ config->of_node = np;
+ break;
+ }
+ }
+ return 0;
+}
+#else
+#define max8925_regulator_dt_init(x, y, z) (-1)
+#endif
+
static int __devinit max8925_regulator_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
@@ -243,9 +273,12 @@ static int __devinit max8925_regulator_probe(struct
platform_device *pdev)
ri->chip = chip;
config.dev = >dev;
- config.init_data = pdata;
config.driver_data = ri;
+ if (max8925_regulator_dt_init(pdev, ri, ))
+ if (pdata)
+ config.init_data = pdata;
+
rdev = regulator_register(>desc, );
if (IS_ERR(rdev)) {
dev_err(>dev, "failed to register regulator %s\n",
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mfd: max8925: support dt for power supply
From: Qing Xu
Signed-off-by: Qing Xu
---
drivers/power/max8925_power.c | 57
1 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index daa333b..dd2ac2d 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -426,14 +426,58 @@ static __devexit int max8925_deinit_charger(struct
max8925_power_info *info)
return 0;
}
+#ifdef CONFIG_OF
+static int max8925_power_dt_init(struct platform_device *pdev,
+ struct max8925_power_pdata *pdata)
+{
+ struct device_node *nproot = pdev->dev.parent->of_node, *np;
+ int batt_detect, topoff_threshold, fast_charge,
+ no_temp_support, no_insert_detect;
+
+ if (!nproot)
+ return -ENODEV;
+ np = of_find_node_by_name(nproot, "charger");
+ if (!np) {
+ dev_err(>dev, "failed to find charger node\n");
+ return -ENODEV;
+ }
+ of_property_read_u32(np, "topoff-threshold", _threshold);
+ of_property_read_u32(np, "batt-detect", _detect);
+ of_property_read_u32(np, "fast-charge", _charge);
+ of_property_read_u32(np, "no-insert-detect", _insert_detect);
+ of_property_read_u32(np, "no-temp-support", _temp_support);
+
+ pdata->batt_detect = batt_detect;
+ pdata->fast_charge = fast_charge;
+ pdata->topoff_threshold = topoff_threshold;
+ pdata->no_insert_detect = no_insert_detect;
+ pdata->no_temp_support = no_temp_support;
+ pr_err("batt_detect%d, topoff_threshold%d,
fast_charge%d,no_temp_support%d, no_insert_detect%d\n",
+ batt_detect, topoff_threshold, fast_charge,
+ no_temp_support, no_insert_detect);
+ return 0;
+}
+#else
+#define max8925_power_dt_init(x, y)(-1)
+#endif
+
+static char *power_supplicants[] = {
+ "max8925-battery",
+};
+
static __devinit int max8925_power_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
- struct max8925_power_pdata *pdata = NULL;
+ struct max8925_power_pdata *pdata = pdev->dev.platform_data;
struct max8925_power_info *info;
int ret;
- pdata = pdev->dev.platform_data;
+ if (pdev->dev.parent->of_node && !pdata) {
+ pdata = devm_kzalloc(>dev,
+sizeof(struct max8925_power_pdata),
+GFP_KERNEL);
+ max8925_power_dt_init(pdev, pdata);
+ }
if (!pdata) {
dev_err(>dev, "platform data isn't assigned to "
"power supply\n");
@@ -453,8 +497,8 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->ac.properties = max8925_ac_props;
info->ac.num_properties = ARRAY_SIZE(max8925_ac_props);
info->ac.get_property = max8925_ac_get_prop;
- info->ac.supplied_to = pdata->supplied_to;
- info->ac.num_supplicants = pdata->num_supplicants;
+ info->ac.supplied_to = power_supplicants;
+ info->ac.num_supplicants = ARRAY_SIZE(power_supplicants);
ret = power_supply_register(>dev, >ac);
if (ret)
goto out;
@@ -465,8 +509,8 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->usb.properties = max8925_usb_props;
info->usb.num_properties = ARRAY_SIZE(max8925_usb_props);
info->usb.get_property = max8925_usb_get_prop;
- info->usb.supplied_to = pdata->supplied_to;
- info->usb.num_supplicants = pdata->num_supplicants;
+ info->usb.supplied_to = power_supplicants;
+ info->usb.num_supplicants = ARRAY_SIZE(power_supplicants);
ret = power_supply_register(>dev, >usb);
if (ret)
@@ -491,6 +535,7 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->no_insert_detect = pdata->no_insert_detect;
max8925_init_charger(chip, info);
+
return 0;
out_battery:
power_supply_unregister(>battery);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mfd: max8925: support dt for power supply
From: Qing Xu
Signed-off-by: Qing Xu
---
drivers/power/max8925_power.c | 57
1 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index daa333b..dd2ac2d 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -426,14 +426,58 @@ static __devexit int max8925_deinit_charger(struct
max8925_power_info *info)
return 0;
}
+#ifdef CONFIG_OF
+static int max8925_power_dt_init(struct platform_device *pdev,
+ struct max8925_power_pdata *pdata)
+{
+ struct device_node *nproot = pdev->dev.parent->of_node, *np;
+ int batt_detect, topoff_threshold, fast_charge,
+ no_temp_support, no_insert_detect;
+
+ if (!nproot)
+ return -ENODEV;
+ np = of_find_node_by_name(nproot, "charger");
+ if (!np) {
+ dev_err(>dev, "failed to find charger node\n");
+ return -ENODEV;
+ }
+ of_property_read_u32(np, "topoff-threshold", _threshold);
+ of_property_read_u32(np, "batt-detect", _detect);
+ of_property_read_u32(np, "fast-charge", _charge);
+ of_property_read_u32(np, "no-insert-detect", _insert_detect);
+ of_property_read_u32(np, "no-temp-support", _temp_support);
+
+ pdata->batt_detect = batt_detect;
+ pdata->fast_charge = fast_charge;
+ pdata->topoff_threshold = topoff_threshold;
+ pdata->no_insert_detect = no_insert_detect;
+ pdata->no_temp_support = no_temp_support;
+ pr_err("batt_detect%d, topoff_threshold%d,
fast_charge%d,no_temp_support%d, no_insert_detect%d\n",
+ batt_detect, topoff_threshold, fast_charge,
+ no_temp_support, no_insert_detect);
+ return 0;
+}
+#else
+#define max8925_power_dt_init(x, y)(-1)
+#endif
+
+static char *power_supplicants[] = {
+ "max8925-battery",
+};
+
static __devinit int max8925_power_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
- struct max8925_power_pdata *pdata = NULL;
+ struct max8925_power_pdata *pdata = pdev->dev.platform_data;
struct max8925_power_info *info;
int ret;
- pdata = pdev->dev.platform_data;
+ if (pdev->dev.parent->of_node && !pdata) {
+ pdata = devm_kzalloc(>dev,
+sizeof(struct max8925_power_pdata),
+GFP_KERNEL);
+ max8925_power_dt_init(pdev, pdata);
+ }
if (!pdata) {
dev_err(>dev, "platform data isn't assigned to "
"power supply\n");
@@ -453,8 +497,8 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->ac.properties = max8925_ac_props;
info->ac.num_properties = ARRAY_SIZE(max8925_ac_props);
info->ac.get_property = max8925_ac_get_prop;
- info->ac.supplied_to = pdata->supplied_to;
- info->ac.num_supplicants = pdata->num_supplicants;
+ info->ac.supplied_to = power_supplicants;
+ info->ac.num_supplicants = ARRAY_SIZE(power_supplicants);
ret = power_supply_register(>dev, >ac);
if (ret)
goto out;
@@ -465,8 +509,8 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->usb.properties = max8925_usb_props;
info->usb.num_properties = ARRAY_SIZE(max8925_usb_props);
info->usb.get_property = max8925_usb_get_prop;
- info->usb.supplied_to = pdata->supplied_to;
- info->usb.num_supplicants = pdata->num_supplicants;
+ info->usb.supplied_to = power_supplicants;
+ info->usb.num_supplicants = ARRAY_SIZE(power_supplicants);
ret = power_supply_register(>dev, >usb);
if (ret)
@@ -491,6 +535,7 @@ static __devinit int max8925_power_probe(struct
platform_device *pdev)
info->no_insert_detect = pdata->no_insert_detect;
max8925_init_charger(chip, info);
+
return 0;
out_battery:
power_supply_unregister(>battery);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] mfd: max8925: fix onkey driver irq base
From: Qing Xu
update onkey driver's irq base, it should get from max8925,
but not save in a private value
Signed-off-by: Qing Xu
---
drivers/input/misc/max8925_onkey.c |3 ---
drivers/mfd/max8925-core.c |2 +-
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/input/misc/max8925_onkey.c
b/drivers/input/misc/max8925_onkey.c
index 0a12b74..6527789 100644
--- a/drivers/input/misc/max8925_onkey.c
+++ b/drivers/input/misc/max8925_onkey.c
@@ -100,9 +100,6 @@ static int __devinit max8925_onkey_probe(struct
platform_device *pdev)
input->dev.parent = >dev;
input_set_capability(input, EV_KEY, KEY_POWER);
- irq[0] += chip->irq_base;
- irq[1] += chip->irq_base;
-
error = request_threaded_irq(irq[0], NULL, max8925_onkey_handler,
IRQF_ONESHOT, "onkey-down", info);
if (error < 0) {
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index b1eacae..37a372d 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -881,7 +881,7 @@ int __devinit max8925_device_init(struct max8925_chip *chip,
ret = mfd_add_devices(chip->dev, 0, _devs[0],
ARRAY_SIZE(onkey_devs),
- NULL, 0, NULL);
+ NULL, chip->irq_base, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add onkey subdev\n");
goto out_dev;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] mfd: max8925: add irqdomain for dt
From: Qing Xu
Add irqdomains for max8925's main irq, and touch irq.
Wrap irq register operations into irqdomain's map func.
it is necessary for dt support.
Also, add dt support for max8925 driver.
Signed-off-by: Qing Xu
---
drivers/mfd/max8925-core.c | 87 ---
drivers/mfd/max8925-i2c.c | 32 +++-
include/linux/mfd/max8925.h | 12 -
3 files changed, 96 insertions(+), 35 deletions(-)
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index 1e0ab0a..dcc218a 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -14,10 +14,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
+#include
static struct resource bk_resources[] __devinitdata = {
{ 0x84, 0x84, "mode control", IORESOURCE_REG, },
@@ -639,17 +643,34 @@ static struct irq_chip max8925_irq_chip = {
.irq_disable= max8925_irq_disable,
};
+static int max8925_irq_domain_map(struct irq_domain *d, unsigned int virq,
+irq_hw_number_t hw)
+{
+ irq_set_chip_data(virq, d->host_data);
+ irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ irq_set_noprobe(virq);
+#endif
+ return 0;
+}
+
+static struct irq_domain_ops max8925_irq_domain_ops = {
+ .map= max8925_irq_domain_map,
+ .xlate = irq_domain_xlate_onetwocell,
+};
+
+
static int max8925_irq_init(struct max8925_chip *chip, int irq,
struct max8925_platform_data *pdata)
{
unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
- int i, ret;
- int __irq;
+ int ret;
+ int tsc_irq;
+ struct device_node *node = chip->dev->of_node;
- if (!pdata || !pdata->irq_base) {
- dev_warn(chip->dev, "No interrupt support on IRQ base\n");
- return -EINVAL;
- }
/* clear all interrupts */
max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ1);
max8925_reg_read(chip->i2c, MAX8925_CHG_IRQ2);
@@ -667,45 +688,51 @@ static int max8925_irq_init(struct max8925_chip *chip,
int irq,
max8925_reg_write(chip->rtc, MAX8925_RTC_IRQ_MASK, 0xff);
mutex_init(>irq_lock);
- chip->core_irq = irq;
- chip->irq_base = pdata->irq_base;
- /* register with genirq */
- for (i = 0; i < ARRAY_SIZE(max8925_irqs); i++) {
- __irq = i + chip->irq_base;
- irq_set_chip_data(__irq, chip);
- irq_set_chip_and_handler(__irq, _irq_chip,
-handle_edge_irq);
- irq_set_nested_thread(__irq, 1);
-#ifdef CONFIG_ARM
- set_irq_flags(__irq, IRQF_VALID);
-#else
- irq_set_noprobe(__irq);
-#endif
- }
- if (!irq) {
- dev_warn(chip->dev, "No interrupt support on core IRQ\n");
- goto tsc_irq;
+ /* domain1: init charger/rtc/onkey irq domain*/
+ chip->irq_base = irq_alloc_descs(-1, 0, MAX8925_NR_IRQS, 0);
+ if (chip->irq_base < 0) {
+ dev_err(chip->dev, "Failed to allocate interrupts, ret:%d\n",
+ chip->irq_base);
+ return -EBUSY;
}
+ irq_domain_add_legacy(node, MAX8925_NR_IRQS, chip->irq_base, 0,
+ _irq_domain_ops, chip);
+ chip->core_irq = irq;
+ if (!chip->core_irq)
+ return -EBUSY;
+
ret = request_threaded_irq(irq, NULL, max8925_irq, flags,
"max8925", chip);
if (ret) {
dev_err(chip->dev, "Failed to request core IRQ: %d\n", ret);
chip->core_irq = 0;
+ return -EBUSY;
}
-tsc_irq:
+ /* domain2: init touch irq domain*/
/* mask TSC interrupt */
max8925_reg_write(chip->adc, MAX8925_TSC_IRQ_MASK, 0x0f);
- if (!pdata->tsc_irq) {
+ chip->tsc_irq_base = irq_alloc_descs(-1, 0, MAX8925_NR_TSC_IRQS, 0);
+ if (chip->tsc_irq < 0) {
+ dev_err(chip->dev, "Failed to allocate interrupts, ret:%d\n",
+ chip->tsc_irq_base);
+ return -EBUSY;
+ }
+
+ irq_domain_add_legacy(node, MAX8925_NR_TSC_IRQS, chip->tsc_irq_base, 0,
+ _irq_domain_ops, chip);
+
+ tsc_irq = irq_of_parse_and_map(node, 1);
+
+ if (!tsc_irq) {
dev_warn(chip->dev, "No interrupt support on TSC IRQ\n");
return 0;
}
- chip->tsc_irq = pdata->tsc_irq;
-
- ret = request_threaded_irq(chip->tsc_irq, NULL, max8925_tsc_irq,
+ chip->tsc_irq = tsc_irq;
+ ret = request_threaded_irq(tsc_irq, NULL, max8925_tsc_irq,
flags, "max8925-tsc", chip);
if (ret) {
[PATCH 2/7] mfd: max8925: fix mfd device register failure
From: Qing Xu
we encounter rtc/power/touch driver registry failure, root cause
it is resources confilict in insert_resouce, solved by changing
mfd_add_devices 5th parameter to NULL
Signed-off-by: Qing Xu
---
drivers/mfd/max8925-core.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index dcc218a..b1eacae 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -873,7 +873,7 @@ int __devinit max8925_device_init(struct max8925_chip *chip,
ret = mfd_add_devices(chip->dev, 0, _devs[0],
ARRAY_SIZE(rtc_devs),
- _resources[0], chip->irq_base, NULL);
+ NULL, chip->irq_base, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add rtc subdev\n");
goto out;
@@ -881,7 +881,7 @@ int __devinit max8925_device_init(struct max8925_chip *chip,
ret = mfd_add_devices(chip->dev, 0, _devs[0],
ARRAY_SIZE(onkey_devs),
- _resources[0], 0, NULL);
+ NULL, 0, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add onkey subdev\n");
goto out_dev;
@@ -900,21 +900,19 @@ int __devinit max8925_device_init(struct max8925_chip
*chip,
goto out_dev;
}
- if (pdata && pdata->power) {
- ret = mfd_add_devices(chip->dev, 0, _devs[0],
- ARRAY_SIZE(power_devs),
- _supply_resources[0], 0, NULL);
- if (ret < 0) {
- dev_err(chip->dev, "Failed to add power supply "
- "subdev\n");
- goto out_dev;
- }
+ ret = mfd_add_devices(chip->dev, 0, _devs[0],
+ ARRAY_SIZE(power_devs),
+ NULL, 0, NULL);
+ if (ret < 0) {
+ dev_err(chip->dev, "Failed to add power supply "
+ "subdev, err = %d\n", ret);
+ goto out_dev;
}
if (pdata && pdata->touch) {
ret = mfd_add_devices(chip->dev, 0, _devs[0],
ARRAY_SIZE(touch_devs),
- _resources[0], 0, NULL);
+ NULL, chip->tsc_irq_base, NULL);
if (ret < 0) {
dev_err(chip->dev, "Failed to add touch subdev\n");
goto out_dev;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NULL pointer dereference at fat_detach
2012/10/31, OGAWA Hirofumi : > Paul Bolle writes: > >> On Wed, 2012-10-31 at 09:49 +0900, OGAWA Hirofumi wrote: >>> This bug is known as the inotify bug. I recall I talked about this, >>> maybe years ago. >> >> Would that be this thread: https://lkml.org/lkml/2011/6/10/155 ? > > Sure, exactly. I found related patch. http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=fe9b25d3ee6bdf6f9c9a9ce61d9d3e144bac13ef Maybe the above patch should be applied to fix this issue in stable kernel. Thanks. > -- > OGAWA Hirofumi > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] mfd: update on max8925 for DT support
From: Qing Xu 1. add irqdomain for max8925, it is necessary for dt support 2. bug fix in max8925 mfd devices'irq base and device registry failure 3. support DT for max8925 mfd devices Qing Xu (7): mfd: max8925: add irqdomain for dt mfd: max8925: fix mfd device register failure mfd: max8925: fix onkey driver irq base mfd: max8925: support dt for power supply mfd: max8925: support dt for regulator mfd: max8925: support dt for backlight mfd: max8925: add dts arch/arm/boot/dts/mmp2-brownstone.dts | 166 + arch/arm/boot/dts/mmp2.dtsi |4 +- drivers/input/misc/max8925_onkey.c|3 - drivers/mfd/max8925-core.c| 107 + drivers/mfd/max8925-i2c.c | 32 ++- drivers/power/max8925_power.c | 57 ++- drivers/regulator/max8925-regulator.c | 35 +++- drivers/video/backlight/max8925_bl.c | 31 ++- include/linux/mfd/max8925.h | 12 ++- 9 files changed, 389 insertions(+), 58 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
At Tue, 6 Nov 2012 15:16:43 +0800,
Ming Lei wrote:
>
> On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai wrote:
> >
> > Yeah, it's just uncovered in the patch. As a easy solution, apply the
> > patch like below to disallow the udev fw loading when signature check
> > is enforced.
> >
> >
> > thanks,
> >
> > Takashi
> >
> > ---
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index 575bc4c..93121c3 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv
> > *fw_priv, bool uevent,
> > goto handle_fw;
> > }
> >
> > + /* signature check isn't handled via udev fw loading */
> > + if (sig_enforce) {
> > + fw_load_abort(fw_priv);
> > + direct_load = 1;
> > + goto handle_fw;
> > + }
> > +
>
> The above might be wrong if the firmware file doesn't exist in default
> search paths.
Heh, I didn't call it's a perfect patch. It's just an easy solution,
as mentioned.
> You should skip loading from user space only if
> verify_signature() returns false. And the udev loading should be
> resorted to if there is no such firmware file in default search paths.
... and the kernel should ask udev again for the corresponding
signature. I'm too lazy to implement that just for unknown corner
cases, so put the patch like above.
Honestly speaking, I have a feeling that we should rather go for
getting rid of udev fw loading. The fw loader code is overly complex
just for udev handshaking.
Do you know how many firmwares still rely on udev...?
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
On Tue, Nov 6, 2012 at 1:36 PM, Li Joey wrote:
> The udev direct write firmware through data attribute, maybe we can do the
> same signature verification in firmware_data_write? The following patch
> didn't test yet.
> @@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file *filp,
> struct kobject *kobj,
> }
>
> buf->size = max_t(size_t, offset, buf->size);
> +
> +#ifdef CONFIG_FIRMWARE_SIG
> + for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
> + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i],
> buf->fw_id);
> + if (verify_signature(buf, path))
> + success = true;
> + }
When direct loading failed, it means that the firmware isn't
under the default search path, so the above verification
might return false always.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/16] mm: use vm_unmapped_area() on sparc32 architecture
On 11/05/2012 08:25 PM, David Miller wrote: From: Michel Lespinasse Date: Mon, 5 Nov 2012 14:47:12 -0800 Update the sparc32 arch_get_unmapped_area function to make use of vm_unmapped_area() instead of implementing a brute force search. Signed-off-by: Michel Lespinasse Hmmm... - if (flags & MAP_SHARED) - addr = COLOUR_ALIGN(addr); - else - addr = PAGE_ALIGN(addr); What part of vm_unmapped_area() is going to duplicate this special aligning logic we need on sparc? That would be this part: +found: + /* We found a suitable gap. Clip it with the original low_limit. */ + if (gap_start < info->low_limit) + gap_start = info->low_limit; + + /* Adjust gap address to the desired alignment */ + gap_start += (info->align_offset - gap_start) & info->align_mask; + + VM_BUG_ON(gap_start + info->length > info->high_limit); + VM_BUG_ON(gap_start + info->length > gap_end); + return gap_start; +} -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 5/5] Thermal: Add ST-Ericsson DB8500 thermal properties and platform data.
On 31 October 2012 10:18, viresh kumar wrote: > On Tue, Oct 30, 2012 at 10:19 PM, hongbo.zhang > wrote: >> From: "hongbo.zhang" > > Just a minor comment below. > >> This patch adds device tree properties for ST-Ericsson DB8500 thermal driver, >> also adds the platform data to support the old fashion. >> >> Signed-off-by: hongbo.zhang > > Reviewed-by: Viresh Kumar > >> --- >> arch/arm/boot/dts/dbx5x0.dtsi | 14 + >> arch/arm/boot/dts/snowball.dts | 31 ++ >> arch/arm/configs/u8500_defconfig | 4 +++ >> arch/arm/mach-ux500/board-mop500.c | 64 >> ++ >> 4 files changed, 113 insertions(+) > >> diff --git a/arch/arm/configs/u8500_defconfig >> b/arch/arm/configs/u8500_defconfig >> index cc5e7a8..34918c4 100644 >> --- a/arch/arm/configs/u8500_defconfig >> +++ b/arch/arm/configs/u8500_defconfig >> @@ -118,3 +118,7 @@ CONFIG_DEBUG_KERNEL=y >> CONFIG_DEBUG_INFO=y >> # CONFIG_FTRACE is not set >> CONFIG_DEBUG_USER=y >> +CONFIG_THERMAL=y >> +CONFIG_CPU_THERMAL=y >> +CONFIG_DB8500_THERMAL=y >> +CONFIG_DB8500_CPUFREQ_COOLING=y > > Have you entered these manually?? Or used make savedefconfig? Yes these are added manually, make savedefconfig should be better, but it seems the original defconfig file are not well generated by savedefconfig, this file will be changed too much if I use make savedefconfig. If this is an issue, I will inform the maintainer to update this. After consideration, for this time, I will use savedefconfig to find right places for my configs, discarding the other dis-order ones. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai wrote:
>
> Yeah, it's just uncovered in the patch. As a easy solution, apply the
> patch like below to disallow the udev fw loading when signature check
> is enforced.
>
>
> thanks,
>
> Takashi
>
> ---
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 575bc4c..93121c3 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv
> *fw_priv, bool uevent,
> goto handle_fw;
> }
>
> + /* signature check isn't handled via udev fw loading */
> + if (sig_enforce) {
> + fw_load_abort(fw_priv);
> + direct_load = 1;
> + goto handle_fw;
> + }
> +
The above might be wrong if the firmware file doesn't exist in default
search paths. You should skip loading from user space only if
verify_signature() returns false. And the udev loading should be
resorted to if there is no such firmware file in default search paths.
> /* fall back on userspace loading */
> buf->fmt = PAGE_BUF;
>
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH]cputime: make bool type for steal ticks
Signed-off-by: liguang --- kernel/sched/cputime.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index 81b763b..d2c24c1 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -282,7 +282,7 @@ static __always_inline bool steal_account_process_tick(void) this_rq()->prev_steal_time += st * TICK_NSEC; account_steal_time(st); - return st; + return !!st; } #endif return false; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 068/104] drivers/pcmcia: remove depends on CONFIG_EXPERIMENTAL
On Tue, Nov 6, 2012 at 7:04 AM, Kees Cook wrote: > The CONFIG_EXPERIMENTAL config item has not carried much meaning for a > while now and is almost always enabled by default. As agreed during the > Linux kernel summit, remove it from any "depends on" lines in Kconfigs. > > CC: Russell King > CC: Manuel Lauss > CC: Dominik Brodowski > CC: Ralf Baechle > CC: Haojian Zhuang > Signed-off-by: Kees Cook > --- > drivers/pcmcia/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig > index 8fd255f..b90f85b 100644 > --- a/drivers/pcmcia/Kconfig > +++ b/drivers/pcmcia/Kconfig > @@ -36,8 +36,8 @@ config PCMCIA >If unsure, say Y. > > config PCMCIA_LOAD_CIS > - bool "Load CIS updates from userspace (EXPERIMENTAL)" > - depends on PCMCIA && EXPERIMENTAL > + bool "Load CIS updates from userspace" > + depends on PCMCIA > select FW_LOADER > default y > help > -- > 1.7.9.5 > Acked-by: Haojian Zhuang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
At Tue, 6 Nov 2012 13:36:46 +0800,
Li Joey wrote:
>
> [1 ]
> 2012/11/6 Ming Lei
>
> > On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai wrote:
> > >
> > > To be noted, it doesn't support the firmwares via udev but only the
> > > direct loading, and the check for built-in firmware is missing, too.
> >
> > Generally, both direct loading and udev may request one same firmware
> > image. And after check failed, current firmware load will fallback on udev
> > to complete loading, so looks a check-failed firmware still can be loaded
> > into kernel no matter if there is firmware signature check or not.
> >
> >
> > Thanks,
> > --
> > Ming Lei
>
>
> The udev direct write firmware through data attribute, maybe we can do the
> same signature verification in firmware_data_write? The following patch
> didn't test yet.
This would work in theory. But in practice, when the direct file
loading fails and falls back to udev, it means that the firmware is no
file but generated somehow dynamically. If so, a static signature
won't help, I'm afraid.
thanks,
Takashi
>
>
> Thanks
> Joey Lee
>
> >From 035dde5fadc9e7f4b7811b18d3a5094ef88e8bbb Mon Sep 17 00:00:00 2001
> From: Lee, Chun-Yi
> Date: Tue, 6 Nov 2012 13:07:04 +0800
> Subject: [PATCH] firmware: Add signature check to firmware_data_write
>
> ---
> drivers/base/firmware_class.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 8945f4e..40d8cc6 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -621,6 +621,7 @@ static ssize_t firmware_data_write(struct file *filp,
> struct kobject *kobj,
> struct firmware_priv *fw_priv = to_firmware_priv(dev);
> struct firmware_buf *buf;
> ssize_t retval;
> + bool success = false;
>
> if (!capable(CAP_SYS_RAWIO))
> return -EPERM;
> @@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file *filp,
> struct kobject *kobj,
> }
>
> buf->size = max_t(size_t, offset, buf->size);
> +
> +#ifdef CONFIG_FIRMWARE_SIG
> + for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
> + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i],
> buf->fw_id);
> + if (verify_signature(buf, path))
> + success = true;
> + }
> + if (!success) {
> + pr_err("Invalid signature file %s\n", path);
> + if (sig_enforce) {
> + vfree(buf->data);
> + buf->data = NULL;
> + buf->size = 0;
> + }
> + retval = -ENOENT;
> + }
> +#endif /* CONFIG_FIRMWARE_SIG */
> out:
> mutex_unlock(_lock);
> return retval;
> --
> 1.6.4.2
> [2 ]
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: PINCTRL_SAMSUNG and PINCTRL_EXYNOS4 need to depend on OF && GPIOLIB
This patch fixes below build error when !CONFIG_OF_GPIO. CC drivers/pinctrl/pinctrl-samsung.o drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_pinctrl_parse_dt_pins': drivers/pinctrl/pinctrl-samsung.c:557:19: warning: unused variable 'prop' [-Wunused-variable] drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_gpiolib_register': drivers/pinctrl/pinctrl-samsung.c:797:5: error: 'struct gpio_chip' has no member named 'of_node' make[2]: *** [drivers/pinctrl/pinctrl-samsung.o] Error 1 make[1]: *** [drivers/pinctrl] Error 2 make: *** [drivers] Error 2 The samsung pinctrl driver supports only device tree enabled platforms. Thus make PINCTRL_SAMSUNG depend on OF && GPIOLIB. The reason to depend on GPIOLIB is CONFIG_OF_GPIO only available when GPIOLIB is selected. Since PINCTRL_EXYNOS4 select PINCTRL_SAMSUNG, thus also make PINCTRL_EXYNOS4 depend on OF && GPIOLIB. Signed-off-by: Axel Lin --- Hi Thomas, If I simply add "select OF_GPIO" for PINCTRL_SAMSUNG, I got below build warning: warning: (PINCTRL_SAMSUNG) selects OF_GPIO which has unmet direct dependencies (GPIOLIB && OF && !SPARC) So I make PINCTRL_SAMSUNG depend on OF && GPIOLIB. Regards, Axel drivers/pinctrl/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 6777a4c..6d5a50b 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -188,11 +188,13 @@ config PINCTRL_COH901 config PINCTRL_SAMSUNG bool "Samsung pinctrl driver" + depends on OF && GPIOLIB select PINMUX select PINCONF config PINCTRL_EXYNOS4 bool "Pinctrl driver data for Exynos4 SoC" + depends on OF && GPIOLIB select PINCTRL_SAMSUNG source "drivers/pinctrl/mvebu/Kconfig" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
At Tue, 6 Nov 2012 10:30:26 +0800,
Ming Lei wrote:
>
> On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai wrote:
> >
> > To be noted, it doesn't support the firmwares via udev but only the
> > direct loading, and the check for built-in firmware is missing, too.
>
> Generally, both direct loading and udev may request one same firmware
> image. And after check failed, current firmware load will fallback on udev
> to complete loading, so looks a check-failed firmware still can be loaded
> into kernel no matter if there is firmware signature check or not.
Yeah, it's just uncovered in the patch. As a easy solution, apply the
patch like below to disallow the udev fw loading when signature check
is enforced.
thanks,
Takashi
---
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 575bc4c..93121c3 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv
*fw_priv, bool uevent,
goto handle_fw;
}
+ /* signature check isn't handled via udev fw loading */
+ if (sig_enforce) {
+ fw_load_abort(fw_priv);
+ direct_load = 1;
+ goto handle_fw;
+ }
+
/* fall back on userspace loading */
buf->fmt = PAGE_BUF;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
At Tue, 06 Nov 2012 00:01:52 +, David Howells wrote: > > Takashi Iwai wrote: > > > this is a patch series to add the support for firmware signature > > check. At this time, the kernel checks extra signature file (*.sig) > > for each firmware, instead of embedded signature. > > It's just a quick hack using the existing module signing mechanism, > > thus provided only as a proof of concept for now. > > There is another way to do this. If you look at the patches I proposed to > wrap keys in PE binaries, you'll find that that can handle PKCS#7 format > messages as that's what's in the sort of signed PE binary we're dealing with. > > You could use this to put the firmware inside a signed-data PKCS#7 message. Yeah, embedding the signature is more straightforward. Actually I tried the embedded signature (just like module) at first, then a couple of concerns arose: - Legally unclear about "modifying" the firmware data or file, - The signed firmware is no longer compatible with the older kernel, thus bad for distro packaging. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 8/8] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
On Mon, Nov 05, 2012 at 14:42:29, Philip, Avinash wrote:
[...]
> + am33xx_pinmux: pinmux@44e10800 {
> + ecap0_pins: backlight_pins {
> + pinctrl-single,pins = <
> + 0x164 0x0 /*
> eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> + >;
> + };
> + };
> +
Ok I see the pinctrl entries here. Shouldn't this be done before
the change in the driver?
Regards.
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/8] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
On Mon, Nov 05, 2012 at 14:42:26, Philip, Avinash wrote:
[...]
> +#include
> +#include
Pinctrl changes should be separate patch. Morevoer, you don't mention
that you making this change.
> +
> +#include "tipwmss.h"
>
> /* EHRPWM registers and bits definitions */
>
> @@ -107,6 +111,10 @@
> #define AQCSFRC_CSFA_FRCHIGH BIT(1)
> #define AQCSFRC_CSFA_DISSWFRC(BIT(1) | BIT(0))
>
> +#define EPWMCLK_EN_SHIFT 8
> +
> +#define PWM_CELL_SIZE3
> +
> #define NUM_PWM_CHANNEL 2 /* EHRPWM channels */
>
> struct ehrpwm_pwm_chip {
> @@ -392,12 +400,27 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
> .owner = THIS_MODULE,
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id ehrpwm_of_match[] = {
> + {
> + .compatible = "ti,am33xx-ehrpwm",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
> +#endif
> +
> static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
> {
> int ret;
> struct resource *r;
> struct clk *clk;
> struct ehrpwm_pwm_chip *pc;
> + struct pinctrl *pinctrl;
> +
> + pinctrl = devm_pinctrl_get_select_default(>dev);
I didn't see a patch adding the pinctrl entries.
> + if (IS_ERR(pinctrl))
> + dev_warn(>dev, "failed to configure pins from driver\n");
>
> pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
> if (!pc) {
> @@ -419,6 +442,7 @@ static int __devinit ehrpwm_pwm_probe(struct
> platform_device *pdev)
>
> pc->chip.dev = >dev;
> pc->chip.ops = _pwm_ops;
> + pc->chip.of_pwm_n_cells = PWM_CELL_SIZE;
> pc->chip.base = -1;
> pc->chip.npwm = NUM_PWM_CHANNEL;
>
> @@ -437,8 +461,11 @@ static int __devinit ehrpwm_pwm_probe(struct
> platform_device *pdev)
> dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
> return ret;
> }
> -
> pm_runtime_enable(>dev);
> + pm_runtime_get_sync(>dev);
> + pwmss_submodule_state_change(pdev->dev.parent, EPWMCLK_EN_SHIFT, true);
I think you should modify this API to return the status for drivers to check.
Another related question, why should this clock be enabled in probe and not
only when it
is required? Shouldn't it be disabled in suspend?
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/8] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
On Mon, Nov 05, 2012 at 14:42:27, Philip, Avinash wrote:
[...]
> + /* Some platforms require explicit tbclk gating */
> + if (of_property_read_bool(pdev->dev.of_node, "tbclkgating")) {
> + pc->tbclk = clk_get(>dev, "tbclk");
> + if (IS_ERR(pc->tbclk)) {
> + dev_err(>dev, "Could not get EHRPWM TBCLK\n");
> + return PTR_ERR(pc->tbclk);
> + }
> + }
> +
> + /* Enable tbclk & leave */
> + if (pc->tbclk)
> + clk_enable(pc->tbclk);
> +
Here also why are you leaving this clock always running?
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
At Mon, 5 Nov 2012 15:43:09 -0500, Josh Boyer wrote: > > On Mon, Nov 5, 2012 at 12:18 PM, Takashi Iwai wrote: > > Hi, > > > > this is a patch series to add the support for firmware signature > > check. At this time, the kernel checks extra signature file (*.sig) > > for each firmware, instead of embedded signature. > > It's just a quick hack using the existing module signing mechanism, > > thus provided only as a proof of concept for now. > > > > To be noted, it doesn't support the firmwares via udev but only the > > direct loading, and the check for built-in firmware is missing, too. > > Just to make sure I'm reading this correctly, it will sign any of the > firwmare files installed directly from the kernel tree if the option is > set. So for the firmware in the linux-firmware tree we'd need to > either copy that into the kernel tree during build time, or duplicate the > signing bits in the linux-firmware tree itself. However if we do the > latter, we'd probably need to use the same keys as the per-build kernel > key which means copying keys (ew) or tell the kernel to include a > separate firmware key in the extra list. Yes, the situation is as same as the external module builds. > I feel like I'm rambling a bit, but I'm trying to work out how signed > firmware would look from a distro perspective. A significant amount of > work has been done to decouple linux-firmware from the kernel tree and > if signed firmware is used it seems to couple them together one way or > another. Well, the primary question is whether the firmware signature check is required or not. Of course, these patches assume that it is for secure boot lockdown :) > At the moment, using generated per-build keys to come up with > the firmware signatures seems a bit suboptimal in that regard. But how would distro sign modules that are built externally? It should be the pretty same situation. I thought that the current module signing is already supported (at least accepted) by distro, even for external modules. Isn't it? thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm-backlight: Add support for active low PWM backlights
On Mon, Nov 05, 2012 at 04:49:01PM +0100, Alban Bedel wrote: > Signed-off-by: Alban Bedel > --- > .../bindings/video/backlight/pwm-backlight.txt |1 + > drivers/video/backlight/pwm_bl.c | 22 ++- > include/linux/pwm_backlight.h |1 + > 3 files changed, 18 insertions(+), 6 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt > b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt > index 1e4fc72..3a40539 100644 > --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt > +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt > @@ -14,6 +14,7 @@ Required properties: > Optional properties: >- pwm-names: a list of names for the PWM devices specified in the > "pwms" property (see PWM binding[0]) > + - active-low: boolean indicating that the backlight use active low logic Couldn't you use the brightness-levels property to achieve the same effect? Thierry pgpjkCZ4Ulmpy.pgp Description: PGP signature
[PATCH V3 5/7] perf, core: Pass perf_sample_data to perf_callchain()
From: "Yan, Zheng"
New Intel CPU can record call chains by using existing last branch
record facility. perf_callchain_user() can make use of the call
chains recorded by hardware in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/arm/kernel/perf_event.c | 4 ++--
arch/powerpc/perf/callchain.c| 4 ++--
arch/sparc/kernel/perf_event.c | 4 ++--
arch/x86/kernel/cpu/perf_event.c | 4 ++--
include/linux/perf_event.h | 3 ++-
kernel/events/callchain.c| 8 +---
kernel/events/core.c | 2 +-
kernel/events/internal.h | 3 ++-
8 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 93971b1..7cd3eba 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -567,8 +567,8 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp - 1;
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct frame_tail __user *tail;
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 74d1e78..b379ebc 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -482,8 +482,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
}
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
if (current_is_64bit())
perf_callchain_user_64(entry, regs);
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index 885a8af..6e9c62c 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1775,8 +1775,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
} while (entry->nr < PERF_MAX_STACK_DEPTH);
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
perf_callchain_store(entry, regs->tpc);
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index c6a133f..0fec97d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1982,8 +1982,8 @@ perf_callchain_user32(struct pt_regs *regs, struct
perf_callchain_entry *entry)
}
#endif
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct stack_frame frame;
const void __user *fp;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f130c6c..fdf0019 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -706,7 +706,8 @@ extern void perf_event_fork(struct task_struct *tsk);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
-extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs);
+extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs,
+ struct perf_sample_data *data);
extern void perf_callchain_kernel(struct perf_callchain_entry *entry, struct
pt_regs *regs);
static inline void perf_callchain_store(struct perf_callchain_entry *entry,
u64 ip)
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c772061..bd7138a 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -30,7 +30,8 @@ __weak void perf_callchain_kernel(struct perf_callchain_entry
*entry,
}
__weak void perf_callchain_user(struct perf_callchain_entry *entry,
- struct pt_regs *regs)
+ struct pt_regs *regs,
+ struct perf_sample_data *data)
{
}
@@ -154,7 +155,8 @@ put_callchain_entry(int rctx)
}
struct perf_callchain_entry *
-perf_callchain(struct perf_event *event, struct pt_regs *regs)
+perf_callchain(struct perf_event *event, struct pt_regs *regs,
+ struct perf_sample_data *data)
{
int rctx;
struct perf_callchain_entry *entry;
@@ -195,7 +197,7 @@ perf_callchain(struct perf_event *event, struct pt_regs
*regs)
goto exit_put;
perf_callchain_store(entry, PERF_CONTEXT_USER);
- perf_callchain_user(entry, regs);
+ perf_callchain_user(entry, regs, data);
}
}
diff --git a/kernel/events/core.c
[PATCH V3 7/7] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
Zero length call is also referred to as zero displacement call.
It is usually used in 32-bit code to get address of next
instruction. The assembly code looks like:
callnext_ip
next_ip:
popl%ebx
Zero length calls may confuse the hardware and make the recorded
call stack incorrect. Try fixing the call stack by discarding
zero length call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 910200b..0546689 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -86,7 +86,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -103,13 +104,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -625,6 +628,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate();
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 6/7] perf, x86: Use LBR call stack to get user callchain
From: "Yan, Zheng"
Enable the LBR call stack feature if user requests recording
usr callchain. kernel can use the hardware feature to get
user callchain in case there is no frame pointer.
This patch also adds a file named "lbr_callstack" to the sysfs
directory of cpu pmu. User can disable/enable the call stack
feature by writing 0/1 to the file.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 126 +
arch/x86/kernel/cpu/perf_event.h | 7 ++
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 +
include/linux/perf_event.h | 6 ++
kernel/events/core.c | 11 ++-
6 files changed, 125 insertions(+), 48 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 0fec97d..b24fe4b 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -400,36 +400,49 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
+ }
+ /*
+* check that PEBS LBR correction does not conflict with
+* whatever the user is asking with attr->branch_sample_type
+*/
+ if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format < 2) {
+ u64 *br_type = >attr.branch_sample_type;
+
+ if (has_branch_stack(event)) {
+ if (!precise_br_compat(event))
+ return -EOPNOTSUPP;
+
+ /* branch_sample_type is compatible */
+
+ } else {
+ /*
+* user did not specify branch_sample_type
+*
+* For PEBS fixups, we capture all
+* the branches at the priv level of the
+* event.
+*/
+ *br_type = PERF_SAMPLE_BRANCH_ANY;
+
+ if (!event->attr.exclude_user)
+ *br_type |= PERF_SAMPLE_BRANCH_USER;
+
+ if (!event->attr.exclude_kernel)
+ *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
+ }
+ } else if ((event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) &&
+ !has_branch_stack(event) &&
+ x86_pmu.attr_lbr_callstack &&
+ !event->attr.exclude_user &&
+ (event->attach_state & PERF_ATTACH_TASK)) {
/*
-* check that PEBS LBR correction does not conflict with
-* whatever the user is asking with attr->branch_sample_type
+* user did not specify branch_sample_type,
+* try using the LBR call stack facility to
+* record call chains of user program.
*/
- if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format
< 2) {
- u64 *br_type = >attr.branch_sample_type;
-
- if (has_branch_stack(event)) {
- if (!precise_br_compat(event))
- return -EOPNOTSUPP;
-
- /* branch_sample_type is compatible */
-
- } else {
- /*
-* user did not specify branch_sample_type
-*
-* For PEBS fixups, we capture all
-* the branches at the priv level of the
-* event.
-*/
- *br_type = PERF_SAMPLE_BRANCH_ANY;
-
- if (!event->attr.exclude_user)
- *br_type |= PERF_SAMPLE_BRANCH_USER;
-
- if (!event->attr.exclude_kernel)
- *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
- }
- }
+ event->attr.branch_sample_type =
+ PERF_SAMPLE_BRANCH_USER |
+ PERF_SAMPLE_BRANCH_CALL_STACK;
}
/*
@@ -1806,12 +1819,35 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+static ssize_t get_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, 40, "%d\n", x86_pmu.attr_lbr_callstack);
+}
+
+static ssize_t set_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long val = simple_strtoul(buf, NULL, 0);
+
+ if (x86_pmu.attr_lbr_callstack != !!val) {
+ if (val
[PATCH V3 3/7] perf, x86: Introduce x86 special perf event context
From: "Yan, Zheng"
The x86 special perf event context is named x86_perf_event_context,
We can enlarge it later to store PMU special data.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 12
arch/x86/kernel/cpu/perf_event.h | 4
include/linux/perf_event.h | 5 +
kernel/events/core.c | 28 ++--
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index e247423..2069f4b 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1749,6 +1749,17 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
+{
+ struct perf_event_context *ctx;
+
+ ctx = kzalloc(sizeof(struct x86_perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static ssize_t get_attr_rdpmc(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -1838,6 +1849,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.flush_branch_stack = x86_pmu_flush_branch_stack,
+ .event_context_alloc= x86_pmu_event_context_alloc,
};
void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 8d7e19f..cdeb028 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -421,6 +421,10 @@ enum {
PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
+struct x86_perf_event_context {
+ struct perf_event_context ctx;
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index c32fba3..6122b2f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -264,6 +264,11 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Allocate PMU special perf event context
+*/
+ void *(*event_context_alloc)(struct perf_event_context *parent_ctx);
};
/**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 534810d..c886018 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2721,13 +2721,20 @@ static void __perf_event_init_context(struct
perf_event_context *ctx)
}
static struct perf_event_context *
-alloc_perf_context(struct pmu *pmu, struct task_struct *task)
+alloc_perf_context(struct pmu *pmu, struct task_struct *task,
+ struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
- ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
- if (!ctx)
- return NULL;
+ if (pmu->event_context_alloc) {
+ ctx = pmu->event_context_alloc(parent_ctx);
+ if (IS_ERR(ctx))
+ return ctx;
+ } else {
+ ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ }
__perf_event_init_context(ctx);
if (task) {
@@ -2813,10 +2820,11 @@ retry:
++ctx->pin_count;
raw_spin_unlock_irqrestore(>lock, flags);
} else {
- ctx = alloc_perf_context(pmu, task);
- err = -ENOMEM;
- if (!ctx)
+ ctx = alloc_perf_context(pmu, task, NULL);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
goto errout;
+ }
err = 0;
mutex_lock(>perf_event_mutex);
@@ -7132,9 +7140,9 @@ inherit_task_group(struct perf_event *event, struct
task_struct *parent,
* child.
*/
- child_ctx = alloc_perf_context(event->pmu, child);
- if (!child_ctx)
- return -ENOMEM;
+ child_ctx = alloc_perf_context(event->pmu, child, parent_ctx);
+ if (IS_ERR(child_ctx))
+ return PTR_ERR(child_ctx);
child->perf_event_ctxp[ctxn] = child_ctx;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 4/7] perf, x86: Save/resotre LBR stack during context switch
From: "Yan, Zheng"
When the LBR call stack is enabled, it is necessary to save/restore
the stack on context switch. The solution is saving/restoring the
stack to/from task's perf event context. If task has no perf event
context, just flush the stack on context switch.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 18 +++--
arch/x86/kernel/cpu/perf_event.h | 13 +++-
arch/x86/kernel/cpu/perf_event_intel.c | 13 ++--
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 108 ++---
include/linux/perf_event.h | 6 +-
kernel/events/core.c | 64 ++---
6 files changed, 168 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 2069f4b..c6a133f 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1749,6 +1749,13 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void x86_pmu_branch_stack_sched(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ if (x86_pmu.branch_stack_sched)
+ x86_pmu.branch_stack_sched(ctx, sched_in);
+}
+
static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
@@ -1757,6 +1764,9 @@ static void *x86_pmu_event_context_alloc(struct
perf_event_context *parent_ctx)
if (!ctx)
return ERR_PTR(-ENOMEM);
+ if (parent_ctx)
+ intel_pmu_lbr_init_context(ctx, parent_ctx);
+
return ctx;
}
@@ -1816,12 +1826,6 @@ static const struct attribute_group
*x86_pmu_attr_groups[] = {
NULL,
};
-static void x86_pmu_flush_branch_stack(void)
-{
- if (x86_pmu.flush_branch_stack)
- x86_pmu.flush_branch_stack();
-}
-
void perf_check_microcode(void)
{
if (x86_pmu.check_microcode)
@@ -1848,7 +1852,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
.event_idx = x86_pmu_event_idx,
- .flush_branch_stack = x86_pmu_flush_branch_stack,
+ .branch_stack_sched = x86_pmu_branch_stack_sched,
.event_context_alloc= x86_pmu_event_context_alloc,
};
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index cdeb028..35dc398 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -371,7 +371,6 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
void(*check_microcode)(void);
- void(*flush_branch_stack)(void);
/*
* Intel Arch Perfmon v2+
@@ -401,6 +400,8 @@ struct x86_pmu {
int lbr_nr;/* hardware stack size */
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
const int *lbr_sel_map; /* lbr_select mappings */
+ void(*branch_stack_sched)(struct perf_event_context *ctx,
+ bool sched_in);
/*
* Extra registers for events
@@ -423,6 +424,12 @@ enum {
struct x86_perf_event_context {
struct perf_event_context ctx;
+
+ u64 lbr_from[MAX_LBR_ENTRIES];
+ u64 lbr_to[MAX_LBR_ENTRIES];
+ u64 lbr_stack_gen;
+ int lbr_callstack_users;
+ bool lbr_stack_saved;
};
#define x86_add_quirk(func_) \
@@ -650,8 +657,12 @@ void intel_pmu_pebs_disable_all(void);
void intel_ds_init(void);
+void intel_pmu_lbr_init_context(struct perf_event_context *child_ctx,
+ struct perf_event_context *parent_ctx);
void intel_pmu_lbr_reset(void);
+void intel_pmu_lbr_sched(struct perf_event_context *ctx, bool sched_in);
+
void intel_pmu_lbr_enable(struct perf_event *event);
void intel_pmu_lbr_disable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index f9aac2e..05f7999 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1813,16 +1813,11 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
}
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_branch_stack_sched(struct perf_event_context *ctx,
+bool sched_in)
{
- /*
-* Intel LBR does not tag entries with the
-* PID of the current task, then we need to
-* flush it on ctxsw
-* For now, we simply reset it
-*/
if (x86_pmu.lbr_nr)
- intel_pmu_lbr_reset();
+ intel_pmu_lbr_sched(ctx, sched_in);
}
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1888,7 +1883,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting =
[PATCH V3 2/7] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 7 ++-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89 ++
include/uapi/linux/perf_event.h| 2 +-
4 files changed, 75 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 14d302c..8d7e19f 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -415,7 +415,10 @@ struct x86_pmu {
};
enum {
- PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
+
+ PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
#define x86_add_quirk(func_) \
@@ -663,6 +666,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index d177d88..f9aac2e 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2269,7 +2269,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 2bac8ac..88367a2 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -31,6 +31,7 @@ enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -41,6 +42,7 @@ enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -66,24 +68,25 @@ enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in transaction */
+
[PATCH V3 1/7] perf, x86: Reduce lbr_sel_map size
From: "Yan, Zheng"
The index of lbr_sel_map is bit value of perf branch_sample_type.
By using bit shift as index, we can reduce lbr_sel_map size.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 4 +++
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 50 ++
include/uapi/linux/perf_event.h| 42 +
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 22f8003..14d302c 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -414,6 +414,10 @@ struct x86_pmu {
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
};
+enum {
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 5455a00..2bac8ac 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -61,10 +61,6 @@ enum {
#define LBR_FROM_FLAG_INTX (1ULL << 62)
#define LBR_FROM_FLAG_ABORT(1ULL << 61)
-#define for_each_branch_sample_type(x) \
- for ((x) = PERF_SAMPLE_BRANCH_USER; \
-(x) < PERF_SAMPLE_BRANCH_MAX; (x) <<= 1)
-
/*
* x86control flow change classification
* x86control flow changes include branches, interrupts, traps, faults
@@ -378,14 +374,14 @@ static int intel_pmu_setup_hw_lbr_filter(struct
perf_event *event)
{
struct hw_perf_event_extra *reg;
u64 br_type = event->attr.branch_sample_type;
- u64 mask = 0, m;
- u64 v;
+ u64 mask = 0, v;
+ int i;
- for_each_branch_sample_type(m) {
- if (!(br_type & m))
+ for (i = 0; i < PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE; i++) {
+ if (!(br_type & (1U << i)))
continue;
- v = x86_pmu.lbr_sel_map[m];
+ v = x86_pmu.lbr_sel_map[i];
if (v == LBR_NOT_SUPP)
return -EOPNOTSUPP;
@@ -631,33 +627,33 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
/*
* Map interface branch filters onto LBR filters
*/
-static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_REL_JMP
- | LBR_IND_JMP | LBR_FAR,
+static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_REL_JMP
+ | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include REL_JMP+IND_JMP to get CALL branches
*/
- [PERF_SAMPLE_BRANCH_ANY_CALL] =
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] =
LBR_REL_CALL | LBR_IND_CALL | LBR_REL_JMP | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include IND_JMP to capture IND_CALL
*/
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL | LBR_IND_JMP,
};
-static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_FAR,
- [PERF_SAMPLE_BRANCH_ANY_CALL] = LBR_REL_CALL | LBR_IND_CALL
- | LBR_FAR,
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL,
+static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] = LBR_REL_CALL | LBR_IND_CALL
+ | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL,
};
/* core */
diff --git a/include/uapi/linux/perf_event.h
[PATCH V3 0/7] perf, x86: Haswell LBR call stack support
From: "Yan, Zheng" Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. When the feature is enabled, function call will be collected as normal, but as return instructions are executed the last captured branch record is popped from the on-chip LBR registers. The LBR call stack facility can help perf to get call chains of progam without frame pointer. The LBR call stack feature is automatic enabled when user requests sampling user callchain. perf_callchain_user() outputs the hardware recorded call stack in case there is no frame pointer in user program. The LBR call stack has following known limitations 1. Zero length calls are not filtered out by hardware 2. Exception handing such as setjmp/longjmp will have calls/returns not match 3. Pushing different return address onto the stack will have calls/returns not match The patch series depends on Andi's "perf PMU support for Haswel" patches --- Changes since v1 - not expose PERF_SAMPLE_BRANCH_CALL_STACK to user space - save/restore LBR stack on context switch for all sampling branch modes - reduce lbr_sel_map size Changes since v2 - only enable LBR call stack when user requests sampling user callchain -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/8] PWMSS: Add PWM Subsystem driver for parent<->child relationship
On Mon, Nov 05, 2012 at 14:42:22, Philip, Avinash wrote:
[...]
> +pwmss0: pwmss@4830 {
> + compatible = "ti,am33xx-pwmss";
> + reg = <0x4830 0x10
> + 0x48300100 0x80
> + 0x48300180 0x80
> + 0x48300200 0x80>;
Do you really need the 4 address ranges here? You eventually do add in
child nodes with other address ranges so isn't the first entry sufficient?
I haven't really looked at the DT details so it is enforced by that let me
know.
[...]
> +
> +#define PWMSS_CLKCONFIG 8
> +
This #def can use a comment.
> +void pwmss_submodule_state_change(struct device *dev, int pos, bool enable)
> +{
> + struct pwmss_info *info = dev_get_drvdata(dev);
> + u16 val;
> +
> + val = readw(info->mmio_base + PWMSS_CLKCONFIG);
> + if (enable)
> + val |= 1 << pos;
> + else
> + val &= ~(1 << pos);
> + mutex_lock(>pwmss_lock);
> + writew(val , info->mmio_base + PWMSS_CLKCONFIG);
> + mutex_unlock(>pwmss_lock);
> +}
> +EXPORT_SYMBOL(pwmss_submodule_state_change);
I see a clk_en_ack field in the clock status register. You should be checking
that.
[...]
> +
> +MODULE_DESCRIPTION("pwmss driver");
> +MODULE_AUTHOR("Texas Instruments");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/pwm/tipwmss.h b/drivers/pwm/tipwmss.h
> new file mode 100644
> index 000..83fdc29
> --- /dev/null
> +++ b/drivers/pwm/tipwmss.h
> @@ -0,0 +1,8 @@
License text?
> +#ifdef CONFIG_PWM_TIPWMSS
> +extern void pwmss_submodule_state_change(struct device *dev, int pos,
> + bool enable);
> +#else
> +static inline void pwmss_submodule_state_change(struct device *dev, int pos,
> + bool enable)
> +{}
> +#endif
Regards,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pkt_sched: enable QFQ to support TSO/GSO
If the max packet size for some class (configured through tc) is violated by the actual size of the packets of that class, then QFQ would not schedule classes correctly, and the data structures implementing the bucket lists may get corrupted. This problem occurs with TSO/GSO even if the max packet size is set to the MTU, and is, e.g., the cause of the failure reported in [1]. Two patches have been proposed to solve this problem in [2], one of them is a preliminary version of this patch. This patch addresses the above issues by: 1) setting QFQ parameters to proper values for supporting TSO/GSO (in particular, setting the maximum possible packet size to 64KB), 2) automatically increasing the max packet size for a class, lmax, when a packet with a larger size than the current value of lmax arrives. The drawback of the first point is that the maximum weight for a class is now limited to 4096, which is equal to 1/16 of the maximum weight sum. Finally, this patch also forcibly caps the timestamps of a class if they are too high to be stored in the bucket list. This capping, taken from QFQ+ [3], handles the unfrequent case described in the comment to the function slot_insert. [1] http://marc.info/?l=linux-netdev=134968777902077=2 [2] http://marc.info/?l=linux-netdev=135096573507936=2 [3] http://marc.info/?l=linux-netdev=134902691421670=2 Signed-off-by: Paolo Valente Tested-by: Cong Wang Acked-by: Stephen Hemminger --- net/sched/sch_qfq.c | 109 +-- 1 file changed, 79 insertions(+), 30 deletions(-) diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c index f0dd83c..9687fa1 100644 --- a/net/sched/sch_qfq.c +++ b/net/sched/sch_qfq.c @@ -84,18 +84,19 @@ * grp->index is the index of the group; and grp->slot_shift * is the shift for the corresponding (scaled) sigma_i. */ -#define QFQ_MAX_INDEX 19 -#define QFQ_MAX_WSHIFT 16 +#define QFQ_MAX_INDEX 24 +#define QFQ_MAX_WSHIFT 12 #defineQFQ_MAX_WEIGHT (1groups[i] != cl->grp && cl->qdisc->q.qlen > 0) { + /* +* shift cl->F back, to not charge the +* class for the not-yet-served head +* packet +*/ + cl->F = cl->S; + /* remove class from its slot in the old group */ + qfq_deactivate_class(q, cl); + need_reactivation = true; + } + + qfq_update_class_params(q, cl, lmax, inv_w, delta_w); + + if (need_reactivation) /* activate in new group */ + qfq_activate_class(q, cl, qdisc_peek_len(cl->qdisc)); +} + + static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, struct nlattr **tca, unsigned long *arg) { @@ -238,7 +265,7 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, struct qfq_class *cl = (struct qfq_class *)*arg; struct nlattr *tb[TCA_QFQ_MAX + 1]; u32 weight, lmax, inv_w; - int i, err; + int err; int delta_w; if (tca[TCA_OPTIONS] == NULL) { @@ -270,16 +297,14 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, if (tb[TCA_QFQ_LMAX]) { lmax = nla_get_u32(tb[TCA_QFQ_LMAX]); - if (!lmax || lmax > (1UL << QFQ_MTU_SHIFT)) { + if (lmax < QFQ_MIN_LMAX || lmax > (1UL << QFQ_MTU_SHIFT)) { pr_notice("qfq: invalid max length %u\n", lmax); return -EINVAL; } } else - lmax = 1UL << QFQ_MTU_SHIFT; + lmax = psched_mtu(qdisc_dev(sch)); if (cl != NULL) { - bool need_reactivation = false; - if (tca[TCA_RATE]) { err = gen_replace_estimator(>bstats, >rate_est, qdisc_root_sleeping_lock(sch), @@ -291,24 +316,8 @@ static int qfq_change_class(struct Qdisc *sch, u32 classid, u32 parentid, if (lmax == cl->lmax && inv_w == cl->inv_w) return 0; /* nothing to update */ - i = qfq_calc_index(inv_w, lmax); sch_tree_lock(sch); - if (>groups[i] != cl->grp && cl->qdisc->q.qlen > 0) { - /* -* shift cl->F back, to not charge the -* class for the not-yet-served head -* packet -*/ - cl->F = cl->S; - /* remove class from its slot in the old group */ -
RE: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Liu, Jinsong wrote: > Stefano Stabellini wrote: diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index 0e86370..a2af622 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG) += mcelog.o obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ obj-$(CONFIG_XEN_PRIVCMD)+= xen-privcmd.o obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o +obj-$(CONFIG_XEN_DOM0) += xen_acpi_pad.o xen-evtchn-y := evtchn.o xen-gntdev-y := gntdev.o xen-gntalloc-y := gntalloc.o >> >> it should really depend on ACPI and maybe also X86, otherwise it is >> going to break the ARM build >> >> > > Hmm, XEN_DOM0 has already depended on ACPI and X86_LOCAL_APIC (which > depends on X86_64). > Ah, you and Konrad are right. I ignore XEN_DOM0 varies under different arch. (But seems it not depends on X86 since it's logically an acpi stuff?). Thanks, Jinsong-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 103/104] mm: remove depends on CONFIG_EXPERIMENTAL
On Mon, 5 Nov 2012, Kees Cook wrote: > >>> diff --git a/mm/Kconfig b/mm/Kconfig > >>> index a3f8ddd..679945e 100644 > >>> --- a/mm/Kconfig > >>> +++ b/mm/Kconfig > >>> @@ -1,6 +1,5 @@ > >>> config SELECT_MEMORY_MODEL > >>> def_bool y > >>> - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL > >>> > >>> choice > >>> prompt "Memory model" > >> > >> I thought you agreed to only drop EXPERIMENTAL here in > >> http://marc.info/?l=linux-kernel=135103415901094 and leave > >> ARCH_SELECT_MEMORY_MODEL, which you've orphaned with the above, for phase > >> two of your effort? > > > > Ah! Yes, thanks. I'll restore that. > > Wait, no. This is an "OR". ARCH_SELECT_MEMORY_MODEL has no affect on > SELECT_MEMORY_MODEL if EXPERIMENTAL is always considered on. My > proposal was to deal with ARCH_SELECT_MEMORY_MODEL separately. Did I > misunderstand something? > We're rehashing the same discussion as before? I left the earlier thread with the understanding that this would become depends on ARCH_SELECT_MEMORY_MODEL and then fix ARCH_SELECT_MEMORY_MODEL when people complain for configurations that actually allow you to configure the memory model. It never should have been short-circuited by EXPERIMENTAL in the first place, but enabling it to be configurable for everybody and orphaning ARCH_SELECT_MEMORY_MODEL doesn't sound appropriate. I think we should do some due diligence in actually making ARCH_SELECT_MEMORY_MODEL work so people are presented with a config that will work on their machines. (This is independent of the rest of the series, we can certainly remove EXPERIMENTAL regardless of this decision, I simply think we should be leaving ARCH_SELECT_MEMORY_MODEL to prevent users with CONFIG_EXPERIMENTAL=n from being presented with a new ability to change their memory model that actually doesn't work for them.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Xen-devel] [PATCH 1/2] Xen acpi pad implement
Stefano Stabellini wrote:
>>> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
>>> index 0e86370..a2af622 100644
>>> --- a/drivers/xen/Makefile
>>> +++ b/drivers/xen/Makefile
>>> @@ -29,6 +29,7 @@ obj-$(CONFIG_XEN_MCE_LOG) += mcelog.o
>>> obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/
>>> obj-$(CONFIG_XEN_PRIVCMD)+= xen-privcmd.o
>>> obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
>>> +obj-$(CONFIG_XEN_DOM0) += xen_acpi_pad.o
>>> xen-evtchn-y := evtchn.o
>>> xen-gntdev-y := gntdev.o
>>> xen-gntalloc-y := gntalloc.o
>
> it should really depend on ACPI and maybe also X86, otherwise it is
> going to break the ARM build
>
>
Hmm, XEN_DOM0 has already depended on ACPI and X86_LOCAL_APIC (which depends on
X86_64).
Thanks,
Jinsong
>>> diff --git a/drivers/xen/xen_acpi_pad.c b/drivers/xen/xen_acpi_pad.c
>>> new file mode 100644
>>> index 000..e8c26a4
>>> --- /dev/null
>>> +++ b/drivers/xen/xen_acpi_pad.c
>>> @@ -0,0 +1,206 @@
>>> +/*
>>> + * xen_acpi_pad.c - Xen pad interface
>>> + *
>>> + * Copyright (c) 2012, Intel Corporation.
>>> + *Author: Liu, Jinsong + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it + * under the terms and conditions of the GNU General
>>> Public License, + * version 2, as published by the Free Software
>>> Foundation. + * + * This program is distributed in the hope it will
>>> be useful, but WITHOUT + * ANY WARRANTY; without even the implied
>>> warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR
>>> PURPOSE. See the GNU General Public License for + * more details.
>>> + */ +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define ACPI_PROCESSOR_AGGREGATOR_CLASS "acpi_pad"
>>> +#define ACPI_PROCESSOR_AGGREGATOR_DEVICE_NAME "Processor
>>> Aggregator" +#define ACPI_PROCESSOR_AGGREGATOR_NOTIFY 0x80
>>> +
>>> +static DEFINE_MUTEX(xen_pad_lock);
>>> +
>>> +static int xen_pad_set_idle_cpus(int num_cpus)
>>> +{
>>> + struct xen_platform_op op;
>>> +
>>> + if (num_cpus < 0)
>>> + return -EINVAL;
>>> +
>>> + /* set cpu nums expected to be idled */
>>> + op.cmd = XENPF_core_parking;
>>> + op.u.core_parking.type = XEN_CORE_PARKING_SET;
>>> + op.u.core_parking.idle_nums = num_cpus;
>>> +
>>> + return HYPERVISOR_dom0_op();
>>> +}
>>> +
>>> +/*
>>> + * Cannot get idle cpus by using hypercall once (shared with _SET)
>>> + * because of the characteristic of Xen continue_hypercall_on_cpu
>>> + */ +static int xen_pad_get_idle_cpus(void)
>>> +{
>>> + int ret;
>>> + struct xen_platform_op op;
>>> +
>>> + /* get cpu nums actually be idled */
>>> + op.cmd = XENPF_core_parking;
>>> + op.u.core_parking.type = XEN_CORE_PARKING_GET;
>>> + ret = HYPERVISOR_dom0_op();
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return op.u.core_parking.idle_nums;
>>> +}
>>> +
>>> +/*
>>> + * Query firmware how many CPUs should be idle
>>> + * return -1 on failure
>>> + */
>>> +static int xen_acpi_pad_pur(acpi_handle handle)
>>> +{
>>> + struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
>>> + union acpi_object *package;
>>> + int num = -1;
>>> +
>>> + if (ACPI_FAILURE(acpi_evaluate_object(handle, "_PUR", NULL,
>>> ))) + return num; +
>>> + if (!buffer.length || !buffer.pointer)
>>> + return num;
>>> +
>>> + package = buffer.pointer;
>>> +
>>> + if (package->type == ACPI_TYPE_PACKAGE &&
>>> + package->package.count == 2 &&
>>> + package->package.elements[0].integer.value == 1) /*
>>> rev 1 */ + + num =
>>> package->package.elements[1].integer.value; + +
>>> kfree(buffer.pointer); + return num;
>>> +}
>>> +
>>> +/* Notify firmware how many CPUs are idle */
>>> +static void xen_acpi_pad_ost(acpi_handle handle, int stat, +
>>> uint32_t idle_cpus) +{
>>> + union acpi_object params[3] = {
>>> + {.type = ACPI_TYPE_INTEGER,},
>>> + {.type = ACPI_TYPE_INTEGER,},
>>> + {.type = ACPI_TYPE_BUFFER,},
>>> + };
>>> + struct acpi_object_list arg_list = {3, params}; +
>>> + params[0].integer.value = ACPI_PROCESSOR_AGGREGATOR_NOTIFY;
>>> + params[1].integer.value = stat;
>>> + params[2].buffer.length = 4;
>>> + params[2].buffer.pointer = (void *)_cpus;
>>> + acpi_evaluate_object(handle, "_OST", _list, NULL); +}
>>> +
>>> +static void xen_acpi_pad_handle_notify(acpi_handle handle) +{
>>> + int num_cpus;
>>> +
>>> + num_cpus = xen_acpi_pad_pur(handle);
>>> + if (num_cpus < 0)
>>> + return;
>>> +
>>> + mutex_lock(_pad_lock);
>>> + if (xen_pad_set_idle_cpus(num_cpus)) {
>>> + mutex_unlock(_pad_lock);
>>> + return;
>>> + }
>>> +
>>> + num_cpus =
linux-next: Tree for Nov 6
Hi all, Changes since 20121105: The pci tree gained a build failure for which I applied a merge fix patch. The v4l-dvb tree still had its build failure so I used the version from next-20121026. The thermal tree lost its conflict. The pm tree gained a conflict against the pci tree. The tty tree gained a conflict against the arm tree. The clk tree lost its conflict. The akpm tree gained conflicts against the cgroup tree and I dropped a few patches that Andrew also dropped. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 209 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3d70f8c Linux 3.7-rc4) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (6404f0b ARM: 7569/1: mm: uninitialized warning corrections) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (8c23f40 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging sparc/master (f7e8d9f qlogicpti: Fix build warning.) Merging net/master (cacb6ba net: inet_diag -- Return error code if protocol handler is missed) Merging sound-current/for-linus (ae24c31 ALSA: hda - Force to reset IEC958 status bits for AD codecs) Merging pci-current/for-linus (85c413b Merge branch 'pci/huang-d3cold-fixes' into for-linus) Merging wireless/master (6fe7cc7 ath9k: Test for TID only in BlockAcks while checking tx status) Merging driver-core.current/driver-core-linus (8f0d816 Linux 3.7-rc3) Merging tty.current/tty-linus (8f0d816 Linux 3.7-rc3) Merging usb.current/usb-linus (d99e65b USB: fix build with XEN and EARLY_PRINTK_DBGP enabled but USB_SUPPORT disabled) Merging staging.current/staging-linus (8f0d816 Linux 3.7-rc3) Merging char-misc.current/char-misc-linus (8f0d816 Linux 3.7-rc3) Merging input-current/for-linus (32ed191 Input: tsc40 - remove wrong announcement of pressure support) Merging md-current/for-linus (ed30be0 MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9efade1 crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging rr-fixes/fixes (59ef28b module: fix out-by-one error in kallsyms) Merging asm-generic/master (9b04ebd asm-generic/io.h: remove asm/cach
Re: [PATCH RFC 0/4] Add firmware signature file check
2012/11/6 Ming Lei :
> On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai wrote:
>>
>> To be noted, it doesn't support the firmwares via udev but only the
>> direct loading, and the check for built-in firmware is missing, too.
>
> Generally, both direct loading and udev may request one same firmware
> image. And after check failed, current firmware load will fallback on udev
> to complete loading, so looks a check-failed firmware still can be loaded
> into kernel no matter if there is firmware signature check or not.
>
>
> Thanks,
> --
> Ming Lei
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
The udev direct write firmware through data attribute, maybe we can do
the same signature verification in firmware_data_write? The following
patch didn't test yet.
Thanks
Joey Lee
>From 035dde5fadc9e7f4b7811b18d3a5094ef88e8bbb Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi
Date: Tue, 6 Nov 2012 13:07:04 +0800
Subject: [PATCH] firmware: Add signature check to firmware_data_write
---
drivers/base/firmware_class.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..40d8cc6 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -621,6 +621,7 @@ static ssize_t firmware_data_write(struct file
*filp, struct kobject *kobj,
struct firmware_priv *fw_priv = to_firmware_priv(dev);
struct firmware_buf *buf;
ssize_t retval;
+ bool success = false;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
@@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file
*filp, struct kobject *kobj,
}
buf->size = max_t(size_t, offset, buf->size);
+
+#ifdef CONFIG_FIRMWARE_SIG
+ for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], buf->fw_id);
+ if (verify_signature(buf, path))
+ success = true;
+ }
+ if (!success) {
+ pr_err("Invalid signature file %s\n", path);
+ if (sig_enforce) {
+ vfree(buf->data);
+ buf->data = NULL;
+ buf->size = 0;
+ }
+ retval = -ENOENT;
+ }
+#endif /* CONFIG_FIRMWARE_SIG */
out:
mutex_unlock(_lock);
return retval;
--
1.6.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] mm/swap: automatic tuning for swapin readahead
On Wed, Oct 24, 2012 at 09:13:56AM +0800, Shaohua Li wrote: > On Tue, Oct 23, 2012 at 09:41:00AM -0400, Rik van Riel wrote: > > On 10/23/2012 01:51 AM, Shaohua Li wrote: > > > > >I have no strong point against the global state method. But I'd agree > > >making the > > >heuristic simple is preferred currently. I'm happy about the patch if the > > >'+1' > > >is removed. > > > > Without the +1, how will you figure out when to re-enable readahead? > > Below code in swapin_nr_pages can recover it. > + if (offset == prev_offset + 1 || offset == prev_offset - 1) > + pages <<= 1; > > Not perfect, but should work in some sort. This reminds me to think if > pagereadahead flag is really required, hit in swap cache is a more reliable > way > to count readahead hit, and as Hugh mentioned, swap isn't vma bound. Hugh, ping! Any chance you can check this again? Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote: > Matthew Garrett writes: > > > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > >> For automated installs you don't have to satisfy me. Feel free to > >> deliver a lousy solution to your users. Just don't use your arbitrary > >> design decisions to justify your kernel patches. > > > > My kernel patches are justified by genuine user requirements. > > Hogwash. You keep using that word, which is unfortunate. > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Correct. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. Incorrect. UEFI boot priorities can be set without physical user interaction. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. Correct, but precludes the kind of automated installs that I know real people do. The keys a machine carries don't vary depending on whether it shipped with Windows or not, so it's not possible to differentiate between the "shipped with Windows" and "shipped without Windows" cases when determining security models. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. That's a stretch. Bored now. You're adding nothing new to anyone's understanding of the problem, and I'm just saying the same thing I've been saying for months, so I don't see any purpose in discussing this with you further. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Consult] for many minor and trivial patches about "* change %8s to %s *"
Hello All:
1) Status:
A) I have many "* change %8s to %s *" patches (minor and trivial
patches).
B) for net subsystem, have 3 (have sent to relative members);
C) for another:
i) arch/x86/kernel/process_64.c:120,
pr_warn("WARNING: dead process %8s still has LDT? <%p/%d>\n",
dead_task->comm is 16 (TASK_COMM_LEN)
ii) arch/blackfin/kernel/irqchip.c:52:
seq_printf(p, " %8s", irq_desc_get_chip(desc)->name);
name is not solid length, such as "tilegx_msi" in
arch/tile/kernel/pci_gx.c
2) Next:
A) It seems, it is only a start (If I am 'lucky' enough, maybe can
find more).
B) for these minor and trivial patches for various subsystems.
C) have 3 sending ways:
i) let each relative subsystem only has one patch which include
all relative trivial modifications.
ii) or gather them into one patch and send to
linux-kernel@vger.kernel.org.
iii) or each minor and trivial patch is an individual.
3) Suggestion:
A) I prefer the first choice (let each subsystem only has one patch)
B) I will do it according to the first choice, until get another
suggestions.
thanks.
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.6.5-rt14
On Sat, 03 Nov 2012 20:04:58 +0100, Ove Karlsen said: > And have you given consideration to the fact that most distros and OS > grow with some levels of bloat, and everyone can`t be an expert, so > maybe one shold consider a (scheduler) queue for "bloat", and one queue > for main app, so that even bloated distros can run with the jitteramount > of a highly specialized distro? (for instance > mainapp,service1,mainapp,service2,mainapp,service3), if bloat is on > queue 2. Or is thins kind of thinking already in batch, or idle? So how does the kernel know which one is your "main app", and which one is "bloat"? Hint - you can't base it on "the main app is the one using OpenGL" or similar rule, as there may be multiple processes doing that, and you may consider one of them to be bloat - and *I* might consider that one to be the *important* one. Or even your definition may change around during the day - if you're running Doom3, an OpenGL-capable window manager is probably "bloat", but once you exit Doom3 and start working with multiple windows again, suddenly you're going to want that window manager to be the "important" process again... pgp3SOV39mT2V.pgp Description: PGP signature
Re: [PATCH 2/2] gpio: do not call __gpio_xxx under !CONFIG_GPIOLIB
On Sun, Nov 04, 2012 at 06:47:12PM +0100, Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 8:00 AM, Yuanhan Liu
> wrote:
>
> > Those functions are availabe only when CONFIG_GPIOLIB is set. So, we
> > should not call them under !CONFIG_GPIOLIB block.
> >
> > This would fix following build errros:
> > include/asm-generic/gpio.h: In function 'gpio_get_value_cansleep':
> > include/asm-generic/gpio.h:220:2: error: implicit declaration of function
> > '__gpio_get_value'
> > include/asm-generic/gpio.h: In function 'gpio_set_value_cansleep':
> > nclude/asm-generic/gpio.h:226:2: error: implicit declaration of function
> > '__gpio_set_value'
>
> OK...
>
> > static inline int gpio_get_value_cansleep(unsigned gpio)
> > {
> > - might_sleep();
Hi,
>
> So why are you deleting this very useful might_sleep() runtime
> semantic check?
Yes, I should keep it. I did it because I saw the definition of
gpio_get_value at include/linux/gpio.h didn't call that function.
Will keep it in the next version together with the previous patch.
And sorry that it may take some time, as I'm occupied by other things :(
Thanks.
--yliu
>
> > - return __gpio_get_value(gpio);
> > + WARN_ON(1);
> > + return 0;
> > }
> >
> > static inline void gpio_set_value_cansleep(unsigned gpio, int value)
> > {
> > - might_sleep();
> > - __gpio_set_value(gpio, value);
> > + WARN_ON(1);
> > }
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > >> For automated installs you don't have to satisfy me. Feel free to >> deliver a lousy solution to your users. Just don't use your arbitrary >> design decisions to justify your kernel patches. > > My kernel patches are justified by genuine user requirements. Hogwash. If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. Furthermore no matter how hard we try with current techniques there will eventually be kernel bugs that allow attackers to inject code into the kernel. So attempting to fully close that attack vector is questionable. > If you > don't feel that there's any requirement for the kernel to satisfy the > people who use it, you're free to ignore those patches. I feel allowing the kernel to be hacked to bits and decend into an unmaintainable mess does not serve the users who use the kernel, and to prevent that technically poor patches should be rejected. This helps prevent non-technical considerations from justifying technically poor decisions. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: > This patchset introduces new functions into random32 library for > getting the requested number of pseudo-random bytes. > > Before introducing these new functions into random32 library, > prandom32() and prandom32_seed() with "prandom32" prefix are > renamed to random32_state() and srandom32_state() respectively. > > The purpose of this renaming is to prevent some kernel developers > from assuming that prandom32() and random32() might imply that only > prandom32() was the one using a pseudo-random number generator by > prandom32's "p", and the result may be a very embarassing security > exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? pgpJAuZEgbFx9.pgp Description: PGP signature
Re: [PATCH 2/2 v2] mm: print out information of file affected by memory error
On Mon, Nov 05, 2012 at 02:01:54PM -0800, Andrew Morton wrote:
> On Fri, 2 Nov 2012 12:33:13 -0400
> Naoya Horiguchi wrote:
>
> > Printing out the information about which file can be affected by a
> > memory error in generic_error_remove_page() is helpful for user to
> > estimate the impact of the error.
> >
> > Changelog v2:
> > - dereference mapping->host after if (!mapping) check for robustness
> >
> > ...
> >
> > --- v3.7-rc3.orig/mm/truncate.c
> > +++ v3.7-rc3/mm/truncate.c
> > @@ -151,14 +151,20 @@ int truncate_inode_page(struct address_space
> > *mapping, struct page *page)
> > */
> > int generic_error_remove_page(struct address_space *mapping, struct page
> > *page)
> > {
> > + struct inode *inode;
> > +
> > if (!mapping)
> > return -EINVAL;
> > + inode = mapping->host;
> > /*
> > * Only punch for normal data pages for now.
> > * Handling other types like directories would need more auditing.
> > */
> > - if (!S_ISREG(mapping->host->i_mode))
> > + if (!S_ISREG(inode->i_mode))
> > return -EIO;
> > + pr_info("MCE %#lx: file info pgoff:%lu, inode:%lu, dev:%s\n",
> > + page_to_pfn(page), page_index(page),
> > + inode->i_ino, inode->i_sb->s_id);
> > return truncate_inode_page(mapping, page);
> > }
> > EXPORT_SYMBOL(generic_error_remove_page);
>
> A couple of things.
>
> - I worry that if a hardware error occurs, it might affect a large
> amount of memory all at the same time. For example, if a 4G memory
> block goes bad, this message will be printed a million times?
If the error on 4G memory block triggered by SRAO MCE and these 1M pages
are all pagecache pages, the answer is yes.
But I think that if it's a whole DIMM error, it should be reported by
another type of MCE than SRAO, so printing a million times seems to be
unlikely to happen.
> - hard-wiring "MCE" in here seems a bit of a layering violation?
> What right does the generic, core .error_remove_page() implementation
> have to assume that it was called because of an MCE?
OK, we need not assume that. I change "MCE " prefix to more specific
one like "Memory error ".
> Many CPU types don't eveh have such a thing?
No. At least currently, only SRAO MCE triggers memory_failure() and
it's defined only on some newest highend models of Intel CPUs.
Thanks,
Naoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 3/4] firmware: Add a signature check
On Mon, 2012-11-05 at 18:20 +0100, Takashi Iwai wrote:
> Add a feature to check the firmware signature, specified via Kconfig
> CONFIG_FIRMWARE_SIG. The signature check is performed only for the
> direct fw loading without udev. Also no check for built-in firmware
> blobs is implemented yet.
>
> Signed-off-by: Takashi Iwai
> ---
> drivers/base/Kconfig | 6 +
> drivers/base/firmware_class.c | 56 +++---
> include/linux/firmware.h | 7 +
> kernel/module_signing.c | 63
> +++
> 4 files changed, 128 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index b34b5cd..3696fd7 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR
> this option you can point it elsewhere, such as /lib/firmware/ or
> some other directory containing the firmware files.
>
> +config FIRMWARE_SIG
> + bool "Firmware signature verification"
> + depends on FW_LOADER && MODULE_SIG
> + help
> + Enable firmware signature check.
> +
> config DEBUG_DRIVER
> bool "Driver Core verbose debug messages"
> depends on DEBUG_KERNEL
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 8945f4e..575bc4c 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -36,6 +36,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
> MODULE_DESCRIPTION("Multi purpose firmware loading support");
> MODULE_LICENSE("GPL");
>
> +#ifdef CONFIG_FIRMWARE_SIG
> +static bool sig_enforce;
> +module_param(sig_enforce, bool, 0644);
> +#endif
> +
> /* Builtin firmware support */
>
> #ifdef CONFIG_FW_LOADER
> @@ -287,7 +292,7 @@ static noinline long fw_file_size(struct file *file)
> return st.size;
> }
>
> -static bool fw_read_file_contents(struct file *file, struct firmware_buf
> *fw_buf)
> +static bool fw_read_file_contents(struct file *file, void **bufp, size_t
> *sizep)
> {
> long size;
> char *buf;
> @@ -302,11 +307,39 @@ static bool fw_read_file_contents(struct file *file,
> struct firmware_buf *fw_buf
> vfree(buf);
> return false;
> }
> - fw_buf->data = buf;
> - fw_buf->size = size;
> + *bufp = buf;
> + *sizep = size;
> return true;
> }
>
> +#ifdef CONFIG_FIRMWARE_SIG
> +static bool verify_signature(struct firmware_buf *buf, const char *path)
> +{
> + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - 1;
> + struct file *file;
> + void *sig_data;
> + size_t sig_size;
> + bool success;
> +
> + file = filp_open(path, O_RDONLY, 0);
> + if (IS_ERR(file))
> + return false;
> +
> + success = fw_read_file_contents(file, _data, _size);
> + fput(file);
> + if (success) {
> + if (sig_size > markerlen &&
> + !memcmp(sig_data, FIRMWARE_SIG_STRING, markerlen))
> + success = !fw_verify_sig(buf->data, buf->size,
> + sig_data + markerlen,
> + sig_size - markerlen);
> + pr_debug("verified signature %s: %d\n", path, success);
> + vfree(sig_data);
> + }
> + return success;
> +}
> +#endif /* CONFIG_FIRMWARE_SIG */
> +
> static bool fw_get_filesystem_firmware(struct firmware_buf *buf)
> {
> int i;
> @@ -320,8 +353,23 @@ static bool fw_get_filesystem_firmware(struct
> firmware_buf *buf)
> file = filp_open(path, O_RDONLY, 0);
> if (IS_ERR(file))
> continue;
> - success = fw_read_file_contents(file, buf);
> + success = fw_read_file_contents(file, >data, >size);
> fput(file);
> +#ifdef CONFIG_FIRMWARE_SIG
> + if (success) {
> + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i],
> + buf->fw_id);
> + if (!verify_signature(buf, path)) {
> + pr_err("Invalid signature file %s\n", path);
> + if (sig_enforce) {
> + vfree(buf->data);
> + buf->data = NULL;
> + buf->size = 0;
> + success = false;
> + }
> + }
> + }
> +#endif /* CONFIG_FIRMWARE_SIG */
The existing kernel modules are read by userspace into a buffer, which
is passed to the kernel. As there is no way of verifying what was read
by userspace is the same as what was passed to the kernel, the signature
verification is done, in the kernel, on the buffer contents. The new
kernel module syscall passes a file descriptor. With commit "41110a4
ima: support new kernel module syscall" the kernel module
Re: [PATCH v2] pinctrl: samsung: Add ifdef CONFIG_OF_GPIO guard for gc->of_node
On 5 November 2012 21:14, Axel Lin wrote: > This fixes below build error when !CONFIG_OF_GPIO. > > CC drivers/pinctrl/pinctrl-samsung.o > drivers/pinctrl/pinctrl-samsung.c: In function > 'samsung_pinctrl_parse_dt_pins': > drivers/pinctrl/pinctrl-samsung.c:557:19: warning: unused variable 'prop' > [-Wunused-variable] > drivers/pinctrl/pinctrl-samsung.c: In function 'samsung_gpiolib_register': > drivers/pinctrl/pinctrl-samsung.c:797:5: error: 'struct gpio_chip' has no > member named 'of_node' > make[2]: *** [drivers/pinctrl/pinctrl-samsung.o] Error 1 > make[1]: *** [drivers/pinctrl] Error 2 > make: *** [drivers] Error 2 > > Signed-off-by: Axel Lin > --- > v2: > Don't remove the prop variable. > It is used in of_property_for_each_string() when CONFIG_OF_GPIO is enabled. > > drivers/pinctrl/pinctrl-samsung.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pinctrl/pinctrl-samsung.c > b/drivers/pinctrl/pinctrl-samsung.c > index fc34cac..f798b4d 100644 > --- a/drivers/pinctrl/pinctrl-samsung.c > +++ b/drivers/pinctrl/pinctrl-samsung.c > @@ -794,7 +794,9 @@ static int __devinit samsung_gpiolib_register(struct > platform_device *pdev, > gc->base = ctrl->base + bank->pin_base; > gc->ngpio = bank->nr_pins; > gc->dev = >dev; > +#if defined(CONFIG_OF_GPIO) > gc->of_node = bank->of_node; > +#endif > gc->label = bank->name; > > ret = gpiochip_add(gc); The samsung pinctrl driver supports only device tree enabled platforms. So instead of adding the above #if, would it not be better to add 'select OF_GPIO' for Samsung pinctrl driver in drivers/pinctrl/Kconfig. ? Thanks, Thomas. > -- > 1.7.9.5 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the cgroup tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/memcontrol.c between commit ab5196c202c6 ("memcg: make
mem_cgroup_reparent_charges non failing") from the cgroup tree and commit
"memcg: destroy memcg caches" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/memcontrol.c
index a38e9fb,b650e09..000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5946,11 -6034,17 +6008,12 @@@ free_out
return ERR_PTR(error);
}
-static int mem_cgroup_pre_destroy(struct cgroup *cont)
+static void mem_cgroup_pre_destroy(struct cgroup *cont)
{
struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
- int ret;
- css_get(>css);
- ret = mem_cgroup_reparent_charges(memcg);
+ mem_cgroup_reparent_charges(memcg);
+ mem_cgroup_destroy_all_caches(memcg);
- css_put(>css);
-
- return ret;
}
static void mem_cgroup_destroy(struct cgroup *cont)
pgpISPTKAMBAu.pgp
Description: PGP signature
Re: [PATCH 2/7] ACPI / PM: Move device power state selection routine to device_pm.c
This patch doesn't apply...
I'm trying on Linus' master branch, HEAD is v3.7-rc4, and I've merged
your pm-qos branch on top of v3.7-rc4.
Thanks,
Aaron
On Mon, Oct 29, 2012 at 10:09:09AM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ACPI function for choosing device power state is now located
> in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more
> logical place for it, so move it there.
>
> However, instead of moving the function entirely, move its core only
> under a different name and with a different list of arguments, so
> that it is more flexible, and leave a wrapper around it in the
> original location.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/device_pm.c | 107
> +++
> drivers/acpi/sleep.c | 88 +-
> include/acpi/acpi_bus.h | 15 ++
> 3 files changed, 124 insertions(+), 86 deletions(-)
>
> Index: linux/drivers/acpi/device_pm.c
> ===
> --- linux.orig/drivers/acpi/device_pm.c
> +++ linux/drivers/acpi/device_pm.c
> @@ -23,7 +23,9 @@
> */
>
> #include
> +#include
> #include
> +#include
>
> #include
> #include
> @@ -89,3 +91,108 @@ acpi_status acpi_remove_pm_notifier(stru
> mutex_unlock(_pm_notifier_lock);
> return status;
> }
> +
> +/**
> + * acpi_device_power_state - Get preferred power state of ACPI device.
> + * @dev: Device whose preferred target power state to return.
> + * @adev: ACPI device node corresponding to @dev.
> + * @target_state: System state to match the resultant device state.
> + * @d_max_in: Deepest low-power state to take into consideration.
> + * @d_min_p: Location to store the upper limit of the allowed states range.
> + * Return value: Preferred power state of the device on success, -ENODEV
> + * (if there's no 'struct acpi_device' for @dev) or -EINVAL on failure
> + *
> + * Find the lowest power (highest number) ACPI device power state that the
> + * device can be in while the system is in the state represented by
> + * @target_state. If @d_min_p is set, the highest power (lowest number)
> device
> + * power state that @dev can be in for the given system sleep state is stored
> + * at the location pointed to by it.
> + *
> + * Callers must ensure that @dev and @adev are valid pointers and that @adev
> + * actually corresponds to @dev before using this function.
> + */
> +int acpi_device_power_state(struct device *dev, struct acpi_device *adev,
> + u32 target_state, int d_max_in, int *d_min_p)
> +{
> + char acpi_method[] = "_SxD";
> + unsigned long long d_min, d_max;
> + bool wakeup = false;
> +
> + if (d_max_in < ACPI_STATE_D0 || d_max_in > ACPI_STATE_D3)
> + return -EINVAL;
> +
> + if (d_max_in > ACPI_STATE_D3_HOT) {
> + enum pm_qos_flags_status stat;
> +
> + stat = dev_pm_qos_flags(dev, PM_QOS_FLAG_NO_POWER_OFF);
> + if (stat == PM_QOS_FLAGS_ALL)
> + d_max_in = ACPI_STATE_D3_HOT;
> + }
> +
> + acpi_method[2] = '0' + target_state;
> + /*
> + * If the sleep state is S0, the lowest limit from ACPI is D3,
> + * but if the device has _S0W, we will use the value from _S0W
> + * as the lowest limit from ACPI. Finally, we will constrain
> + * the lowest limit with the specified one.
> + */
> + d_min = ACPI_STATE_D0;
> + d_max = ACPI_STATE_D3;
> +
> + /*
> + * If present, _SxD methods return the minimum D-state (highest power
> + * state) we can use for the corresponding S-states. Otherwise, the
> + * minimum D-state is D0 (ACPI 3.x).
> + *
> + * NOTE: We rely on acpi_evaluate_integer() not clobbering the integer
> + * provided -- that's our fault recovery, we ignore retval.
> + */
> + if (target_state > ACPI_STATE_S0) {
> + acpi_evaluate_integer(adev->handle, acpi_method, NULL, _min);
> + wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid
> + && adev->wakeup.sleep_state >= target_state;
> + } else if (dev_pm_qos_flags(dev, PM_QOS_FLAG_REMOTE_WAKEUP) !=
> + PM_QOS_FLAGS_NONE) {
> + wakeup = adev->wakeup.flags.valid;
> + }
> +
> + /*
> + * If _PRW says we can wake up the system from the target sleep state,
> + * the D-state returned by _SxD is sufficient for that (we assume a
> + * wakeup-aware driver if wake is set). Still, if _SxW exists
> + * (ACPI 3.x), it should return the maximum (lowest power) D-state that
> + * can wake the system. _S0W may be valid, too.
> + */
> + if (wakeup) {
> + acpi_status status;
> +
> + acpi_method[3] = 'W';
> + status = acpi_evaluate_integer(adev->handle, acpi_method, NULL,
> + _max);
> +
linux-next: manual merge of the akpm tree with the cgroup tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
mm/memcontrol.c between commit ab5196c202c6 ("memcg: make
mem_cgroup_reparent_charges non failing") from the cgroup tree and commit
"memcg: allow a memcg with kmem charges to be destructed" from the akpm
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc mm/memcontrol.c
index 8f2b789,540bac5..000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -3987,11 -4015,15 +3992,12 @@@ static void mem_cgroup_force_empty_list
*
* Caller is responsible for holding css reference on the memcg.
*/
-static int mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
+static void mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
{
- struct cgroup *cgrp = memcg->css.cgroup;
int node, zid;
+ u64 usage;
do {
- if (cgroup_task_count(cgrp) || !list_empty(>children))
- return -EBUSY;
/* This is for making all *used* pages to be on LRU. */
lru_add_drain_all();
drain_all_stock_sync(memcg);
@@@ -4016,7 -4053,11 +4027,9 @@@
* right after the check. RES_USAGE should be safe as we always
* charge before adding to the LRU.
*/
- } while (res_counter_read_u64(>res, RES_USAGE) > 0);
+ usage = res_counter_read_u64(>res, RES_USAGE) -
+ res_counter_read_u64(>kmem, RES_USAGE);
+ } while (usage > 0);
-
- return 0;
}
/*
pgpCs5HP31Ay8.pgp
Description: PGP signature
RE: [PATCH RESEND 0/8] TI Touchscreen driver updates and Support for TSC/ADC MFD driver
Hi Samuel, On Tue, Nov 06, 2012 at 04:25:24, Samuel Ortiz wrote: > Hi Rachna, > > On Tue, Oct 16, 2012 at 12:55:37PM +0530, Patil, Rachna wrote: > > This patch set is a cumulative set of [1] and [2] sent earlier. > > I have merged the patch set so that the MFD patches apply without any > > issues. > > > > Also Note that there are no code changes in either of the patch set, > > only rebased on top of linux-next to make sure that all the patches > > apply without any conflicts. > > > > This patch set has been tested on AM335x EVM. > > > > [1] "[PATCH 0/4] input: TSC: ti_tscadc: TI Touchscreen driver updates" > > (http://www.spinics.net/lists/linux-input/msg22107.html) > > > > [2] "[PATCH v5 0/4] Support for TSC/ADC MFD driver" > > (http://www.spinics.net/lists/linux-input/msg22832.html) > > > > Patil, Rachna (8): > > input: TSC: ti_tscadc: Correct register usage > > input: TSC: ti_tscadc: Add Step configuration as platform data > > input: TSC: ti_tscadc: set FIFO0 threshold Interrupt > > input: TSC: ti_tscadc: Remove definition of End Of Interrupt register > > input: TSC: ti_tscadc: Rename the existing touchscreen driver > > MFD: ti_tscadc: Add support for TI's TSC/ADC MFDevice > > input: TSC: ti_tsc: Convert TSC into a MFDevice > > IIO : ADC: tiadc: Add support of TI's ADC driver > All patches applied now, thanks a lot. Thanks for pulling this in. Regards, Rachna > > Cheers, > Samuel. > > -- > Intel Open Source Technology Centre > http://oss.intel.com/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Source updater script
On Tue, Nov 06, 2012 at 12:52:46AM +0100, Matteo Croce wrote: > Hi all, > > I know that this is useless to people using git, but it was so fun to write > and I use it to update regularly my pc kernel source from time to time > while saving servers (and home) bandwidth Have you looked at the python script called 'ketchup'? I think it already does a lot of what you are doing here. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/104] checkpatch: warn about using CONFIG_EXPERIMENTAL
On Mon, 2012-11-05 at 15:03 -0800, Kees Cook wrote:
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, it is being removed. This will discourage future addition of
> CONFIG_EXPERIMENTAL while it is being phased out.
>
> Cc: Andy Whitcroft
> Signed-off-by: Kees Cook
> ---
> scripts/checkpatch.pl |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 21a9f5d..f8b33ed 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1757,6 +1757,13 @@ sub process {
> #print "is_start<$is_start> is_end<$is_end>
> length<$length>\n";
> }
>
> +# Discourage the addition of CONFIG_EXPERIMENTAL in Kconfig.
> + if ($realfile =~ /Kconfig/ &&
> + $line =~ /.\s*depends on\s+.*\bEXPERIMENTAL\b/) {
> + WARN("CONFIG_EXPERIMENTAL",
> + "Use of CONFIG_EXPERIMENTAL is deprecated. For
> alternatives, see:\nhttps://lkml.org/lkml/2012/10/23/580\n;);
> + }
> +
> if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
> ($line =~ /\+(EXTRA_[A-Z]+FLAGS).*/)) {
> my $flag = $1;
Couple bits of trivia:
Perhaps this would be better if it didn't just check Kconfig
files and simply looked for any use of CONFIG_EXPERIMENTAL
$line =~ /^\+.*\bCONFIG_EXPERIMENTAL\b/
I think the output WARN would be better on single line.
"Use of CONFIG_EXPERIMENTAL is deprecated. For alternatives see
https://lkml.org/lkml/2012/10/23/580\n;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] fat: remove parent_logstart check in fat_get_parent
2012/11/5, OGAWA Hirofumi :
> Namjae Jeon writes:
>
>> +blknr = fat_clus_to_blknr(sbi, parent_logstart);
>> +parent_bh = sb_bread(sb, blknr);
>> +if (!parent_bh) {
>> +fat_msg(sb, KERN_ERR,
>> +"NFS:unable to read cluster of parent
>> directory");
>> +goto out;
>> }
>> +de = (struct msdos_dir_entry *) parent_bh->b_data;
>> +clus_to_match = fat_get_start(sbi, [0]);
>> +search_clus = fat_get_start(sbi, [1]);
>> +if (!search_clus)
>> +search_clus = sbi->root_cluster;
>> +brelse(parent_bh);
>> +do {
>> +parent_inode = fat_traverse_cluster(sb,
>> +search_clus, clus_to_match);
>> +if (IS_ERR(parent_inode) || parent_inode)
>> +break;
>> +search_clus = fat_read_next_clus(sb,
>> +search_clus);
>> +if (search_clus < 0)
>> +break;
>> +} while (search_clus != FAT_ENT_EOF);
>> }
>> out:
>> brelse(dotdot_bh);
>
> I started to understand what is doing this with cleanup. It is really
> strange and duplicates many codes with bugs.
>
> So, please replace whole FAT nfs patches in -mm to review whole at next
> patchset. And sorry, but please think whole more carefully.
Hi OGAWA.
Okay, I will rework all of patches as your comment.
Thanks for review.
>
> Thanks.
> --
> OGAWA Hirofumi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > For automated installs you don't have to satisfy me. Feel free to > deliver a lousy solution to your users. Just don't use your arbitrary > design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. If you don't feel that there's any requirement for the kernel to satisfy the people who use it, you're free to ignore those patches. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the tty tree with the arm tree
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in
drivers/tty/serial/omap-serial.c between commit d864c03bfce2 ("SERIAL:
omap: remove setting of EFR SCD bit") from the arm tree and commit
7ba897d77ce2 ("serial: omap: Remove the default setting of special
character") from the tty tree.
I fixed it up (using the version from the arm tree) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpjNlb1skvhp.pgp
Description: PGP signature
Re: [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote: > Actually moving it from plat-omap, as this framework/driver code is > supposed to be under drivers/ folder. The framework should work with > the current supported OMAP processors (OMAP1+) that have mailbox and > can be used as a method of interprocessor communication. > > The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism > that provides a communication channel between processors through a set of > registers and their associated interrupt signals by sending and receiving > messages. > diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? Is this a generic interface to any mailbox driver? If so, then I don't think having "omap" in the symbol names is appropriate. If the header is specific to the OMAP driver, I don't think using the very generic filename "mailbox.h" is appropriate; use omap_mailbox.h instead? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: >> Matthew Garrett writes: >> >> > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> >> Matthew Garrett writes: >> >> > No, in the general case the system will do that once it fails to find a >> >> > bootable OS on the drive. >> >> >> >> In the general case there will be a bootable OS on the drive. >> > >> > That's in no way a given. >> >> You have it backwards. The conclusion here is that having a case where >> a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. I have spent what feels like half my life doing automatic installs. I care a lot and I understand the requirements. I also see through misstatements about reality used to justify stupid design decisions. For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. Non-interactive installs do not justify removing all trust from the root user of a system, disabling suspend to disk and completely rewriting kexec for the simple expedient removing a couple of lines of code from your bootloader. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: spear: Add stub functions for spear3[0|1|2]0_clk_init()
On Tue, Nov 6, 2012 at 8:04 AM, Axel Lin wrote: > This fixes compile error if one of SPEAr3xx implementations is not selected. > > CC drivers/clk/spear/spear3xx_clock.o > drivers/clk/spear/spear3xx_clock.c: In function 'spear3xx_clk_init': > drivers/clk/spear/spear3xx_clock.c:599:3: error: implicit declaration of > function 'spear300_clk_init' [-Werror=implicit-function-declaration] > drivers/clk/spear/spear3xx_clock.c:601:3: error: implicit declaration of > function 'spear310_clk_init' [-Werror=implicit-function-declaration] > drivers/clk/spear/spear3xx_clock.c:603:3: error: implicit declaration of > function 'spear320_clk_init' [-Werror=implicit-function-declaration] > cc1: some warnings being treated as errors > make[3]: *** [drivers/clk/spear/spear3xx_clock.o] Error 1 > make[2]: *** [drivers/clk/spear] Error 2 > make[1]: *** [drivers/clk] Error 2 > make: *** [drivers] Error 2 > > Signed-off-by: Axel Lin Thanks.. Acked-by: Viresh Kumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/16] mm: use vm_unmapped_area() on sparc32 architecture
On Mon, Nov 5, 2012 at 5:25 PM, David Miller wrote: > From: Michel Lespinasse > Date: Mon, 5 Nov 2012 14:47:12 -0800 > >> Update the sparc32 arch_get_unmapped_area function to make use of >> vm_unmapped_area() instead of implementing a brute force search. >> >> Signed-off-by: Michel Lespinasse > > Hmmm... > >> - if (flags & MAP_SHARED) >> - addr = COLOUR_ALIGN(addr); >> - else >> - addr = PAGE_ALIGN(addr); > > What part of vm_unmapped_area() is going to duplicate this special > aligning logic we need on sparc? The idea there is that you can specify the desired alignment mask and offset using info.align_mask and info.align_offset. Now, I just noticed that the old code actually always uses an alignment offset of 0 instead of basing it on pgoff. I'm not sure why that is, but it looks like this may be an issue ? -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Second attempt at kernel secure boot support
On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > Matthew Garrett writes: > > > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: > >> Matthew Garrett writes: > >> > No, in the general case the system will do that once it fails to find a > >> > bootable OS on the drive. > >> > >> In the general case there will be a bootable OS on the drive. > > > > That's in no way a given. > > You have it backwards. The conclusion here is that having a case where > a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Grant, On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely wrote: > > > Joel A Fernandes wrote: > >>Hi Grant, >> >>On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely >> wrote: >>> I'm open to suggestions if anyone has any. I have not objections to a >>> fixup approach, but I'm not comfortable with anything that is fragile >>> to modifications to the fragment. >> >>I am fairly new to the DT world so please bear with me, but how about >>a method that resolves symbols the same way that the linux dynamic >>linker does when shared libraries are loaded? >> >>A separate table (similar to .PLT/GOT sections in the ELF object >>format) could be created when the fragment is loaded, and the phandle >>references could be fixed to point to the table offsets during compile >>time. This table would be a second level indirection and the kernel >>would populate this table with the in-kernel values of the phandles >>that the dt fragment refers to. > > That's an interesting idea that is worth exploring. That would make > it possible to avoid a fixup stage, but it also means that any parsing > code must know how to handle the got-like table. It won't be > backwards compatible with existing tools. It also wouldn't easily > support the case of firmware applying the overlay and passing the > resulting tree to the kernel. Hmmm Not being backwards compatible > at the data level is a big problem. I really want a method that can > resolve back to the current data format or is a compatible extension > of it. > Is it meaningful or feasible to make the table a part of the tree structure itself? the table would initially be empty. If I'm right, this is how the GOT tables in ELF objects that refer to unresolved symbols in shared libraries are implemented as well, they are a part of the object and are loaded into memory and fixed up. If the table is a part of the DT data, the tools would then be able to parse such a tree. We could enforce that the got-like tree would strictly follow a predefined format. Something along these lines would also avoid the need for a tree fix up. Do you think this reduces the difficulty of backward compatibility with the parsing tools and firmware loading? >> >>This might involve changes to the DT core, but as such, this method >>wouldn't suffer from the fragility problem of either base or fragment >>DT trees being modified. >> >>The table itself could be added to the tree by the compiler, and the >>phandles could point to it (fixed). such phandles could be marked for >>special handling to facilitate the 1-level indirection. > > That's part of the problem. Property values are essentially > anaonymous data. There is no mechanism currently for marking data > such as indicate which data values are phandles. If there were then > it would be a simple matter to find all the phandles and fix them up. > > We could possibly add data type suppplementary properties to the tree > to solve that problem. They would have to be optional for the base > tree to retain backwards compatibility, but could be required on > overlays. > Sure, so if we add data type supplementary properties to the tree to indicate the data type as "indirect phandle", then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. Thanks and Regards, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] mailbox: split internal header from API header
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Luna
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48 +
include/linux/mailbox.h | 22 +
3 files changed, 57 insertions(+), 47 deletions(-)
create mode 100644 include/linux/mailbox.h
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 6346ad3..aab9a13 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -116,6 +116,40 @@ out:
}
EXPORT_SYMBOL(omap_mbox_msg_send);
+void omap_mbox_save_ctx(struct omap_mbox *mbox)
+{
+ if (!mbox->ops->save_ctx) {
+ dev_err(mbox->dev, "%s:\tno save\n", __func__);
+ return;
+ }
+
+ mbox->ops->save_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_save_ctx);
+
+void omap_mbox_restore_ctx(struct omap_mbox *mbox)
+{
+ if (!mbox->ops->restore_ctx) {
+ dev_err(mbox->dev, "%s:\tno restore\n", __func__);
+ return;
+ }
+
+ mbox->ops->restore_ctx(mbox);
+}
+EXPORT_SYMBOL(omap_mbox_restore_ctx);
+
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ mbox->ops->enable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_enable_irq);
+
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
+{
+ mbox->ops->disable_irq(mbox, irq);
+}
+EXPORT_SYMBOL(omap_mbox_disable_irq);
+
static void mbox_tx_tasklet(unsigned long tx_data)
{
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
index cc3921e..b05f64c 100644
--- a/drivers/mailbox/mailbox.h
+++ b/drivers/mailbox/mailbox.h
@@ -8,17 +8,7 @@
#include
#include
#include
-
-typedef u32 mbox_msg_t;
-struct omap_mbox;
-
-typedef int __bitwise omap_mbox_irq_t;
-#define IRQ_TX ((__force omap_mbox_irq_t) 1)
-#define IRQ_RX ((__force omap_mbox_irq_t) 2)
-
-typedef int __bitwise omap_mbox_type_t;
-#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
-#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+#include
struct omap_mbox_ops {
omap_mbox_type_ttype;
@@ -61,45 +51,9 @@ struct omap_mbox {
struct blocking_notifier_head notifier;
};
-int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
-void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
-
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
-static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
-{
- if (!mbox->ops->save_ctx) {
- dev_err(mbox->dev, "%s:\tno save\n", __func__);
- return;
- }
-
- mbox->ops->save_ctx(mbox);
-}
-
-static inline void omap_mbox_restore_ctx(struct omap_mbox *mbox)
-{
- if (!mbox->ops->restore_ctx) {
- dev_err(mbox->dev, "%s:\tno restore\n", __func__);
- return;
- }
-
- mbox->ops->restore_ctx(mbox);
-}
-
-static inline void omap_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_irq_t irq)
-{
- mbox->ops->enable_irq(mbox, irq);
-}
-
-static inline void omap_mbox_disable_irq(struct omap_mbox *mbox,
-omap_mbox_irq_t irq)
-{
- mbox->ops->disable_irq(mbox, irq);
-}
-
#endif /* MAILBOX_H */
diff --git a/include/linux/mailbox.h b/include/linux/mailbox.h
new file mode 100644
index 000..e8e4131
--- /dev/null
+++ b/include/linux/mailbox.h
@@ -0,0 +1,22 @@
+/* mailbox.h */
+
+typedef u32 mbox_msg_t;
+struct omap_mbox;
+
+typedef int __bitwise omap_mbox_irq_t;
+#define IRQ_TX ((__force omap_mbox_irq_t) 1)
+#define IRQ_RX ((__force omap_mbox_irq_t) 2)
+
+typedef int __bitwise omap_mbox_type_t;
+#define OMAP_MBOX_TYPE1 ((__force omap_mbox_type_t) 1)
+#define OMAP_MBOX_TYPE2 ((__force omap_mbox_type_t) 2)
+
+int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
+
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
+
+void omap_mbox_save_ctx(struct omap_mbox *mbox);
+void omap_mbox_restore_ctx(struct omap_mbox *mbox);
+void omap_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
+void omap_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] drivers: mailbox: omap-mailbox out of plat code
As part of plat-omap code cleanup, move omap-mailbox framework to a newly drivers/mailbox folder, right now this code is specific to OMAP platforms, but with some clean up it could be the base for a generic framework; living under drivers/mailbox could give it some exposure for interested developers to give feedback and propose changes. In the past there was a mailbox-like driver in mach-ux500, I was hoping both could live under the same folder, however the platform using it, was dropped a couple of kernel releases back and with it the other similar mailbox implementation. However and as per Loic's comments[1], it looks like there could be another potential mailbox candidate to live under drivers/mailbox in the works, along with some proposed changes that could make the original framework to evolve towards a generic implementation. So for now, lets move the mailbox code to drivers/mailbox and split internal structures from common API for others to use. Based on 3.7-rc4. 1. https://lkml.org/lkml/2012/10/31/123 Omar Ramirez Luna (2): mailbox: OMAP: introduce mailbox framework mailbox: split internal header from API header arch/arm/configs/omap1_defconfig |3 +- arch/arm/mach-omap1/Makefile |4 - arch/arm/mach-omap1/mailbox.c | 199 arch/arm/mach-omap2/Makefile |3 - arch/arm/mach-omap2/devices.c |4 +- arch/arm/mach-omap2/mailbox.c | 430 -- arch/arm/plat-omap/Kconfig| 16 - arch/arm/plat-omap/Makefile |3 - arch/arm/plat-omap/include/plat/mailbox.h | 105 --- arch/arm/plat-omap/mailbox.c | 435 -- drivers/Kconfig |2 + drivers/Makefile |1 + drivers/mailbox/Kconfig | 37 +++ drivers/mailbox/Makefile |4 + drivers/mailbox/mailbox-omap1.c | 200 drivers/mailbox/mailbox-omap2.c | 430 ++ drivers/mailbox/mailbox.c | 469 + drivers/mailbox/mailbox.h | 59 include/linux/mailbox.h | 22 ++ 19 files changed, 1228 insertions(+), 1198 deletions(-) delete mode 100644 arch/arm/mach-omap1/mailbox.c delete mode 100644 arch/arm/mach-omap2/mailbox.c delete mode 100644 arch/arm/plat-omap/include/plat/mailbox.h delete mode 100644 arch/arm/plat-omap/mailbox.c create mode 100644 drivers/mailbox/Kconfig create mode 100644 drivers/mailbox/Makefile create mode 100644 drivers/mailbox/mailbox-omap1.c create mode 100644 drivers/mailbox/mailbox-omap2.c create mode 100644 drivers/mailbox/mailbox.c create mode 100644 drivers/mailbox/mailbox.h create mode 100644 include/linux/mailbox.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the pm tree with the pci tree
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
arch/x86/pci/acpi.c between commit 3f385fa9edce ("x86/PCI: Ignore _SEG on
HP xw9300") from the pci tree and commit 97a7108a3c00 ("ACPI / x86: Add
quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info") from the pm
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/pci/acpi.c
index 49e5195,7010c19..000
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@@ -106,16 -98,16 +106,27 @@@ static const struct dmi_system_id pci_c
DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"),
},
},
+
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=15362 */
+ {
+ .callback = set_ignore_seg,
+ .ident = "HP xw9300",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP xw9300 Workstation"),
+ },
+ },
++
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=47981 */
+ {
+ .callback = set_nouse_crs,
+ .ident = "CheckPoint P-20-00",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "CheckPoint"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P-20-00"),
+ DMI_MATCH(DMI_BOARD_NAME, "Bridgeport"),
+ },
+ },
{}
};
pgp3RtiHPGQ5V.pgp
Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> Matthew Garrett writes: >> > No, in the general case the system will do that once it fails to find a >> > bootable OS on the drive. >> >> In the general case there will be a bootable OS on the drive. > > That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. Therefore inflicting the entire rest of the ecosystem with requirements that only exist in the union of the requirements for non-interactive installs and installs on a machine with an existing machine does not make sense. In situations where a non-interactive install is interesting. Aka an empty boot disk it is not interesting to guard against. In situations where interaction happens is where windows may already exists and so spoofing windows is a design consideration and and a user presence test does not break the design. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2] Support volatile range for anon vma
On 11/5/12 5:49 PM, Minchan Kim wrote: Also, memory allocators have a second motivation in using madvise: to create virtually contiguous regions of memory from a fragmented address space, without increasing the RSS. I don't get it. How do we create contiguos region by madvise? Just out of curiosity. Could you elaborate that use case? :) By using a new anonymous map and faulting pages in. The fragmented virtual memory is released via MADV_DONTNEED and if the malloc/free activity on the system is dominated by one process, chances are that the newly faulted in page is the one released by the same process :) The net effect is that physical pages within a single address space are rearranged so larger allocations can be satisfied. -Arun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: spear: Add stub functions for spear3[0|1|2]0_clk_init()
This fixes compile error if one of SPEAr3xx implementations is not selected.
CC drivers/clk/spear/spear3xx_clock.o
drivers/clk/spear/spear3xx_clock.c: In function 'spear3xx_clk_init':
drivers/clk/spear/spear3xx_clock.c:599:3: error: implicit declaration of
function 'spear300_clk_init' [-Werror=implicit-function-declaration]
drivers/clk/spear/spear3xx_clock.c:601:3: error: implicit declaration of
function 'spear310_clk_init' [-Werror=implicit-function-declaration]
drivers/clk/spear/spear3xx_clock.c:603:3: error: implicit declaration of
function 'spear320_clk_init' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/clk/spear/spear3xx_clock.o] Error 1
make[2]: *** [drivers/clk/spear] Error 2
make[1]: *** [drivers/clk] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin
---
drivers/clk/spear/spear3xx_clock.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/spear/spear3xx_clock.c
b/drivers/clk/spear/spear3xx_clock.c
index c315745..59049cf 100644
--- a/drivers/clk/spear/spear3xx_clock.c
+++ b/drivers/clk/spear/spear3xx_clock.c
@@ -157,6 +157,8 @@ static void __init spear300_clk_init(void)
1);
clk_register_clkdev(clk, NULL, "a000.kbd");
}
+#else
+static inline void spear300_clk_init(void) { }
#endif
/* array of all spear 310 clock lookups */
@@ -197,6 +199,8 @@ static void __init spear310_clk_init(void)
1);
clk_register_clkdev(clk, NULL, "b220.serial");
}
+#else
+static inline void spear310_clk_init(void) { }
#endif
/* array of all spear 320 clock lookups */
@@ -336,6 +340,8 @@ static void __init spear320_clk_init(void)
&_lock);
clk_register_clkdev(clk, NULL, "6010.serial");
}
+#else
+static inline void spear320_clk_init(void) { }
#endif
void __init spear3xx_clk_init(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
firmware issue: do_IRQ: X 55 No irq handler for vector (irq -1)
Hi, Firstly, this is a coreboot issue rather than kernel issue. I don't know how to deal with it so come here to ask for help. I am debugging coreboot which is an open source bios on a mainboard now. the mainboard is tyan s8226, which has two CPUs and each CPU has 8 cores. the details of s8226 could be googled. I can't insert link. I encountered a problem these days. The dmesg has such error: do_IRQ: X 55 No irq handler for vector (irq -1) where X is from 1 to 10 this message is printed by do_IRQ() in arch/x86/kernel/irq.c this is my coreboot issue, because other bios doesn't have this dmesg error. it seems that this error has no effect to the system. Linux works well now. But I want to resolve this issue. I am not familiar with linux kernel, so I don't know how to locate the problem. would anybody give me some suggestion? thank you! I can't send the whole dmesg, because it is rejected. I don't know why. -- WANG Siyuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/4] Add firmware signature file check
On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai wrote: > > To be noted, it doesn't support the firmwares via udev but only the > direct loading, and the check for built-in firmware is missing, too. Generally, both direct loading and udev may request one same firmware image. And after check failed, current firmware load will fallback on udev to complete loading, so looks a check-failed firmware still can be loaded into kernel no matter if there is firmware signature check or not. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] Re: [ 049/149] rtc: Disable the alarm in the hardware (v2)
On Mon, Nov 05, 2012 at 11:55:32PM +0100, Heinz Wiesinger wrote: > On Monday 05 November 2012 11:13:31 Greg KH wrote: > > On Mon, Nov 05, 2012 at 01:11:18AM -0800, Jonathan Nieder wrote: > > > Hi, > > > > > > In March, Greg KH wrote: > > > > 3.2-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > Sorry, I'm a little late. This seems to be causing spurious wakeups > > > after shutdown on some systems just like v1 did. :/ > > > > > > Janne Boman reports[1], using an HP EliteBook 8530w: > > > | I'm unable to shutdown my system via normal means. The system > > > | completes the shutdown process, all hardware lights are off, but then > > > | somehow it restarts. > > > > > > Based on a quick web search, Heinz Wiesinger, using the same model, > > > > > > ran into the same problem and bisected it to this patch: > > > https://bugzilla.kernel.org/show_bug.cgi?id=44261 > > > > > > Janne confirmed the same by testing kernels closely based on 3.2.13 > > > and 3.2.14 --- 3.2.13 shut down fine, while on 3.2.14 "shutdown -h > > > now" behaved roughly speaking like "reboot". A kernel close to 3.6.4 > > > was also affected. > > > > So is 3.6.6 still and issue? How about 3.7-rc4? 3.4.18? Figuring out > > if this is still an issue in Linus's tree would be the best thing to do > > first. > > I checked 3.7-rc4 and the issue is still there. Should I still test the other > versions as well? I can do so but it might take a bit. No, that should be good enough, this needs to be fixed there first. > If you need anything else, I'll be happy to help wherever I can. Working with the developers involved would be great. Anyone have any patches that Heinz could test? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC virtio-next 0/4] Introduce CAIF Virtio and reversed Vrings
Sjur Brændeland writes:
> Hi Rusty,
>
>> So, this adds another host-side virtqueue implementation.
>>
>> Can we combine them together conveniently? You pulled out more stuff
>> into vring.h which is a start, but it's a bit overloaded.
>> Perhaps we should separate the common fields into struct vring, and use
>> it to build:
>>
>> struct vring_guest {
>> struct vring vr;
>> u16 last_used_idx;
>> };
>>
>> struct vring_host {
>> struct vring vr;
>> u16 last_avail_idx;
>> };
>> I haven't looked closely at vhost to see what it wants, but I would
>> think we could share more code.
>
> I have played around with the code in vhost.c to explore your idea.
> The main issue I run into is that vhost.c is accessing user data while my new
> code does not. So I end up with some quirky code testing if the ring lives in
> user memory or not. Another issue is sparse warnings when
> accessing user memory.
Sparse is a servant, not a master. If that's the only thing stopping
us, we can ignore it (or hack around it).
> With your suggested changes I end up sharing about 100 lines of code.
> So in sum, I feel this add more complexity than what we gain by sharing.
>
> Below is an initial draft of the re-usable code. I added "is_uaccess" to
> struct
> virtio_ring in order to know if the ring lives in user memory.
>
> Let me know what you think.
Agreed, that's horrible...
Fortunately, recent GCCs will inline function pointers, so inlining this
and handing an accessor function gets optimized away.
I would really like this, because I'd love to have a config option to do
strict checking on the format of these things (similar to my recently
posted CONFIG_VIRTIO_DEVICE_TORTURE patch).
See below.
> int virtqueue_add_used(struct vring_host *vr, unsigned int head, int len,
> struct vring_used_elem **used)
> {
> /* The virtqueue contains a ring of used buffers. Get a pointer to the
>* next entry in that used ring. */
> *used = >vring.used->ring[vr->last_used_idx % vr->vring.num];
> if (vr->is_uaccess) {
> if(unlikely(__put_user(head, &(*used)->id))) {
> pr_debug("Failed to write used id");
> return -EFAULT;
> }
> if (unlikely(__put_user(len, &(*used)->len))) {
> pr_debug("Failed to write used len");
> return -EFAULT;
> }
> smp_wmb();
> if (__put_user(vr->last_used_idx + 1,
> >vring.used->idx)) {
> pr_debug("Failed to increment used idx");
> return -EFAULT;
> }
> } else {
> (*used)->id = head;
> (*used)->len = len;
> smp_wmb();
> vr->vring.used->idx = vr->last_used_idx + 1;
> }
> vr->last_used_idx++;
> return 0;
> }
/* Untested! */
static inline bool in_kernel_put(u32 *dst, u32 v)
{
*dst = v;
return true;
}
static inline bool userspace_put(u32 *dst, u32 v)
{
return __put_user(dst, v) == 0;
}
static inline struct vring_used_elem *vrh_add_used(struct vring_host *vr,
unsigned int head, u32 len,
bool (*put)(u32 *dst, u32 v))
{
struct vring_used_elem *used;
/* The virtqueue contains a ring of used buffers. Get a pointer to the
* next entry in that used ring. */
used = >vring.used->ring[vr->last_used_idx % vr->vring.num];
if (!put(>id, head) || !put(>len = len))
return NULL;
smp_wmb();
if (!put(>vring.used->idx, vr->last_used_idx + 1))
return NULL;
vr->last_used_idx++;
return used;
}
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv8 0/3]virtio_console: Add rproc_serial driver
Amit Shah writes: > On (Mon) 05 Nov 2012 [11:31:24], Amit Shah wrote: >> On (Mon) 05 Nov 2012 [09:11:45], Rusty Russell wrote: >> > Sjur Brændeland writes: >> > >> > > From: Sjur Brændeland >> > > >> > > This patch-set introduces a new virtio type "rproc_serial" for >> > > communicating >> > > with remote processors over shared memory. The driver depends on the >> > > the remoteproc framework. As preparation for introducing "rproc_serial" >> > > I've done a refactoring of the transmit buffer handling. >> > > >> > > Changes since v7: >> > > - Rebased to virtio-next branch. >> > > - Removed extra added lines. >> > > - Removed superfluous checks before calling reclaim_dma_bufs(). >> > > - Rusty raised some question regarding garbage collection of the >> > > out-vq, so I moved this into a separate patch. >> > >> > OK, I'm not sure that WARN_ON won't fire, but that's not all that >> > harmful. >> >> Sjur said he'll send out a respin for this; can you wait for his v8? > > Er, v9. > > Amit Yep, they're in my pending-rebases tree now. Though no need to repost the whole series; just the changes please. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] utilize _Static_assert() for BUILD_BUG_ON() when the compiler supports it
Andrew Morton writes:
> On Fri, 02 Nov 2012 14:47:40 +
> "Jan Beulich" wrote:
>
>> This makes the resulting diagnostics quite a bit more useful.
>
> So asserts Jan, but to confirm it I would need to download, configure,
> build and install a different gcc version, which sounds rather a hassle.
>
> So, please show us an exmple of these diagnostics in the changelog.
>
>> --- 3.7-rc3/include/linux/bug.h
>> +++ 3.7-rc3-static-assert/include/linux/bug.h
>> @@ -27,8 +27,15 @@ struct pt_regs;
>> result (of value 0 and type size_t), so the expression can be used
>> e.g. in a structure initializer (or where-ever else comma expressions
>> aren't permitted). */
>> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
>
> This sort of logic is normally performed via the
> include/linux/compiler*.h system. And
>
> grep __GNUC include/linux/*.h
>
> indicates that we've been pretty successful. Can we do that here too?
>
> (eg: suppose the Intel compiler supports _Static_assert?)
Yeah, there are a lot of goodies here:
_Static_assert:
We could define __ASSERT_STRUCT_FIELD(e) for this:
#define BUILD_BUG_ON_ZERO(e) \
sizeof(struct { __ASSERT_STRUCT_FIELD(e); })
__COUNTER__:
Used to make a unique id. Let's define __UNIQUE_ID(prefix) for
this (using __COUNTER__ or __LINE__). 4.3 and above.
__compiletime_error():
I blame Arjan for this. It disappears if not implemented, which
is just lazy. BUILD_BUG_ON() does this right, and he didn't fix
that at the time :(
I'd say we have three patches here, really:
1) Add __ASSERT_STRUCT_FIELD(e) to compiler.h
2) Add __UNIQUE_ID().
3) Use them (I can think of at least one other place for __UNIQUE_ID()).
Jan, do you want the glory? :) If not, I'll respin.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] MODSIGN: Only sign modules if built in-tree
Josh Boyer writes: > On Mon, Nov 05, 2012 at 12:31:39PM +1030, Rusty Russell wrote: >> Josh Boyer writes: >> > diff --git a/Makefile b/Makefile >> > index 14c93b3..7e27d51 100644 >> > --- a/Makefile >> > +++ b/Makefile >> > @@ -722,8 +722,14 @@ export mod_strip_cmd >> > ifeq ($(CONFIG_MODULE_SIG),y) >> > MODSECKEY = ./signing_key.priv >> > MODPUBKEY = ./signing_key.x509 >> > +ifeq ($(KBUILD_EXTMOD),) >> > +SIGNFAIL = false >> > +else >> > +# External builds might not have a signing key, don't break >> > module_install. >> > +SIGNFAIL = true >> > +endif # KBUILD_EXTMOD >> > export MODPUBKEY >> > -mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) >> > +mod_sign_cmd = $(SIGNFAIL) || perl $(srctree)/scripts/sign-file >> > $(MODSECKEY) $(MODPUBKEY) >> > else >> > mod_sign_cmd = true >> > endif >> >> Huh? 'true || perl' never runs perl due to short circuiting. > > Ah. Maybe you were going for "sign all modules if keys are available, > but don't break external if they aren't" semantics. I was just skipping > it entirely for external modules. Exactly. This way you get warnings, not failure. You probably want that, since you'll (at least) taint your kernel when you load those modules. I've applied this in my fixes branch, will push to Linus later this week. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 8/8] x86/lguest: Use __pa_symbol instead of __pa on C visible symbols
Alexander Duyck writes: > The function lguest_write_cr3 is using __pa to convert swapper_pg_dir and > initial_page_table from virtual addresses to physical. The correct function > to use for these values is __pa_symbol since they are C visible symbols. > > Cc: Rusty Russell > Signed-off-by: Alexander Duyck Acked-by: Rusty Russell Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the pci tree
Hi Greg, On Tue, 6 Nov 2012 02:55:42 +0100 Greg Kroah-Hartman wrote: > > It is gone in my tree, and it should be deleted in yours, do you not see > that? Unfortunately, your tree gets merged late in my set of trees ... so I'll just keep the disabling patch and the problem will go away eventually. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpoBZLUam4IZ.pgp Description: PGP signature
Re: [PATCH v11] kvm: notify host when the guest is panicked
On Tue, Oct 30, 2012 at 10:30:02PM -0400, Sasha Levin wrote: > On Tue, Oct 30, 2012 at 9:48 PM, Wen Congyang wrote: > > At 10/31/2012 09:12 AM, Marcelo Tosatti Wrote: > >> It has been asked earlier why a simple virtio device is not usable > >> for this (with no response IIRC). > > > > 1. We can't use virtio device when the kernel is booting. > > So the issue here is the small window between the point the guest > becomes "self aware" and to the point virtio drivers are loaded, > right? > > I agree that if something happens during that interval, a > "virtio-notifier" driver won't catch that, but anything beyond that is > better done with a virtio driver, so how is the generic infrastructure > added in this patch useful to anything beyond detecting panics in that > initial interval? Another point is dependency. To make panic notification more reliable, we have to reduce its dependency on other parts of kernel as possible as we can. > > > 2. The virtio's driver can be built as a module, and if it is not loaded > >and the kernel is panicked, there is no way to notify the host. > > Even if the suggested virtio-notifier driver is built as a module, it > would get auto-loaded when the guest is booting, so I'm not sure about > this point? > > > 3. I/O port is more reliable than virtio device. > >If virtio's driver has some bug, and it cause kernel panicked, we can't > >use it. The I/O port is more reliable because it only depends on notifier > >chain(If we use virtio device, it also depends on notifier chain). > > This is like suggesting that we let KVM emulate virtio-blk on it's > own, parallel to the virtio implementation, so that even if there's a > problem with virtio-blk, KVM can emulate a virtio-blk on it's own. Not the same. On virtio-blk, if we can make use of virtio, why not? If there is a problem of virtio-blk but caused by virtio itself, just fix it in virtio. But in the case of panic notification, more dependency means more chances of failure of panic notification. Say, if we use a virtio device to do panic notification, then we will fail if: virtio itself has problems, virtio for some reason can't be deployed(neither built-in or as a module), or guest doesn't support virtio, etc. We choose IO because compared to virtio device, it is not that heavy and less problematic. > > Furthermore, why stop at virtio? What if the KVM code has a bug and it > doesn't pass IO properly? Or the x86 code? we still want panic > notifications if that happens... Better ideas are welcome. -- Thanks, Hu Tao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 103/104] mm: remove depends on CONFIG_EXPERIMENTAL
On Mon, Nov 5, 2012 at 5:54 PM, Kees Cook wrote: > On Mon, Nov 5, 2012 at 5:22 PM, David Rientjes wrote: >> On Mon, 5 Nov 2012, Kees Cook wrote: >> >>> diff --git a/mm/Kconfig b/mm/Kconfig >>> index a3f8ddd..679945e 100644 >>> --- a/mm/Kconfig >>> +++ b/mm/Kconfig >>> @@ -1,6 +1,5 @@ >>> config SELECT_MEMORY_MODEL >>> def_bool y >>> - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL >>> >>> choice >>> prompt "Memory model" >> >> I thought you agreed to only drop EXPERIMENTAL here in >> http://marc.info/?l=linux-kernel=135103415901094 and leave >> ARCH_SELECT_MEMORY_MODEL, which you've orphaned with the above, for phase >> two of your effort? > > Ah! Yes, thanks. I'll restore that. Wait, no. This is an "OR". ARCH_SELECT_MEMORY_MODEL has no affect on SELECT_MEMORY_MODEL if EXPERIMENTAL is always considered on. My proposal was to deal with ARCH_SELECT_MEMORY_MODEL separately. Did I misunderstand something? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the pci tree
On Tue, Nov 06, 2012 at 11:27:29AM +1100, Stephen Rothwell wrote:
> Hi Bjorn,
>
> After merging the pci tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/telephony/ixj.c: In function 'ixj_probe_pci':
> drivers/staging/telephony/ixj.c:7732:13: warning: assignment makes integer
> from pointer without a cast [enabled by default]
> drivers/staging/telephony/ixj.c:7732:38: error: expected ';' before
> 'pci_resource_start'
>
> Exposed by commit 545974a28f78 ("PCI: Convert pci_resource_ macros to
> static inlines"). The macro version of pci_resource_start() made this
> RHS look like a function call and now it isn't.
>
> Maybe it is time this driver just went away.
It is gone in my tree, and it should be deleted in yours, do you not see
that?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 103/104] mm: remove depends on CONFIG_EXPERIMENTAL
On Mon, Nov 5, 2012 at 5:22 PM, David Rientjes wrote: > On Mon, 5 Nov 2012, Kees Cook wrote: > >> diff --git a/mm/Kconfig b/mm/Kconfig >> index a3f8ddd..679945e 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -1,6 +1,5 @@ >> config SELECT_MEMORY_MODEL >> def_bool y >> - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL >> >> choice >> prompt "Memory model" > > I thought you agreed to only drop EXPERIMENTAL here in > http://marc.info/?l=linux-kernel=135103415901094 and leave > ARCH_SELECT_MEMORY_MODEL, which you've orphaned with the above, for phase > two of your effort? Ah! Yes, thanks. I'll restore that. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2] Support volatile range for anon vma
Hello, On Mon, Nov 05, 2012 at 03:54:43PM -0800, Arun Sharma wrote: > On Wed, Oct 31, 2012 at 06:56:05PM -0400, KOSAKI Motohiro wrote: > > glibc malloc discard freed memory by using MADV_DONTNEED > > as tcmalloc. and it is often a source of large performance decrease. > > because of MADV_DONTNEED discard memory immediately and > > right after malloc() call fall into page fault and pagesize memset() path. > > then, using DONTNEED increased zero fill and cache miss rate. > > The memcg based solution that I posted a few months ago is working well > for us. We see significantly less cpu in zero'ing pages. > > Not everyone was comfortable with the security implications of recycling > pages between processes in a memcg, although it was disabled by default > and had to be explicitly opted-in. > > Also, memory allocators have a second motivation in using madvise: to > create virtually contiguous regions of memory from a fragmented address > space, without increasing the RSS. I don't get it. How do we create contiguos region by madvise? Just out of curiosity. Could you elaborate that use case? :) > > -Arun > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind Regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] tasklet: ignore disabled tasklet in tasklet_action
On Tue, 6 Nov 2012 09:22:16 +0800 Xiaotian Feng wrote: > On Tue, Nov 6, 2012 at 6:52 AM, Andrew Morton > wrote: > > On Fri, 2 Nov 2012 10:48:54 +0800 > > Xiaotian Feng wrote: > > > >> We met a ksoftirqd 100% issue, the perf top shows kernel is busy > >> with tasklet_action(), but no actual action is shown. From dumped > >> kernel, there's only one disabled tasklet on the tasklet_vec. > >> > >> tasklet_action might be handled after tasklet is disabled, this will > >> make disabled tasklet stayed on tasklet_vec. tasklet_action will not > >> handle disabled tasklet, but place it on the tail of tasklet_vec, > >> still raise softirq for this tasklet. Things will become worse if > >> device driver uses tasklet_disable on its device remove/close code. > >> The disabled tasklet will stay on the vec, frequently __raise_softirq_off() > >> and make ksoftirqd wakeup even if no tasklets need to be handled. > >> > >> This patch introduced a new TASKLET_STATE_HI bit to indicate HI_SOFTIRQ, > >> in tasklet_action(), simply ignore the disabled tasklet and don't raise > >> the softirq nr. In my previous patch, I remove tasklet_hi_enable() since > >> it is the same as tasklet_enable(). So only tasklet_enable() needs to be > >> modified, if tasklet state is changed from disable to enable, use > >> __tasklet_schedule() to put it on the right vec. > > > > gee, I haven't looked at the tasklet code in 100 years. I think I'll > > send this in Thomas's direction ;) > > > > The race description seems real and the patch looks sane to me. Are > > you sure we can get away with never clearing TASKLET_STATE_HI? For > > example, what would happen if code does a tasklet_hi_schedule(t) and > > later does a tasklet_schedule(t)? > > hmm, that will be a nightmare... > tasklet_schedule(t)/tasklet_hi_schedule(t) doesn't use list_head, they > simply > make t->next = NULL, then put t on the tail of > tasklet_vec/tasklet_hi_vec. If the code does a tasklet_hi_schedule() > and then a tasklet_schedule, the tasklet will stay on tasklet_vec and > tasklet_hi_vec tasklet_hi_action will handle it first and clear > the TASKLET_SCHED_SCHED bit, later, in tasklet_action, it will be > handled again and hit a BUG_ON ... Well, actually I meant if the caller reuses the tassklet_struct after its softirq has been run. > But if code does a tasklet_hi_schedule(), then tasklet_kil and later > does a tasklet_schedule(), we do need clear the TASKLET_STATE_HI. That as well ;) > Also > we need to remove the tasklet_hi_enable() as it is the same as > tasklet_enable() and there's > only one user.. > > I'll send you V2 patch soon, thanks. Sounds good. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tmpfs: change final i_blocks BUG to WARNING
Under a particular load on one machine, I have hit shmem_evict_inode()'s BUG_ON(inode->i_blocks), enough times to narrow it down to a particular race between swapout and eviction. It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(), and the lack of coherent locking between mapping's nrpages and shmem's swapped count. There's a window in shmem_writepage(), between lowering nrpages in shmem_delete_from_page_cache() and then raising swapped count, when the freed count appears to be +1 when it should be 0, and then the asymmetry stops it from being corrected with -1 before hitting the BUG. One answer is coherent locking: using tree_lock throughout, without info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on used_blocks makes that messier than expected. Another answer may be a further effort to eliminate the weird shmem_recalc_inode() altogether, but previous attempts at that failed. So far undecided, but for now change the BUG_ON to WARN_ON: in usual circumstances it remains a useful consistency check. Signed-off-by: Hugh Dickins Cc: sta...@vger.kernel.org --- mm/shmem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 3.7-rc4/mm/shmem.c 2012-10-14 16:16:58.361309122 -0700 +++ linux/mm/shmem.c2012-11-01 14:31:04.288185742 -0700 @@ -643,7 +643,7 @@ static void shmem_evict_inode(struct ino kfree(info->symlink); simple_xattrs_free(>xattrs); - BUG_ON(inode->i_blocks); + WARN_ON(inode->i_blocks); shmem_free_inode(inode->i_sb); clear_inode(inode); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tmpfs: fix shmem_getpage_gfp VM_BUG_ON
Fuzzing with trinity hit the "impossible" VM_BUG_ON(error)
(which Fedora has converted to WARNING) in shmem_getpage_gfp():
WARNING: at mm/shmem.c:1151 shmem_getpage_gfp+0xa5c/0xa70()
Pid: 29795, comm: trinity-child4 Not tainted 3.7.0-rc2+ #49
Call Trace:
[] warn_slowpath_common+0x7f/0xc0
[] warn_slowpath_null+0x1a/0x20
[] shmem_getpage_gfp+0xa5c/0xa70
[] shmem_fault+0x4f/0xa0
[] __do_fault+0x71/0x5c0
[] handle_pte_fault+0x97/0xae0
[] handle_mm_fault+0x289/0x350
[] __do_page_fault+0x18e/0x530
[] do_page_fault+0x2b/0x50
[] page_fault+0x28/0x30
[] tracesys+0xe1/0xe6
Thanks to Johannes for pointing to truncation: free_swap_and_cache()
only does a trylock on the page, so the page lock we've held since
before confirming swap is not enough to protect against truncation.
What cleanup is needed in this case? Just delete_from_swap_cache(),
which takes care of the memcg uncharge.
Reported-by: Dave Jones
Hypothesis-by: Johannes Weiner
Signed-off-by: Hugh Dickins
Cc: sta...@vger.kernel.org
---
mm/shmem.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
--- 3.7-rc4/mm/shmem.c 2012-10-14 16:16:58.361309122 -0700
+++ linux/mm/shmem.c2012-11-01 14:31:04.288185742 -0700
@@ -1145,8 +1145,22 @@ repeat:
if (!error) {
error = shmem_add_to_page_cache(page, mapping, index,
gfp, swp_to_radix_entry(swap));
- /* We already confirmed swap, and make no allocation */
- VM_BUG_ON(error);
+ /*
+* We already confirmed swap under page lock, and make
+* no memory allocation here, so usually no possibility
+* of error; but free_swap_and_cache() only trylocks a
+* page, so it is just possible that the entry has been
+* truncated or holepunched since swap was confirmed.
+* shmem_undo_range() will have done some of the
+* unaccounting, now delete_from_swap_cache() will do
+* the rest (including mem_cgroup_uncharge_swapcache).
+* Reset swap.val? No, leave it so "failed" goes back to
+* "repeat": reading a hole and writing should succeed.
+*/
+ if (error) {
+ VM_BUG_ON(error != -ENOENT);
+ delete_from_swap_cache(page);
+ }
}
if (error)
goto failed;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: fix a regression with HIGHMEM introduced by changeset 7f1290f2f2a4d
Changeset 7f1290f2f2 tries to fix a issue when calculating
zone->present_pages, but it causes a regression to 32bit systems with
HIGHMEM. With that changeset, function reset_zone_present_pages()
resets all zone->present_pages to zero, and fixup_zone_present_pages()
is called to recalculate zone->present_pages when boot allocator frees
core memory pages into buddy allocator. Because highmem pages are not
freed by bootmem allocator, all highmem zones' present_pages becomes
zero.
Actually there's no need to recalculate present_pages for highmem zone
because bootmem allocator never allocates pages from them. So fix the
regression by skipping highmem in function reset_zone_present_pages()
and fixup_zone_present_pages().
Signed-off-by: Jiang Liu
Signed-off-by: Jianguo Wu
Reported-by: Maciej Rutecki
Tested-by: Maciej Rutecki
Cc: Chris Clayton
Cc: Rafael J. Wysocki
Cc: Andrew Morton
Cc: Mel Gorman
Cc: Minchan Kim
Cc: KAMEZAWA Hiroyuki
Cc: Michal Hocko
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
Hi Maciej,
Thanks for reporting and bisecting. We have analyzed the regression
and worked out a patch for it. Could you please help to verify whether it
fix the regression?
Thanks!
Gerry
---
mm/page_alloc.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5b74de6..2311f15 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6108,7 +6108,8 @@ void reset_zone_present_pages(void)
for_each_node_state(nid, N_HIGH_MEMORY) {
for (i = 0; i < MAX_NR_ZONES; i++) {
z = NODE_DATA(nid)->node_zones + i;
- z->present_pages = 0;
+ if (!is_highmem(z))
+ z->present_pages = 0;
}
}
}
@@ -6123,10 +6124,11 @@ void fixup_zone_present_pages(int nid, unsigned long
start_pfn,
for (i = 0; i < MAX_NR_ZONES; i++) {
z = NODE_DATA(nid)->node_zones + i;
+ if (is_highmem(z))
+ continue;
+
zone_start_pfn = z->zone_start_pfn;
zone_end_pfn = zone_start_pfn + z->spanned_pages;
-
- /* if the two regions intersect */
if (!(zone_start_pfn >= end_pfn || zone_end_pfn <= start_pfn))
z->present_pages += min(end_pfn, zone_end_pfn) -
max(start_pfn, zone_start_pfn);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How about a gpio_get(device *, char *) function?
On Tuesday 06 November 2012 01:35:11 Stephen Warren wrote: > On 11/04/2012 11:04 AM, Linus Walleij wrote: > > On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote: > >> Would anyone be opposed to having a gpio_get() function that works > >> similarly to e.g. regulator_get() and clk_get()? > > > > I understand the concept and why you want to do this. > > > > However I think the global GPIO numberspace defeats the > > purpose. > > > > gpio_get() should get an abstract handle just like clk_get() or > > regulator_get(), not a fixed numeral. > > I don't really see why the return type of gpio_get() influences whether > it can be implemented or not. > > If gpio_get() were implemented today, it could return an integer with > the same value as any other GPIO functions use already. > > With board files, some "gpio map" table would simply contain the same > int GPIO ID value the table as is used anywhere else already. With DT, > the same xlate function would translate from DT GPIO-chip-relative > IDs/specifiers into the global number space in the same way that we do > today via other APIs. > > If the GPIO subsystem were reworked as you propose, this API could be > reworked in exactly the same way, or if implemented after the rework, it > would return whatever handle type was in use at the time. How about, in a first time (and because I'd also like to get the power seqs moving on), a typedef from int to gpio_handle_t and a first implementation of the gpio_handle_*() API that would just call the existing integer-based API (apart from gpio_handle_get())? That way things will not break when we switch to a real handle. Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] create sun sysfs file
Yasuaki, Please refresh this patch on top of linux-next and re-send to Rafael. I've dropped it from my tree. thanks, -Len On 10/10/2012 10:52 PM, Len Brown wrote: > v5 applied (with typo fixed). > In the future, it would be better if your patches apply to the latest > upstream kernel. (_STR made changes in same place as _SUN) > > thanks, > Len Brown, Intel Open Source Technology Center > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the v4l-dvb tree
Hi Stephen,
Em Mon, 5 Nov 2012 11:34:09 +1100
Stephen Rothwell escreveu:
> Hi Mauro,
>
> On Mon, 29 Oct 2012 11:14:03 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the v4l-dvb tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/hid/hid-picolcd_cir.c: In function 'picolcd_init_cir':
> > drivers/hid/hid-picolcd_cir.c:119:27: error: 'RC_TYPE_ALL' undeclared
> > (first use in this function)
> >
> > Caused by commit c003ab1bedf0 ("[media] rc-core: add separate defines for
> > protocol bitmaps and numbers"). The new reference was introduced in
> > commit ae08e324146c ("HID: picoLCD: Add support for CIR") which was
> > merged by Linus on October 2 into v3.7-rc1 via the hid tree.
> >
> > I have used the v4l-dvb tree from next-20121026 for today.
>
> I still get this today.
Not sure what happened, as I think I pushed it on my -next tree. I'm abroad
this week for LinuxCon Europe. Unfortunately, hotel's network blocks almost all
TCP ports, except for web ports. I'm seeing if this can be fixed tomorrow.
If so, I'll be pushing the patches tomorrow night.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/16] mm: use vm_unmapped_area() on sparc32 architecture
From: Michel Lespinasse Date: Mon, 5 Nov 2012 14:47:12 -0800 > Update the sparc32 arch_get_unmapped_area function to make use of > vm_unmapped_area() instead of implementing a brute force search. > > Signed-off-by: Michel Lespinasse Hmmm... > - if (flags & MAP_SHARED) > - addr = COLOUR_ALIGN(addr); > - else > - addr = PAGE_ALIGN(addr); What part of vm_unmapped_area() is going to duplicate this special aligning logic we need on sparc? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 103/104] mm: remove depends on CONFIG_EXPERIMENTAL
On Mon, 5 Nov 2012, Kees Cook wrote: > diff --git a/mm/Kconfig b/mm/Kconfig > index a3f8ddd..679945e 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -1,6 +1,5 @@ > config SELECT_MEMORY_MODEL > def_bool y > - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL > > choice > prompt "Memory model" I thought you agreed to only drop EXPERIMENTAL here in http://marc.info/?l=linux-kernel=135103415901094 and leave ARCH_SELECT_MEMORY_MODEL, which you've orphaned with the above, for phase two of your effort? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] tasklet: ignore disabled tasklet in tasklet_action
On Tue, Nov 6, 2012 at 6:52 AM, Andrew Morton wrote: > On Fri, 2 Nov 2012 10:48:54 +0800 > Xiaotian Feng wrote: > >> We met a ksoftirqd 100% issue, the perf top shows kernel is busy >> with tasklet_action(), but no actual action is shown. From dumped >> kernel, there's only one disabled tasklet on the tasklet_vec. >> >> tasklet_action might be handled after tasklet is disabled, this will >> make disabled tasklet stayed on tasklet_vec. tasklet_action will not >> handle disabled tasklet, but place it on the tail of tasklet_vec, >> still raise softirq for this tasklet. Things will become worse if >> device driver uses tasklet_disable on its device remove/close code. >> The disabled tasklet will stay on the vec, frequently __raise_softirq_off() >> and make ksoftirqd wakeup even if no tasklets need to be handled. >> >> This patch introduced a new TASKLET_STATE_HI bit to indicate HI_SOFTIRQ, >> in tasklet_action(), simply ignore the disabled tasklet and don't raise >> the softirq nr. In my previous patch, I remove tasklet_hi_enable() since >> it is the same as tasklet_enable(). So only tasklet_enable() needs to be >> modified, if tasklet state is changed from disable to enable, use >> __tasklet_schedule() to put it on the right vec. > > gee, I haven't looked at the tasklet code in 100 years. I think I'll > send this in Thomas's direction ;) > > The race description seems real and the patch looks sane to me. Are > you sure we can get away with never clearing TASKLET_STATE_HI? For > example, what would happen if code does a tasklet_hi_schedule(t) and > later does a tasklet_schedule(t)? hmm, that will be a nightmare... tasklet_schedule(t)/tasklet_hi_schedule(t) doesn't use list_head, they simply make t->next = NULL, then put t on the tail of tasklet_vec/tasklet_hi_vec. If the code does a tasklet_hi_schedule() and then a tasklet_schedule, the tasklet will stay on tasklet_vec and tasklet_hi_vec tasklet_hi_action will handle it first and clear the TASKLET_SCHED_SCHED bit, later, in tasklet_action, it will be handled again and hit a BUG_ON ... But if code does a tasklet_hi_schedule(), then tasklet_kil and later does a tasklet_schedule(), we do need clear the TASKLET_STATE_HI. Also we need to remove the tasklet_hi_enable() as it is the same as tasklet_enable() and there's only one user.. I'll send you V2 patch soon, thanks. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] hrtimer: Printing timer info when hitting BUG_ON()
On Tue, 2012-10-30 at 18:27 +0800, Chuansheng Liu wrote:
> We encounted one BUG_ON() issue at function __run_hrtimer(),
> but the panic info is not enough to find out which hrtimer
> users use the hrtimer wrongly.
> (in this BUG_ON case, it is callback running at the same time
> hrtimer_start() is executed on different context.)
>
> We can print basic timer info before BUG(), it is easy to find
> out which hrtimer user has fault, the output info is like below:
>
> <3>[ 41.118552] timer info: state/3, func/test_timer_cb
> <3>[ 41.118618] timer stats: pid/786(sh), site/hrtimer_start
> <0>[ 41.118670] [ cut here ]
> <2>[ 41.118691] kernel BUG at
> /root/r4_code/hardware/intel/linux-2.6/kernel/hrtimer.c:1260!
> <0>[ 41.118715] invalid opcode: [#1] PREEMPT SMP
>
> The infos of callback/state are very helpful for debugging this BUG_ON().
It's a useful patch.
Thomas,
Could you merge it into your testing tree, so other developers could also
benefit from it?
Thanks all.
Yanmin
>
> Signed-off-by: Li Fei
> Signed-off-by: liu chuansheng
> ---
> kernel/hrtimer.c | 21 -
> 1 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 6db7a5e..0618eaf 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1204,6 +1204,22 @@ int hrtimer_get_res(const clockid_t which_clock,
> struct timespec *tp)
> }
> EXPORT_SYMBOL_GPL(hrtimer_get_res);
>
> +/*
> + * dump_hrtimer_callinfo - print hrtimer information including:
> + * state, callback function, pid and start_site.
> +*/
> +static void dump_hrtimer_callinfo(struct hrtimer *timer)
> +{
> +
> + pr_err("timer info: state/%lx, func/%pf\n",
> + timer->state, timer->function);
> +
> +#ifdef CONFIG_TIMER_STATS
> + pr_err("timer stats: pid/%d(%s), site/%pf\n",
> + timer->start_pid, timer->start_comm, timer->start_site);
> +#endif
> +}
> +
> static void __run_hrtimer(struct hrtimer *timer, ktime_t *now)
> {
> struct hrtimer_clock_base *base = timer->base;
> @@ -1235,7 +1251,10 @@ static void __run_hrtimer(struct hrtimer *timer,
> ktime_t *now)
>* hrtimer_start_range_ns() or in hrtimer_interrupt()
>*/
> if (restart != HRTIMER_NORESTART) {
> - BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
> + if (timer->state != HRTIMER_STATE_CALLBACK) {
> + dump_hrtimer_callinfo(timer);
> + BUG();
> + }
> enqueue_hrtimer(timer, base);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ledtrig-cpu: kill useless mutex to fix sleep in atomic context
On Mon, Nov 5, 2012 at 6:20 AM, Nathan Lynch wrote:
> Seeing the following every time the CPU enters or leaves idle on a
> Beagleboard:
>
> BUG: sleeping function called from invalid context at kernel/mutex.c:269
> in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
> no locks held by swapper/0/0.
> [] (unwind_backtrace+0x0/0xf8) from []
> (mutex_lock_nested+0x24/0x380)
> [] (mutex_lock_nested+0x24/0x380) from []
> (ledtrig_cpu+0x38/0x88)
> [] (ledtrig_cpu+0x38/0x88) from [] (cpu_idle+0xf4/0x120)
> [] (cpu_idle+0xf4/0x120) from []
> (start_kernel+0x2bc/0x30c)
>
> Miles Lane has reported seeing similar splats during system suspend.
>
> The mutex in struct led_trigger_cpu appears to have no function: it
> resides in a per-cpu data structure which never changes after the
> trigger is registered. So just remove it.
>
> Reported-by: Miles Lane
> Signed-off-by: Nathan Lynch
Thanks, I also think we probable don't need this locking for per CPU
data. But if I'm wrong please correct me.
I will merge this and send to Linus soon.
-Bryan
> ---
> drivers/leds/ledtrig-cpu.c | 21 -
> 1 file changed, 21 deletions(-)
>
> diff --git a/drivers/leds/ledtrig-cpu.c b/drivers/leds/ledtrig-cpu.c
> index b312056..4239b39 100644
> --- a/drivers/leds/ledtrig-cpu.c
> +++ b/drivers/leds/ledtrig-cpu.c
> @@ -33,8 +33,6 @@
> struct led_trigger_cpu {
> char name[MAX_NAME_LEN];
> struct led_trigger *_trig;
> - struct mutex lock;
> - int lock_is_inited;
> };
>
> static DEFINE_PER_CPU(struct led_trigger_cpu, cpu_trig);
> @@ -50,12 +48,6 @@ void ledtrig_cpu(enum cpu_led_event ledevt)
> {
> struct led_trigger_cpu *trig = &__get_cpu_var(cpu_trig);
>
> - /* mutex lock should be initialized before calling mutex_call() */
> - if (!trig->lock_is_inited)
> - return;
> -
> - mutex_lock(>lock);
> -
> /* Locate the correct CPU LED */
> switch (ledevt) {
> case CPU_LED_IDLE_END:
> @@ -75,8 +67,6 @@ void ledtrig_cpu(enum cpu_led_event ledevt)
> /* Will leave the LED as it is */
> break;
> }
> -
> - mutex_unlock(>lock);
> }
> EXPORT_SYMBOL(ledtrig_cpu);
>
> @@ -117,14 +107,9 @@ static int __init ledtrig_cpu_init(void)
> for_each_possible_cpu(cpu) {
> struct led_trigger_cpu *trig = _cpu(cpu_trig, cpu);
>
> - mutex_init(>lock);
> -
> snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu);
>
> - mutex_lock(>lock);
> led_trigger_register_simple(trig->name, >_trig);
> - trig->lock_is_inited = 1;
> - mutex_unlock(>lock);
> }
>
> register_syscore_ops(_cpu_syscore_ops);
> @@ -142,15 +127,9 @@ static void __exit ledtrig_cpu_exit(void)
> for_each_possible_cpu(cpu) {
> struct led_trigger_cpu *trig = _cpu(cpu_trig, cpu);
>
> - mutex_lock(>lock);
> -
> led_trigger_unregister_simple(trig->_trig);
> trig->_trig = NULL;
> memset(trig->name, 0, MAX_NAME_LEN);
> - trig->lock_is_inited = 0;
> -
> - mutex_unlock(>lock);
> - mutex_destroy(>lock);
> }
>
> unregister_syscore_ops(_cpu_syscore_ops);
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
