Re: [PATCH V2] spi: tegra: add spi driver for SLINK controller
On Tuesday 30 October 2012 12:44 AM, Stephen Warren wrote:
On 10/29/2012 11:18 AM, Laxman Dewangan wrote:
Tegra20/Tegra30 supports the spi interface through its SLINK
controller. Add spi driver for SLINK controller.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
+config SPI_TEGRA20_SLINK
+ tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
+ depends on ARCH_TEGRA&& TEGRA20_APB_DMA
I think it depends on DMAENGINE, not the specific driver now, doesn't it?
I saw in MFD where the dependent driver depends on the actual drver, not
on core. Also this driver need apb dma and hence if there is other dma
driver based on dmaengine, not apb dma then this driver should not get
invoked.
+ tegra_slink_writel(tspi, x, SLINK_TX_FIFO);
+ }
+ }
The if and the else there are basically identical now. Can't the else
branch simply be replaced by the if branch? At most I think the
difference comes down to max_n_32bit v.s. fifo_words_left calculations
being slight different; everything else is the same.
I suppose this isn't a big deal though; we could clean it up later if
necessary.
I like to do later.
+ tegra_slink_writel(tspi, val, SLINK_DMA_CTL);
+ udelay(1);
+ wmb();
Why the udelay() and wmb()?
Udelay() is required as suggested by ASIC.
wmb() is lying in our downstream code and hence it is here but I think
it is not require now.
+ return tegra_slink_clk_prepare(tspi);
+}
Why not move the body of tegra_slink_clk_{un,prepare} inside those
functions, since they're only called from those functions?
Fine, I will do.
+MODULE_ALIAS("platform:tegra_slink-slink");
I think that's a typo.
I will fix this typo.
Thanks,
Laxman
--
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] hwmon: da9055: Fix chan_mux[DA9055_ADC_ADCIN3] setting
On Mon, Oct 29, 2012 at 04:34:38PM +0800, Axel Lin wrote:
> Set chan_mux[DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3.
>
> Signed-off-by: Axel Lin
> ---
> Hi,
> This looks like a typo, but I don't have a hardware to test it.
> Axel
> drivers/hwmon/da9055-hwmon.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/da9055-hwmon.c b/drivers/hwmon/da9055-hwmon.c
> index 0b41f2c..3a3377c 100644
> --- a/drivers/hwmon/da9055-hwmon.c
> +++ b/drivers/hwmon/da9055-hwmon.c
> @@ -54,7 +54,7 @@ static const u8 chan_mux[DA9055_ADC_TJUNC + 1] = {
> [DA9055_ADC_VSYS] = DA9055_ADC_MUX_VSYS,
> [DA9055_ADC_ADCIN1] = DA9055_ADC_MUX_ADCIN1,
> [DA9055_ADC_ADCIN2] = DA9055_ADC_MUX_ADCIN2,
> - [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN1,
> + [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3,
> [DA9055_ADC_TJUNC] = DA9055_ADC_MUX_T_SENSE,
> };
>
Applied.
Thanks,
Guenter
--
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] spi: tegra: add spi driver for SLINK controller
On Tuesday 30 October 2012 12:44 AM, Stephen Warren wrote:
On 10/29/2012 11:18 AM, Laxman Dewangan wrote:
Tegra20/Tegra30 supports the spi interface through its SLINK
controller. Add spi driver for SLINK controller.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
+config SPI_TEGRA20_SLINK
+ tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
+ depends on ARCH_TEGRA&& TEGRA20_APB_DMA
I think it depends on DMAENGINE, not the specific driver now, doesn't it?
Taking example from the mfd, we depends on particular driver, not from
the core driver.
I like to have this depends on Tegra20_apb_dma.
+ x = 0;
+ for (i = 0; nbytes&& (i< tspi->bytes_per_word);
+ i++, nbytes--)
+ x |= ((*tx_buf++)<< i*8);
+ tegra_slink_writel(tspi, x, SLINK_TX_FIFO);
+ }
+ }
The if and the else there are basically identical now. Can't the else
branch simply be replaced by the if branch? At most I think the
difference comes down to max_n_32bit v.s. fifo_words_left calculations
being slight different; everything else is the same.
I suppose this isn't a big deal though; we could clean it up later if
necessary.
I like to clean it later.
+ val |= SLINK_PACKED;
+ tegra_slink_writel(tspi, val, SLINK_DMA_CTL);
+ udelay(1);
+ wmb();
Why the udelay() and wmb()?
udelay() is suggetsed by ASIC.
wmb() is lying in our downstream code and hence it is there but I dont
think it is require now. I will remove it.
+static int tegra_slink_runtime_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct tegra_slink_data *tspi = spi_master_get_devdata(master);
+
+ return tegra_slink_clk_prepare(tspi);
+}
Why not move the body of tegra_slink_clk_{un,prepare} inside those
functions, since they're only called from those functions?
Fine, I will do this,
+MODULE_ALIAS("platform:tegra_slink-slink");
I think that's a typo.
Yes, I will correct it.
--
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 v3 13/16] ARM: dts: add AM33XX MMC support
On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
> Adds AM33XX MMC support for am335x-bone and am335x-evm.
>
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am335x-bone.dts |6 ++
> arch/arm/boot/dts/am335x-evm.dts |6 ++
> arch/arm/boot/dts/am33xx.dtsi | 27 +++
> 3 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..5510979 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -70,6 +70,8 @@
> };
>
> ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
I think these min & max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)
> regulator-always-on;
> };
>
> @@ -78,3 +80,7 @@
> };
> };
> };
> +
> + {
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 185d632..d63fce8 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -114,7 +114,13 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
=same=
> regulator-always-on;
> };
> };
> };
> +
> + {
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ab9c78f..26a6af7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,33 @@
> status = "disabled";
> };
>
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = < 24
> + 25>;
> + dma-names = "tx", "rx";
Add status = "disabled" here and "okay" in corresponding
.dts file
> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = < 2
> + 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;
What about DMA resources for mmc3?
AnilKumar
> + status = "disabled";
> + };
> +
> wdt2: wdt@44e35000 {
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> --
> 1.7.9.5
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
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 2/2] therma: exynos: Supports thermal tripping
TMU urgently sends active-high signal (thermal trip) to PMU,
and thermal tripping by hardware logic i.e PMU is performed.
Thermal tripping means that PMU cut off the whole power of SoC
by controlling external voltage regulator.
Signed-off-by: Jonghwan Choi
---
drivers/thermal/exynos_thermal.c |7 ++-
include/linux/platform_data/exynos_thermal.h |4
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 6ce6667..edac601 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -53,6 +53,7 @@
#define EXYNOS_TMU_TRIM_TEMP_MASK 0xff
#define EXYNOS_TMU_GAIN_SHIFT 8
#define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24
+#define EXYNOS_TMU_TRIP_EN BIT(12)
#define EXYNOS_TMU_CORE_ON 1
#define EXYNOS_TMU_CORE_OFF0
#define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50
@@ -656,6 +657,8 @@ static void exynos_tmu_control(struct platform_device
*pdev, bool on)
if (data->soc == SOC_ARCH_EXYNOS) {
con |= pdata->noise_cancel_mode <<
EXYNOS_TMU_TRIP_MODE_SHIFT;
con |= (EXYNOS_MUX_ADDR_VALUE << EXYNOS_MUX_ADDR_SHIFT);
+ if (pdata->trip_en)
+ con |= EXYNOS_THERMAL_TRIP_EN;
}
if (on) {
@@ -762,10 +765,12 @@ static struct exynos_tmu_platform_data const
exynos_default_tmu_data = {
.trigger_levels[0] = 85,
.trigger_levels[1] = 103,
.trigger_levels[2] = 110,
+ .trigger_levels[3] = 120,
.trigger_level0_en = 1,
.trigger_level1_en = 1,
.trigger_level2_en = 1,
- .trigger_level3_en = 0,
+ .trigger_level3_en = 1,
+ .trip_en = 1,
.gain = 8,
.reference_voltage = 16,
.noise_cancel_mode = 4,
diff --git a/include/linux/platform_data/exynos_thermal.h
b/include/linux/platform_data/exynos_thermal.h
index a7bdb2f..9e44aac 100644
--- a/include/linux/platform_data/exynos_thermal.h
+++ b/include/linux/platform_data/exynos_thermal.h
@@ -79,6 +79,9 @@ struct freq_clip_table {
* @trigger_level3_en:
* 1 = enable trigger_level3 interrupt,
* 0 = disable trigger_level3 interrupt
+ * @trip_en:
+ * 1 = enable thermal tripping
+ * 0 = disable thermal tripping
* @gain: gain of amplifier in the positive-TC generator block
* 0 <= gain <= 15
* @reference_voltage: reference voltage of amplifier
@@ -102,6 +105,7 @@ struct exynos_tmu_platform_data {
bool trigger_level1_en;
bool trigger_level2_en;
bool trigger_level3_en;
+ bool trip_en;
u8 gain;
u8 reference_voltage;
--
1.7.4.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/
[PATCH 1/2] thermal: exynos: Fix wrong bit to control tmu core
[0]bit is used to enable/disable tmu core. [1] bit is a reserved bit. Signed-off-by: Jonghwan Choi --- drivers/thermal/exynos_thermal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/exynos_thermal.c b/drivers/thermal/exynos_thermal.c index fd03e85..6ce6667 100644 --- a/drivers/thermal/exynos_thermal.c +++ b/drivers/thermal/exynos_thermal.c @@ -53,8 +53,8 @@ #define EXYNOS_TMU_TRIM_TEMP_MASK 0xff #define EXYNOS_TMU_GAIN_SHIFT 8 #define EXYNOS_TMU_REF_VOLTAGE_SHIFT 24 -#define EXYNOS_TMU_CORE_ON 3 -#define EXYNOS_TMU_CORE_OFF2 +#define EXYNOS_TMU_CORE_ON 1 +#define EXYNOS_TMU_CORE_OFF0 #define EXYNOS_TMU_DEF_CODE_TO_TEMP_OFFSET 50 /* Exynos4210 specific registers */ -- 1.7.4.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: [PATCHv5] Input: keypad: Add smsc ece1099 keypad driver
Hi Felipe,
On Monday 29 October 2012 09:50 PM, Felipe Balbi wrote:
Hi,
On Mon, Oct 29, 2012 at 04:08:49PM +0530, Sourav Poddar wrote:
+static int __devinit
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0;
+ int i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = devm_input_allocate_device(dev);
+ if (!kp || !input)
+ ret = -ENOMEM;
+
+ ret = smsc_keypad_parse_dt(dev, kp);
+ if (ret)
+ return ret;
+
+ /* Get the debug Device */
+ kp->input = input;
+ kp->irq = platform_get_irq(pdev, 0);
+ kp->dev = dev;
+
+ /* setup input device */
+__set_bit(EV_KEY, input->evbit);
+
+ /* Enable auto repeat feature of Linux input subsystem */
+ if (!kp->no_autorepeat)
+ __set_bit(EV_REP, input->evbit);
+
+ input_set_capability(input, EV_MSC, MSC_SCAN);
+ input->name = "SMSC Keypad";
+ input->phys = "smsc_keypad/input0";
+ input->dev.parent = >dev;
+ input->id.bustype = BUS_HOST;
+ input->id.vendor= 0x0001;
+ input->id.product = 0x0001;
+ input->id.version = 0x0003;
+
+ input->open = smsc_keypad_open;
+ input->close = smsc_keypad_close;
+ input_set_drvdata(input, kp);
+
+ /* Mask all GPIO interrupts (0x37-0x3B) */
+ for (addr = SMSC_GPIO_INT_MASK_START;
+ addr < SMSC_GPIO_INT_MASK_START + 4; addr++)
+ smsc_write(dev, addr, 0);
+
+ /* Set all outputs high (0x05-0x09) */
+ for (addr = SMSC_GPIO_DATA_OUT_START;
+ addr < SMSC_GPIO_DATA_OUT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Clear all GPIO interrupts (0x32-0x36) */
+ for (addr = SMSC_GPIO_INT_STAT_START;
+ addr < SMSC_GPIO_INT_STAT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Configure the smsc pins as Keyboard scan Input */
+ for (i = 0; i < kp->rows; i++) {
+ addr = 0x12 + i;
+ smsc_write(dev, addr, SMSC_KP_KSI);
+ }
+
+ /* Configure the smsc pins as Keyboard scan output */
+ for (i = 0; i < kp->cols; i++) {
+ addr = 0x1a + i;
+ smsc_write(dev, addr, SMSC_KP_KSO);
+ }
+
+ smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
+ smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+ smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+
+ row_shift = get_count_order(kp->cols);
+ max_keys = kp->rows << row_shift;
+
+ kp->row_shift = row_shift;
+ kp->keymap = devm_kzalloc(dev, max_keys * sizeof(kp->keymap[0]),
+ GFP_KERNEL);
+ if (!kp->keymap) {
+ dev_err(dev, "Not enough memory for keymap\n");
+ return -ENOMEM;
+ }
+
+ ret = matrix_keypad_build_keymap(NULL, NULL, kp->rows,
+ kp->cols, kp->keymap, input);
+ if (ret) {
+ dev_err(dev, "failed to build keymap\n");
+ return ret;
+ }
+
+ /*
+ * This ISR will always execute in kernel thread context because of
+ * the need to access the SMSC over the I2C bus.
+ */
+ ret = devm_request_threaded_irq(dev, kp->irq, NULL, do_kp_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev->name, kp);
+ if (ret) {
+ dev_dbg(dev, "request_irq failed for irq no=%d\n",
+ irq);
+ return ret;
+ }
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(kp->dev,
+ "Unable to register twl4030 keypad device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
shouldn't you unregister the input device here ??
As Dmitry already pointed out, I was also thinking on the same line that
using devm_* variants
will automatically take care of unregistering your device.
--
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: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi
Cc: Santosh Shilimkar
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 95 +++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
{
status = "disabled";
};
+
+ {
+ clock-frequency = <40>;
+
+ smsc@38 {
+ compatible = "smscece1099";
+ reg = <0x38>;
+ clock = <0x13>;
What does that "clock" mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
Regards,
Benoit
--
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: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 07:32:55PM -0700, Greg KH wrote: > On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: > > --- /dev/null > > +++ b/drivers/misc/vmw_vmci/Makefile > > @@ -0,0 +1,43 @@ > > + > > +# > > +# Linux driver for VMware's VMCI device. > > +# > > +# Copyright (C) 2007-2012, VMware, Inc. All Rights Reserved. > > +# > > +# This program is free software; you can redistribute it and/or modify it > > +# under the terms of the GNU General Public License as published by the > > +# Free Software Foundation; version 2 of the License and no later version. > > +# > > +# This program is distributed in the hope that it will be useful, but > > +# WITHOUT ANY WARRANTY; without even the implied warranty of > > +# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or > > +# NON INFRINGEMENT. See the GNU General Public License for more > > +# details. > > +# > > +# Maintained by: Andrew Stiegmann > > +# > > + > > That's a big boiler-plate for a makefile :) > > Wait, what's Andrew's name doing here, and yet it isn't on any of the > signed-off-by: or From: lines of the driver? Surely you aren't the only > contributor here? > > > +# > > +# Makefile for the VMware VMCI > > +# > > That's the only needed comment for this file, if even that. > > > + > > +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o > > + > > +vmw_vmci-y += vmci_context.o > > +vmw_vmci-y += vmci_datagram.o > > +vmw_vmci-y += vmci_doorbell.o > > +vmw_vmci-y += vmci_driver.o > > +vmw_vmci-y += vmci_event.o > > +vmw_vmci-y += vmci_guest.o > > +vmw_vmci-y += vmci_handle_array.o > > +vmw_vmci-y += vmci_host.o > > +vmw_vmci-y += vmci_queue_pair.o > > +vmw_vmci-y += vmci_resource.o > > +vmw_vmci-y += vmci_route.o > > You can do this cleaner with multiple .o objects on the same line... > > > +vmci: > > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules > > + > > +clean: > > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean > > What are these two last targets for? I'm guessing this is from when you > ported it from a stand-along module? Please remove them. We'll clean it all up. Thanks for going over the code. -- Dmitry -- 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: [Pv-drivers] [PATCH 08/12] VMCI: resource object implementation.
On Mon, Oct 29, 2012 at 07:29:46PM -0700, Greg KH wrote: > On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote: > > VMCI resource tracks all used resources within the vmci code. > > Same "kref_put() with no lock seen" question in this file, prove me > wrong please. Same proof as with others, the reference can't be taken unless the resource is in hast table (which protected by RCU/spinlock) so no fear of bouncing off 0. Thanks, Dmitry -- 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: [Pv-drivers] [PATCH 08/12] VMCI: resource object implementation.
On Mon, Oct 29, 2012 at 07:29:05PM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote:
> > +static struct vmci_resource *vmci_resource_lookup(struct vmci_handle
> > handle)
> > +{
> > + struct vmci_resource *r, *resource = NULL;
> > + struct hlist_node *node;
> > + unsigned int idx = vmci_resource_hash(handle);
> > +
> > + BUG_ON(VMCI_HANDLE_EQUAL(handle, VMCI_INVALID_HANDLE));
>
> You just crashed a machine, with no chance for recovery. Not a good
> idea. Never a good idea. Customers just lost data, and now they are
> mad. Make sure you at least print out your email address so they know
> who to blame :)
>
> Seriously, never BUG() in a driver, warn, sure, but this just looks like
> a debugging assert(). Please remove all of these, they are sprinkled
> all over the driver code here, I'm only responding to one of them here.
>
> Even better yet, properly handle the error and keep on going, that's
> what the rest of the kernel does. Or should :)
For public APIs it certainly makes sense to check and handle erroneous input;
internally it often makes sense to simply enforce invariants, because if
we managed to get into that state that we consider impossible we can't really
trust anything.
FWIW:
[dtor@dtor-ws kernel]$ grep -r BUG_ON . | wc -l
11269
Thanks,
Dmitry
--
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: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, 2012-10-29 at 23:16 +0100, Antonio Ospite wrote: > Hi, > > I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > my video adapter is the one integrated on the MSI M3N78-VM motherboard > (hence x86_64): > > 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev > a2) (prog-if 00 [VGA controller]) > Subsystem: ASUSTeK Computer Inc. Device 82f2 > Flags: bus master, fast devsel, latency 0, IRQ 21 > Memory at fd00 (32-bit, non-prefetchable) [size=16M] > Memory at f000 (64-bit, prefetchable) [size=128M] > Memory at fa00 (64-bit, prefetchable) [size=32M] > I/O ports at ec00 [size=128] > Expansion ROM at febe [disabled] [size=128K] > Capabilities: [60] Power Management version 2 > Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ > Kernel driver in use: nouveau > > The problem presents itself as soon as I use a gnome-shell session from > gdm3, if I use the fall-back mode (gnome-panel) it does not happen > immediately, until maybe some processes do something stressful (firefox > triggered it twice). If you boot into fallback mode and run glxgears (or whatever, some 3d app) does this happen too? > > Here is the kernel trace, please let me know if the disassembled > nouveau.o —or any other information— is necessary: Are you able to post me your entire kernel log from before this happens? Thanks, Ben. > > [ 1943.858601] BUG: unable to handle kernel paging request at fff8 > [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau] > [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 > [ 1943.858803] Oops: [#1] SMP > [ 1943.858823] Modules linked in: hidp ebtable_nat ebtables cpufreq_powersave > cpufreq_conservative cpufreq_stats cpufreq_userspace ipt_MASQUERADE > xt_CHECKSUM bridge stp llc ppdev lp bnep rfcomm tun sit tunnel4 binfmt_misc > uinput ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp > libiscsi_tcp libiscsi scsi_transport_iscsi ip6table_raw ip6table_mangle > ip6t_REJECT xt_LOG nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_rt ip6table_filter > ip6_tables xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_multiport xt_conntrack > iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 > nf_nat nf_conntrack iptable_mangle iptable_raw ip_tables x_tables hwmon_vid > loop fuse snd_hda_codec_hdmi snd_hda_codec_via snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc nouveau > snd_seq_midi snd_seq_midi_event powernow_k8 snd_rawmidi snd_seq kvm_amd > snd_seq_device kvm snd_timer ttm snd edac_mce_amd btusb drm_kms_helper > bluetooth edac_core drm rfkill i2c! _a! > lgo_bit > mxm_wmi shpchp asus_atk0110 soundcore crc16 k8temp evdev pcspkr parport_pc > parport video wmi processor thermal_sys i2c_nforce2 i2c_core button ext3 > mbcache jbd dm_mod sg hid_generic sr_mod sd_mod cdrom crc_t10dif usbhid > usb_storage hid uas ohci_hcd ahci libahci libata ehci_hcd forcedeth scsi_mod > usbcore usb_common floppy > [ 1943.859565] CPU 0 > [ 1943.859580] Pid: 2985, comm: Xorg Not tainted 3.7.0-rc3-ao2 #1 System > manufacturer System Product Name/M3N78-VM > [ 1943.859609] RIP: 0010:[] [] > nouveau_mm_head+0x30/0x127 [nouveau] > [ 1943.859670] RSP: 0018:8801179519a8 EFLAGS: 00010212 > [ 1943.859687] RAX: RBX: fff0 RCX: > 007e > [ 1943.859708] RDX: 007e RSI: 0001 RDI: > 880117bfbce8 > [ 1943.859728] RBP: 88011785fd38 R08: R09: > 88011785fd38 > [ 1943.859748] R10: 880117bfbc00 R11: 88011785fc80 R12: > 007e > [ 1943.859769] R13: 880117bfbc01 R14: 880117bfbc20 R15: > 880117951a70 > [ 1943.859791] FS: 7f1099383880() GS:88011fc0() > knlGS: > [ 1943.859813] CS: 0010 DS: ES: CR0: 80050033 > [ 1943.859830] CR2: fff8 CR3: 000118473000 CR4: > 07f0 > [ 1943.859850] DR0: DR1: DR2: > > [ 1943.859870] DR3: DR6: 0ff0 DR7: > 0400 > [ 1943.859891] Process Xorg (pid: 2985, threadinfo 88011795, task > 8801181cc8e0) > [ 1943.859911] Stack: > [ 1943.859920] 0246 810fa13d 81060f13 > 03f0 > [ 1943.859955] 0002 0010 880117bfbc00 > 880117bfbc20 > [ 1943.859986] 880117951a70 a032a10a 8801 > 03f8 > [ 1943.860018] Call Trace: > [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf > [ 1943.860019] [] ? should_resched+0x5/0x23 > [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] > [ 1943.860019] [] ? nouveau_vram_manager_new+0x62/0xa4 > [nouveau] > [ 1943.860019] [] ? ttm_bo_handle_move_mem+0x1ab/0x2ec > [ttm] > [ 1943.860019] [] ? ttm_bo_mem_space+0x112/0x2f8 [ttm]
Re: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at "running init tables"
On Tue, 2012-10-30 at 00:32 +0100, Mathieu Chouquet-Stringer wrote: > Hi again, > > On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote: > > Are you able to go back to the current master, and get me a > > log/screenshot with "nouveau.debug=trace" appended to your kernel > > options? > > Hmmm I did just that on v3.7-rc3-8-g35fd3dc and it doesn't seem to > output more stuff: Hm, the module probably wasn't built with a high enough debug level by default. It's alright, we'll come back to that if we need to. Not sure what's up with the hang yet, however, I noticed the issue [1] which is likely causing the error messages from nouveau's i2c code. With some luck, it'll stop triggering whatever bug is making it hang in the VBIOS init table parser. Ben. [1] http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=000463f13fba6b2f94a5bfcb0d615751ae9c34a0 > > http://mathieu.csetco.com/nouveau.jpeg -- 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: [Pv-drivers] [PATCH 05/12] VMCI: event handling implementation.
On Mon, Oct 29, 2012 at 07:26:05PM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> > +static void event_signal_destroy(struct kref *kref)
> > +{
> > + struct vmci_subscription *entry =
> > + container_of(kref, struct vmci_subscription, kref);
> > +
> > + complete(>done);
> > +}
>
> Didn't you just leak memory here? What frees the structure up?
event_unregister_subscription() waits for that completion and frees the
structure. We want event_unregister_subscription() to wait until all
fired callbacks completed before unregister is complete.
Thanks,
Dmitry
--
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: [Pv-drivers] [PATCH 05/12] VMCI: event handling implementation.
On Mon, Oct 29, 2012 at 07:24:46PM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> > +/*
> > + * Releases the given VMCISubscription.
> > + * Fires the destroy event if the reference count has gone to zero.
> > + */
> > +static void event_release(struct vmci_subscription *entry)
> > +{
> > + kref_put(>kref, event_signal_destroy);
> > +}
>
> Same question as before with the kref_put() call, what is handling the
> locking here? It looks like a race to me.
The reference is taken only if event is on the list (which managed by
RCU and a mutex), so it is not possible to go from 0->1 for that
refcount.
Thanks,
Dmitry
--
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] hrtimer: Printing timer info when hitting BUG_ON()
> -Original Message-
> From: Peter Zijlstra [mailto:a.p.zijls...@chello.nl]
> Sent: Monday, October 29, 2012 5:06 PM
> To: Liu, Chuansheng
> Cc: t...@linutronix.de; mi...@kernel.org; linux-kernel@vger.kernel.org; Li,
> Fei;
> yanmin_zh...@linux.intel.com
> Subject: Re: [PATCH] hrtimer: Printing timer info when hitting BUG_ON()
>
> On Mon, 2012-10-29 at 19:02 +0800, Chuansheng Liu wrote:
> > +/*
> > + * dump_hrtimer_callinfo - print hrtimer information including:
> > + * state, callback function, pid and start_site.
> > +*/
> > +static void dump_hrtimer_callinfo(struct hrtimer *timer)
> > +{
> > +
> > + char symname[KSYM_NAME_LEN];
> > +
> > + if (lookup_symbol_name((unsigned long)(timer->function),
> symname) < 0) {
> > + pr_err("timer info: state/%lx, func/%pK\n",
> > + timer->state, timer->function);
> > + } else {
> > + pr_err("timer info: state/%lx, func/%s",
> > + timer->state, symname);
> > + }
> > +
> > +#ifdef CONFIG_TIMER_STATS
> > + if (lookup_symbol_name((unsigned long)(timer->start_site),
> > + symname) < 0) {
> > + pr_err("timer stats: pid/%d(%s), site/%pK\n",
> > + timer->start_pid, timer->start_comm,
> timer->start_site);
> > + } else {
> > + pr_err("timer stats: pid/%d(%s), site/%s\n",
> > + timer->start_pid, timer->start_comm,
> symname);
> > + }
> > +#endif
> > +}
>
> What's wrong with %pf ?
Thanks Peter's help and pointing out, patch V2 has been sent.
This patch helps us to find out the root cause quickly.
--
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 from 3.4.9 to 3.4.16 "stable" kernel
On 12-10-29 07:03 PM, Greg Kroah-Hartman wrote: > On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote: >> There's something else very wrong when going from 3.4.9 to 3.4.16. >> I've done it on two machines here, one the AMD-450 server (64-bit), >> and the other my main notebook (Core2duo 32-bit-PAE). >> >> Both systems feel much more sluggish than usual with 3.4.16 running. >> Reverted them both back to earlier kernels (3.4.9, 3.4.4-PAE), >> and the usual responsive feel has returned. >> >> Vague, I know, but something bad happened in there somewhere. > > That's too vague for me to do anything with, sorry. Bisection would be > good if you can figure out how to measure this. Well, I'd bet Donkeys to Daises that reverting the kernel/sched.c changes will probably fix the responsiveness, but I haven't done that yet. I've lost enough time already debugging the other issues. This is more just an indication that perhaps -stable patches need better review than they're getting. Take the setup.c breakage: as soon as I pointed it out, a few people jumped in with knowledge that it was broken, and that patches existed to fix it. That kind of thing should be happening before a -stable release, though I don't know how you would get the Right People to look at this stuff then rather than after the fact. Maybe a topic for a future kernel summit or something. Best wishes. -ml -- 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 2/9] uuid: use random32_get_bytes()
On Tue, Oct 30, 2012 at 09:49:58AM +0800, Huang Ying wrote:
> The uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE,
> that is done in __uuid_gen_common() with "b[8] = (b[8] & 0x3F) | 0x80".
Oh, I see, I missed that.
> To deal with random number generation issue, how about use
> get_random_bytes() in __uuid_gen_common()?
We already have generate_random_uuid() in drivers/char/random.c, and
no users for lib/uuid.c's equivalent uuid_be_gen(). So here's a
counter-proposal, why don't we drop lib/uuid.c, and include in
drivers/char/random.c:
/*
* Generate random GUID
*
* GUID's is like UUID's, but they uses the non-standard little-endian
* layout, compared to what is defined in RFC-4112; it is primarily
* used by the EFI specification.
*/
void generate_random_guid(unsigned char uuid_out[16])
{
get_random_bytes(uuid_out, 16);
/* Set UUID version to 4 --- truly random generation */
uuid_out[7] = (uuid_out[7] & 0x0F) | 0x40;
/* Set the UUID variant to DCE */
uuid_out[8] = (uuid_out[8] & 0x3F) | 0x80;
}
EXPORT_SYMBOL(generate_random_guid);
I really don't think it's worth it to have a __uuid_gen_common once we
are using get_random_bytes(), since there isn't much code to be
factored out, and it's simpler just to have two functions in one place.
Using UUID vs. GUID I think makes things much clearer, since the EFI
specification talks about GUID's, not UUID's, and that way we don't
have to worry about people getting confused about whether they should
be using the little-endian versus big-endian variant. (And I'd love
to ask to whoever wrote the EFI specification what on *Earth* were
they thinking when they decided to diverge from the rest of the
world)
- Ted
--
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/5] fat: add mutex lock to fat_build_inode
2012/10/30, Andrew Morton : > On Sun, 28 Oct 2012 10:53:43 +0900 > Namjae Jeon wrote: > >> From: Namjae Jeon >> >> fat_nfs_get_inode does not hold i_mutex of parent directory.So add >> lock to fat_build_inode. > Hi. Andrew. > Well.. why? Presumably this patch fixes some race. A good > description of that race would be useful - partly because others may > then be able to suggest alternative ways of fixing that bug. We are making use of fat_build_inode to build the inode using 'i_pos'. Since, this function is local to FAT and when mounted over NFS. We can make use of FAT parallely from local NFS Server and mounted from NFS client. So, in order to avoid race to multiple regeneration for the same 'i_pos' - we have introduced this locking. > > I'll merge these patches for some testing. > > I did merge these patches three weekes ago: > > fat-modify-nfs-mount-option.patch > fat-exportfs-rebuild-inode-if-ilookup-fails.patch > fat-exportfs-rebuild-inode-if-ilookup-fails-fix.patch > fat-exportfs-rebuild-directory-inode-if-fat_dget-fails.patch > documentation-update-nfs-option-in-filesystem-vfattxt.patch > > But I have no record of Bruce or Ogawa having reviewed/acked them? While the patches were sent for review on LKML and also in the meantime since the functionality was finalised, the patches were picked for merging in the linux tree. But there few comments which were later provided by OGAWA. So, these patches are extending the earlier patch-set by providing some fix-ups and cleanup routines. 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] hwmon: da9055: Fix chan_mux[DA9055_ADC_ADCIN3] setting
On Mon, 2012-10-29 at 17:52 -0700, Guenter Roeck wrote:
> On Mon, Oct 29, 2012 at 04:34:38PM +0800, Axel Lin wrote:
> > Set chan_mux[DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3.
> >
> > Signed-off-by: Axel Lin
> > ---
> > Hi,
> > This looks like a typo, but I don't have a hardware to test it.
> > Axel
> > drivers/hwmon/da9055-hwmon.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwmon/da9055-hwmon.c b/drivers/hwmon/da9055-hwmon.c
> > index 0b41f2c..3a3377c 100644
> > --- a/drivers/hwmon/da9055-hwmon.c
> > +++ b/drivers/hwmon/da9055-hwmon.c
> > @@ -54,7 +54,7 @@ static const u8 chan_mux[DA9055_ADC_TJUNC + 1] = {
> > [DA9055_ADC_VSYS] = DA9055_ADC_MUX_VSYS,
> > [DA9055_ADC_ADCIN1] = DA9055_ADC_MUX_ADCIN1,
> > [DA9055_ADC_ADCIN2] = DA9055_ADC_MUX_ADCIN2,
> > - [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN1,
> > + [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3,
> > [DA9055_ADC_TJUNC] = DA9055_ADC_MUX_T_SENSE,
> > };
>
> Very much loks like a typo.
>
> David, Ashish, any comments ? I would like to get your Ack before applying it.
>
> Thanks,
> Guenter
>
Yes, its typo so you can apply the patch.
--
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: [Pv-drivers] [PATCH 04/12] VMCI: device driver implementaton.
On Mon, Oct 29, 2012 at 07:23:47PM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 06:04:15PM -0700, George Zhang wrote:
> > +static int __init vmci_core_init(void)
> > +{
> > + int result;
> > +
> > + result = vmci_ctx_init();
> > + if (result < VMCI_SUCCESS) {
> > + pr_err("Failed to initialize VMCIContext (result=%d).\n",
> > + result);
>
> If you are going to use pr_* functions, it's usually a good idea to
> define pr_fmt in a consistant way so that it shows up the same across
> all of your .c files. See other drivers for examples of how to do this
> properly.
pr_fmt() is defined in drivers/misc/vmw_vmci/vmci_common_int.h
>
> > + return -EINVAL;
> > + }
> > +
> > + result = vmci_datagram_init();
> > + if (result < VMCI_SUCCESS) {
> > + pr_err("Failed to initialize VMCIDatagram (result=%d).\n",
> > + result);
> > + return -EINVAL;
> > + }
> > +
> > + result = vmci_event_init();
> > + if (result < VMCI_SUCCESS) {
> > + pr_err("Failed to initialize VMCIEvent (result=%d).\n", result);
> > + return -EINVAL;
> > + }
>
> You don't free and unwind things properly if things go wrong here, why
> not?
We do, the above calls do not need to be cleaned up.
>
> > +
> > + return 0;
> > +}
> > +
> > +static void __exit vmci_core_exit(void)
> > +{
> > + vmci_event_exit();
> > +}
> > +
> > +static int __init vmci_drv_init(void)
> > +{
> > + int error;
> > +
> > + error = vmci_core_init();
> > + if (error)
> > + return error;
> > +
> > + if (!vmci_disable_guest) {
> > + error = vmci_guest_init();
> > + if (error) {
> > + pr_warn("Failed to initialize guest personality
> > (err=%d).\n",
> > + error);
> > + } else {
> > + vmci_guest_personality_initialized = true;
> > + pr_info("Guest personality initialized and is %s\n",
> > + vmci_guest_code_active() ?
> > + "active" : "inactive");
> > + }
> > + }
> > +
> > + if (!vmci_disable_host) {
> > + error = vmci_host_init();
> > + if (error) {
> > + pr_warn("Unable to initialize host personality
> > (err=%d).\n",
> > + error);
> > + } else {
> > + vmci_host_personality_initialized = true;
> > + pr_info("Initialized host personality\n");
> > + }
> > + }
> > +
> > + if (!vmci_guest_personality_initialized &&
> > + !vmci_host_personality_initialized) {
> > + vmci_core_exit();
> > + return -ENODEV;
> > + }
> > +
> > + pr_debug("Module is initialized\n");
>
> Really? You need this message still?
These are debug messages so do not show up in logs by default.
>
> > + return 0;
> > +}
> > +module_init(vmci_drv_init);
> > +
> > +static void __exit vmci_drv_exit(void)
> > +{
> > + if (vmci_guest_personality_initialized)
> > + vmci_guest_exit();
> > +
> > + if (vmci_host_personality_initialized)
> > + vmci_host_exit();
> > +
> > + vmci_core_exit();
> > + pr_debug("Module is unloaded\n");
>
> Same here, is this really needed?
>
Still debug so no littering in logs.
Thanks,
Dmitry
--
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: [Pv-drivers] [PATCH 00/12] VMCI for Linux upstreaming
Hi Greg, On Mon, Oct 29, 2012 at 07:19:38PM -0700, Greg KH wrote: > On Mon, Oct 29, 2012 at 06:03:28PM -0700, George Zhang wrote: > > drivers/misc/Kconfig |1 > > drivers/misc/Makefile |2 > > drivers/misc/vmw_vmci/Kconfig | 16 > > drivers/misc/vmw_vmci/Makefile| 43 > > Meta comment here, why drivers/misc/? The other hypervisor > infrastructures all have their own directory under drivers/ Should we > be moving everything to drivers/hyperv/ somehow? drivers/hyperv is not the best name for obvious reasons... I think that even if we had a special directory for vmci having network drivers in Dave's realm and pvscsi in James's is best option, so the new directory would contain vmci and the balloon driver (vsock will go into net/). Given that balloon is already in drivers/misc it looked like obvious place for VMCI as well. Thanks, Dmitry -- 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 clk tree with the arm-soc tree
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
arch/arm/include/asm/hardware/sp810.h between commit 0891642cf117 ("ARM:
vexpress: Start using new Versatile Express infrastructure") from the
arm-soc tree and commit 05e3659135a4 ("clk: Common clocks implementation
for Versatile Express") from the clk 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/arm/include/asm/hardware/sp810.h
index 2cdcf44,afd7e91..000
--- a/arch/arm/include/asm/hardware/sp810.h
+++ b/arch/arm/include/asm/hardware/sp810.h
@@@ -50,6 -50,14 +50,8 @@@
#define SCPCELLID20xFF8
#define SCPCELLID30xFFC
-#define SCCTRL_TIMEREN0SEL_REFCLK (0 << 15)
-#define SCCTRL_TIMEREN0SEL_TIMCLK (1 << 15)
-
-#define SCCTRL_TIMEREN1SEL_REFCLK (0 << 17)
-#define SCCTRL_TIMEREN1SEL_TIMCLK (1 << 17)
-
+ #define SCCTRL_TIMERENnSEL_SHIFT(n) (15 + ((n) * 2))
+
static inline void sysctl_soft_reset(void __iomem *base)
{
/* switch to slow mode */
pgpU2QdyNTy5b.pgp
Description: PGP signature
[PATCH] eCryptfs: Avoid unnecessary disk read and data decryption during writing
ecryptfs_write_begin grabs a page from page cache for writing.
If the page contains invalid data, or data older than the
counterpart on the disk, eCryptfs will read out the
corresponing data from the disk into the page, decrypt them,
then perform writing. However, for this page, if the length
of the data to be written into is equal to page size,
that means the whole page of data will be overwritten,
in which case, it does not matter whatever the data were before,
it is beneficial to perform writing directly rather than bothering
to read and decrypt first.
With this optimization, according to our test on a machine with
Intel Core 2 Duo processor, iozone 'write' operation on an existing
file with write size being multiple of page size will enjoy a steady
3x speedup.
Signed-off-by: Li Wang
Signed-off-by: Yunchuan Wen
Reviewed-by: Tyler Hicks
---
fs/ecryptfs/mmap.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index bd1d57f..564a1fa 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -338,7 +338,8 @@ static int ecryptfs_write_begin(struct file *file,
if (prev_page_end_size
>= i_size_read(page->mapping->host)) {
zero_user(page, 0, PAGE_CACHE_SIZE);
- } else {
+ SetPageUptodate(page);
+ } else if (len < PAGE_CACHE_SIZE) {
rc = ecryptfs_decrypt_page(page);
if (rc) {
printk(KERN_ERR "%s: Error decrypting "
@@ -348,8 +349,8 @@ static int ecryptfs_write_begin(struct file *file,
ClearPageUptodate(page);
goto out;
}
+ SetPageUptodate(page);
}
- SetPageUptodate(page);
}
}
/* If creating a page or more of holes, zero them out via truncate.
@@ -499,6 +500,13 @@ static int ecryptfs_write_end(struct file *file,
}
goto out;
}
+ if (!PageUptodate(page)) {
+ if (copied < PAGE_CACHE_SIZE) {
+ rc = 0;
+ goto out;
+ }
+ SetPageUptodate(page);
+ }
/* Fills in zeros if 'to' goes beyond inode size */
rc = fill_zeros_to_end_of_page(page, to);
if (rc) {
--
1.7.6.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] async_tx: use memchr_inv
On Sun, 2012-10-28 at 00:49 +0900, Akinobu Mita wrote: > Use memchr_inv() to check the specified page is filled with zero. > Applied Thanks -- Vinod Koul Intel Corp. -- 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: [Pv-drivers] [PATCH 01/12] VMCI: context implementation.
Hi Greg,
On Mon, Oct 29, 2012 at 07:10:58PM -0700, Greg KH wrote:
> On Mon, Oct 29, 2012 at 06:03:42PM -0700, George Zhang wrote:
> > +/*
> > + * Releases the VMCI context. If this is the last reference to
> > + * the context it will be deallocated. A context is created with
> > + * a reference count of one, and on destroy, it is removed from
> > + * the context list before its reference count is
> > + * decremented. Thus, if we reach zero, we are sure that nobody
> > + * else are about to increment it (they need the entry in the
> > + * context list for that). This function musn't be called with a
> > + * lock held.
> > + */
> > +void vmci_ctx_release(struct vmci_ctx *context)
> > +{
> > + ASSERT(context);
> > + kref_put(>kref, ctx_free_ctx);
> > +}
> > +
>
> Hm, are you _sure_ you should be calling this without a lock held?
> That's usually kref-101, you MUST hold a lock when calling put,
> otherwise you can race a kref_get() call, and all hell can break loose.
>
> Because of this, some saner people (like Al Viro), have suggested that I
> force the kref_put() and kref_get() calls pass in a spinlock just to
> enforce this.
>
> So, tell me what I'm missing here, and why you put the comment here
> saying that it really is supposed to be called without a lock held? How
> is that safe?
>
Contexts are created/registered in vmci_ctx_init_ctx() and unregistered in
vmci_ctx_release_ctx() and these operations are protected by
ctx_list.lock spinlock. Context lookup (vmci_ctx_get) also uses spinlock
to traverse list of registered contexts and then grabs reference to the
[valid] context. The use of kref_put() without additional locking in
vmci_ctx_release() is fine as there is no chance of another thread
bumping count from 0 to 1.
I believe the comment should actually read that the function should not
be called from atomic contexts.
Thanks,
Dmitry
--
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 samsung tree with the pinctrl tree
Hi Kukjin,
Today's linux-next merge of the samsung tree got a conflict in
arch/arm/boot/dts/exynos4210.dtsi between commit a7a8241540c3 ("ARM: dts:
exynos4210-pinctrl: Add nodes for pin banks") from the pinctrl tree and
commit 8d4155dbb184 ("ARM: EXYNOS: Add devicetree node for TMU driver for
exynos4") from the samsung 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/arm/boot/dts/exynos4210.dtsi
index d877dbe,038de97..000
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@@ -64,4 -74,240 +64,11 @@@
compatible = "samsung,pinctrl-exynos4210";
reg = <0x0386 0x1000>;
};
+
- gpio-controllers {
- #address-cells = <1>;
- #size-cells = <1>;
- gpio-controller;
- ranges;
-
- gpa0: gpio-controller@1140 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x1140 0x20>;
- #gpio-cells = <4>;
- };
-
- gpa1: gpio-controller@11400020 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400020 0x20>;
- #gpio-cells = <4>;
- };
-
- gpb: gpio-controller@11400040 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400040 0x20>;
- #gpio-cells = <4>;
- };
-
- gpc0: gpio-controller@11400060 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400060 0x20>;
- #gpio-cells = <4>;
- };
-
- gpc1: gpio-controller@11400080 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400080 0x20>;
- #gpio-cells = <4>;
- };
-
- gpd0: gpio-controller@114000A0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114000A0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpd1: gpio-controller@114000C0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114000C0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpe0: gpio-controller@114000E0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114000E0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpe1: gpio-controller@11400100 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400100 0x20>;
- #gpio-cells = <4>;
- };
-
- gpe2: gpio-controller@11400120 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400120 0x20>;
- #gpio-cells = <4>;
- };
-
- gpe3: gpio-controller@11400140 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400140 0x20>;
- #gpio-cells = <4>;
- };
-
- gpe4: gpio-controller@11400160 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400160 0x20>;
- #gpio-cells = <4>;
- };
-
- gpf0: gpio-controller@11400180 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x11400180 0x20>;
- #gpio-cells = <4>;
- };
-
- gpf1: gpio-controller@114001A0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114001A0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpf2: gpio-controller@114001C0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114001C0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpf3: gpio-controller@114001E0 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x114001E0 0x20>;
- #gpio-cells = <4>;
- };
-
- gpj0: gpio-controller@1100 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x1100 0x20>;
- #gpio-cells = <4>;
- };
-
- gpj1: gpio-controller@1120 {
- compatible = "samsung,exynos4-gpio";
- reg = <0x1120 0x20>;
- #gpio-cells = <4>;
- };
-
-
Re: [PATCH v7 0/3] Add modules to support realtek PCIE card reader
Hi Chris, Samuel and Alex: Can you help to review this patchset, please? I have asked Greg to remove rts_pstor from the staging tree. So this driver have to be merged into 3.8 kernel, or else Realtek'sPCI-E card reader can not be accessed easily. BR, Wei WANG -- 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 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
On Mon, Oct 29, 2012 at 11:41 PM, Alan Stern wrote:
> On Mon, 29 Oct 2012, Ming Lei wrote:
>
>> The patch introduces the flag of memalloc_noio_resume in
>> 'struct dev_pm_info' to help PM core to teach mm not allocating
>> memory with GFP_KERNEL flag for avoiding probable deadlock
>> problem.
>>
>> As explained in the comment, any GFP_KERNEL allocation inside
>> runtime_resume on any one of device in the path from one block
>> or network device to the root device in the device tree may cause
>> deadlock, the introduced pm_runtime_set_memalloc_noio() sets or
>> clears the flag on device of the path recursively.
>>
>> This patch also introduces pm_runtime_get_memalloc_noio() because
>> the flag may be accessed in block device's error handling path
>> (for example, usb device reset)
>
>> +/*
>> + * pm_runtime_get_memalloc_noio - Get a device's memalloc_noio flag.
>> + * @dev: Device to handle.
>> + *
>> + * Return the device's memalloc_noio flag.
>> + *
>> + * The device power lock is held because bitfield is not SMP-safe.
>> + */
>> +bool pm_runtime_get_memalloc_noio(struct device *dev)
>> +{
>> + bool ret;
>> + spin_lock_irq(>power.lock);
>> + ret = dev->power.memalloc_noio_resume;
>> + spin_unlock_irq(>power.lock);
>> + return ret;
>> +}
>
> You don't need to acquire and release a spinlock just to read the
> value. Reading bitfields _is_ SMP-safe; writing them is not.
Thanks for your review.
As you pointed out before, the flag need to be checked before
resetting usb devices, so the lock should be held to make another
context(CPU) see the updated value suppose one context(CPU)
call pm_runtime_set_memalloc_noio() to change the flag at the
same time.
The lock needn't to be held when the function is called inside
pm_runtime_set_memalloc_noio(), so the bitfield flag should
be checked directly without holding power lock in dev_memalloc_noio().
>
>> +/*
>> + * pm_runtime_set_memalloc_noio - Set a device's memalloc_noio flag.
>> + * @dev: Device to handle.
>> + * @enable: True for setting the flag and False for clearing the flag.
>> + *
>> + * Set the flag for all devices in the path from the device to the
>> + * root device in the device tree if @enable is true, otherwise clear
>> + * the flag for devices in the path which sibliings don't set the flag.
>
> s/which/whose/
> s/ii/i
Will fix it in -v4.
>> + *
>> + * The function should only be called by block device, or network
>> + * device driver for solving the deadlock problem during runtime
>> + * resume:
>> + * if memory allocation with GFP_KERNEL is called inside runtime
>> + * resume callback of any one of its ancestors(or the block device
>> + * itself), the deadlock may be triggered inside the memory
>> + * allocation since it might not complete until the block device
>> + * becomes active and the involed page I/O finishes. The situation
>> + * is pointed out first by Alan Stern. Network device are involved
>> + * in iSCSI kind of situation.
>> + *
>> + * The lock of dev_hotplug_mutex is held in the function for handling
>> + * hotplug race because pm_runtime_set_memalloc_noio() may be called
>> + * in async probe().
>> + */
>> +void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
>> +{
>> + static DEFINE_MUTEX(dev_hotplug_mutex);
>> +
>> + mutex_lock(_hotplug_mutex);
>> + while (dev) {
>
> Unless you think somebody is likely to call this function with dev
> equal to NULL, this can simply be
>
> for (;;) {
>
>> + /* hold power lock since bitfield is not SMP-safe. */
>> + spin_lock_irq(>power.lock);
>> + dev->power.memalloc_noio_resume = enable;
>> + spin_unlock_irq(>power.lock);
>> +
>> + dev = dev->parent;
>> +
>> + /* only clear the flag for one device if all
>> + * children of the device don't set the flag.
>> + */
>> + if (!dev || (!enable &&
>
> ... thanks to this test.
>
>> + device_for_each_child(dev, NULL,
>> +dev_memalloc_noio)))
>> + break;
>> + }
>> + mutex_unlock(_hotplug_mutex);
>> +}
>
> This might not work if somebody calls pm_runtime_set_memalloc_noio(dev,
> true) and then afterwards registers dev at the same time as someone
> else calls pm_runtime_set_memalloc_noio(dev2, false), if dev and dev2
> have the same parent.
Good catch, pm_runtime_set_memalloc_noio() should be called between
device_add() and device_del() on block/network device.
> Perhaps the kerneldoc should mention that this function must not be
> called until after dev is registered.
Yes, it should be added in -v4.
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: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Ben Widawsky wrote:
> Hi Norbert. In addition to the above, if this truly appears to be
> related to i/o, can we try to decrease the time to failure with some
I am *not* sure. As I said, the last thing was shotwell photo
editing. It might be some io while loading the photos, but
after that they are in the cache, and the only thing is done is
lots of displaying.
> serious i/o tests? Off the top of my head I am not sure what's
Anyway, that is my idea. I think I don't need google. A simple
svn up
on my 15Gb svn repository creates enough io. And doing some git pull
or so on same sized repositories in parallel brings anyway the
laptop to its knees (actually, badly to its knees).
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
Far out in the uncharted backwaters of the unfashionable
end of the western spiral arm of the Galaxy lies a small
unregarded yellow sun.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
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] bonding: fix bond 6 mode change MAC of arp reply from vif to cause Domu's network unreachable intermittently
On Tue, 30 Oct 2012 at 02:47 GMT, Zheng Li wrote:
> + struct slave *tmp_slave = NULL;
> + int i = 0, found_mac = 0;
> + bond_for_each_slave(bond, tmp_slave, i) {
> + if (ether_addr_equal_64bits(arp->mac_src,
> + tmp_slave->dev->dev_addr)) {
> + found_mac = 1;
> + break;
> + }
> + }
> + if (found_mac)
> + memcpy(arp->mac_src, tx_slave->dev->dev_addr,
> + ETH_ALEN);
A nitpick: found_mac can be a bool.
--
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] bonding: fix bond 6 mode change MAC of arp reply from vif to cause Domu's network unreachable intermittently
This is a fix for a bug in bond_alb.c
Rate of reproduced:100%
Scenario: set Dom0 to bond 6 mode, Domu communicate with Dom0 through vif which
is in bridge mode. The Dom0's bridge of xenbr0 contains vif and bond0, bond0
contains eth0 and eth1. You can just need to ping a host which is in same LAN on
Domu, some of packets will be lost intermittently.
Analyse: When Dom0 set bond mode to 6, the bond alb will change MAC of every arp
reply in rlb_arp_xmit function to affect receive packets, it is ok for normal
NIC, but it's wrong to Domu, when Domu send arp reply through vif of Dom0, bond
of alb replace Domu's MAC in arp reply with NIC's MAC address, that will cause
remote host send packets to Domu using real NIC's MAC instead of Domu's MAC.
Domu
can't receive the packets whose dst MAC is not Domu's MAC.
Cc: Jay Vosburgh
Cc: Andy Gospodarek
Cc: "David S. Miller"
Signed-off-by: Zheng Li
---
drivers/net/bonding/bond_alb.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index e15cc11..d6b134a 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -700,7 +700,18 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb,
struct bonding *bond)
*/
tx_slave = rlb_choose_channel(skb, bond);
if (tx_slave) {
- memcpy(arp->mac_src,tx_slave->dev->dev_addr, ETH_ALEN);
+ struct slave *tmp_slave = NULL;
+ int i = 0, found_mac = 0;
+ bond_for_each_slave(bond, tmp_slave, i) {
+ if (ether_addr_equal_64bits(arp->mac_src,
+ tmp_slave->dev->dev_addr)) {
+ found_mac = 1;
+ break;
+ }
+ }
+ if (found_mac)
+ memcpy(arp->mac_src, tx_slave->dev->dev_addr,
+ ETH_ALEN);
}
pr_debug("Server sent ARP Reply packet\n");
} else if (arp->op_code == htons(ARPOP_REQUEST)) {
--
1.7.6.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 1/2] ARM: mach-imx: imx53.dtsi: pinctl update
On Mon, Oct 29, 2012 at 10:13:59PM +0100, Sascha Hauer wrote: > On Thu, Oct 25, 2012 at 01:26:39PM +0200, Roland Stigge wrote: > > This patch supplements pinctl support on i.MX53. > > > > Signed-off-by: Roland Stigge > > Acked-by: Sascha Hauer > > Shawn, probably better when you take this patch as it's quite likely > that you collect other patches to this file. > Applied with patch subject changed to ARM: dts: imx53: pinctl update Shawn -- 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 4/9] clear the memory to store struct page
At 10/30/2012 10:41 AM, Andrew Morton Wrote: > On Tue, 30 Oct 2012 10:18:17 +0800 Wen Congyang wrote: > >> At 10/30/2012 05:10 AM, Andrew Morton Wrote: >>> On Fri, 26 Oct 2012 17:44:06 +0800 >>> Wen Congyang wrote: >>> This patch has been acked by kosaki motohiro. Is it OK to be merged into -mm tree? >>> >>> I'd already merged the v2 patchset when you later sent out the v3 >>> patchset which contains some of the material from v2 plus more things. >>> >>> I can drop all of v2 and remerge v3. But I see from the discussion >>> under "[PATCH v3 6/9] memory-hotplug: update mce_bad_pages when >>> removing the memory" that you intend to send out a v4 patchset. >> >> OK, I will send out a v4 patchset. > > Thanks. > >> Do I need to resend the patch >> which is in -mm tree and has no comment? > > I wonder which patch that is! > > Sure, send everything. > OK, I will send everything soon. Thanks Wen Congyang -- 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 4/9] clear the memory to store struct page
On Tue, 30 Oct 2012 10:18:17 +0800 Wen Congyang wrote: > At 10/30/2012 05:10 AM, Andrew Morton Wrote: > > On Fri, 26 Oct 2012 17:44:06 +0800 > > Wen Congyang wrote: > > > >> This patch has been acked by kosaki motohiro. Is it OK to be merged > >> into -mm tree? > > > > I'd already merged the v2 patchset when you later sent out the v3 > > patchset which contains some of the material from v2 plus more things. > > > > I can drop all of v2 and remerge v3. But I see from the discussion > > under "[PATCH v3 6/9] memory-hotplug: update mce_bad_pages when > > removing the memory" that you intend to send out a v4 patchset. > > OK, I will send out a v4 patchset. Thanks. > Do I need to resend the patch > which is in -mm tree and has no comment? I wonder which patch that is! Sure, send everything. -- 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 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote:
> +/*
> + * Driver version.
> + *
> + * Increment major version when you make an incompatible change.
> + * Compatibility goes both ways (old driver with new executable
> + * as well as new driver with old executable).
> + */
> +
> +/* Never change VMCI_VERSION_SHIFT_WIDTH */
> +#define VMCI_VERSION_SHIFT_WIDTH 16
> +#define VMCI_MAKE_VERSION(_major, _minor)\
> + ((_major) << VMCI_VERSION_SHIFT_WIDTH | (u16) (_minor))
> +
> +#define VMCI_VERSION_MAJOR(v) ((u32) (v) >> VMCI_VERSION_SHIFT_WIDTH)
> +#define VMCI_VERSION_MINOR(v) ((u16) (v))
> +
> +/*
> + * VMCI_VERSION is always the current version. Subsequently listed
> + * versions are ways of detecting previous versions of the connecting
> + * application (i.e., VMX).
> + *
> + * VMCI_VERSION_NOVMVM: This version removed support for VM to VM
> + * communication.
> + *
> + * VMCI_VERSION_NOTIFY: This version introduced doorbell notification
> + * support.
> + *
> + * VMCI_VERSION_HOSTQP: This version introduced host end point support
> + * for hosted products.
> + *
> + * VMCI_VERSION_PREHOSTQP: This is the version prior to the adoption of
> + * support for host end-points.
> + *
> + * VMCI_VERSION_PREVERS2: This fictional version number is intended to
> + * represent the version of a VMX which doesn't call into the driver
> + * with ioctl VERSION2 and thus doesn't establish its version with the
> + * driver.
> + */
Do we care about these old versions anymore, now that this is really
"new" code going into the kernel?
> +
> +#define VMCI_VERSIONVMCI_VERSION_NOVMVM
> +#define VMCI_VERSION_NOVMVM VMCI_MAKE_VERSION(11, 0)
> +#define VMCI_VERSION_NOTIFY VMCI_MAKE_VERSION(10, 0)
> +#define VMCI_VERSION_HOSTQP VMCI_MAKE_VERSION(9, 0)
> +#define VMCI_VERSION_PREHOSTQP VMCI_MAKE_VERSION(8, 0)
> +#define VMCI_VERSION_PREVERS2 VMCI_MAKE_VERSION(1, 0)
> +
> +#define VMCI_SOCKETS_MAKE_VERSION(_p)
> \
> + _p)[0] & 0xFF) << 24) | (((_p)[1] & 0xFF) << 16) | ((_p)[2]))
> +
> +/*
> + * Linux defines _IO* macros, but the core kernel code ignore the encoded
> + * ioctl value. It is up to individual drivers to decode the value (for
> + * example to look at the size of a structure to determine which version
> + * of a specific command should be used) or not (which is what we
> + * currently do, so right now the ioctl value for a given command is the
> + * command itself).
> + *
> + * Hence, we just define the IOCTL_VMCI_foo values directly, with no
> + * intermediate IOCTLCMD_ representation.
> + */
> +#define IOCTLCMD(_cmd) IOCTL_VMCI_ ## _cmd
Huh? I don't understand, why aren't the "normal" macros good enough for
you? What are you doing special from the entire rest of the kernel that
you need to do things differently?
> +enum {
> + /*
> + * We need to bracket the range of values used for ioctls,
> + * because x86_64 Linux forces us to explicitly register ioctl
> + * handlers by value for handling 32 bit ioctl syscalls.
> + * Hence FIRST and LAST. Pick something for FIRST that
> + * doesn't collide with vmmon (2001+).
> + */
> + IOCTLCMD(FIRST) = 1951,
> + IOCTLCMD(VERSION) = IOCTLCMD(FIRST),
I don't understand, what are you doing here with the numbering?
> + /* BEGIN VMCI */
> + IOCTLCMD(INIT_CONTEXT),
> +
> + /*
> + * The following two were used for process and datagram
> + * process creation. They are not used anymore and reserved
> + * for future use. They will fail if issued.
> + */
> + IOCTLCMD(RESERVED1),
> + IOCTLCMD(RESERVED2),
> +
> + /*
> + * The following used to be for shared memory. It is now
> + * unused and and is reserved for future use. It will fail if
> + * issued.
> + */
> + IOCTLCMD(RESERVED3),
> +
> + /*
> + * The follwoing three were also used to be for shared
> + * memory. An old WS6 user-mode client might try to use them
> + * with the new driver, but since we ensure that only contexts
> + * created by VMX'en of the appropriate version
> + * (VMCI_VERSION_NOTIFY or VMCI_VERSION_NEWQP) or higher use
> + * these ioctl, everything is fine.
> + */
> + IOCTLCMD(QUEUEPAIR_SETVA),
> + IOCTLCMD(NOTIFY_RESOURCE),
> + IOCTLCMD(NOTIFICATIONS_RECEIVE),
> + IOCTLCMD(VERSION2),
> + IOCTLCMD(QUEUEPAIR_ALLOC),
> + IOCTLCMD(QUEUEPAIR_SETPAGEFILE),
> + IOCTLCMD(QUEUEPAIR_DETACH),
> + IOCTLCMD(DATAGRAM_SEND),
> + IOCTLCMD(DATAGRAM_RECEIVE),
> + IOCTLCMD(DATAGRAM_REQUEST_MAP),
> + IOCTLCMD(DATAGRAM_REMOVE_MAP),
> + IOCTLCMD(CTX_ADD_NOTIFICATION),
> + IOCTLCMD(CTX_REMOVE_NOTIFICATION),
> + IOCTLCMD(CTX_GET_CPT_STATE),
> + IOCTLCMD(CTX_SET_CPT_STATE),
> + IOCTLCMD(GET_CONTEXT_ID),
> + IOCTLCMD(LAST),
> + /* END VMCI */
> +
> + /*
> + * VMCI Socket
Re: [PATCH 12/12] VMCI: Some header and config files.
On Mon, Oct 29, 2012 at 06:05:38PM -0700, George Zhang wrote: > --- /dev/null > +++ b/drivers/misc/vmw_vmci/Makefile > @@ -0,0 +1,43 @@ > + > +# > +# Linux driver for VMware's VMCI device. > +# > +# Copyright (C) 2007-2012, VMware, Inc. All Rights Reserved. > +# > +# This program is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License as published by the > +# Free Software Foundation; version 2 of the License and no later version. > +# > +# This program is distributed in the hope that it will be useful, but > +# WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or > +# NON INFRINGEMENT. See the GNU General Public License for more > +# details. > +# > +# Maintained by: Andrew Stiegmann > +# > + That's a big boiler-plate for a makefile :) Wait, what's Andrew's name doing here, and yet it isn't on any of the signed-off-by: or From: lines of the driver? Surely you aren't the only contributor here? > +# > +# Makefile for the VMware VMCI > +# That's the only needed comment for this file, if even that. > + > +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o > + > +vmw_vmci-y += vmci_context.o > +vmw_vmci-y += vmci_datagram.o > +vmw_vmci-y += vmci_doorbell.o > +vmw_vmci-y += vmci_driver.o > +vmw_vmci-y += vmci_event.o > +vmw_vmci-y += vmci_guest.o > +vmw_vmci-y += vmci_handle_array.o > +vmw_vmci-y += vmci_host.o > +vmw_vmci-y += vmci_queue_pair.o > +vmw_vmci-y += vmci_resource.o > +vmw_vmci-y += vmci_route.o You can do this cleaner with multiple .o objects on the same line... > +vmci: > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules > + > +clean: > + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean What are these two last targets for? I'm guessing this is from when you ported it from a stand-along module? Please remove them. 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 08/12] VMCI: resource object implementation.
On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote: > VMCI resource tracks all used resources within the vmci code. Same "kref_put() with no lock seen" question in this file, prove me wrong please. 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/
[PATCH] blkcg: fix "scheduling while atomic" in blk_queue_bypass_start
On 10/30/12 02:13, Vivek Goyal wrote:
> On Mon, Oct 29, 2012 at 05:45:15PM +0100, Peter Zijlstra wrote:
>> int radix_tree_preload(gfp_t gfp_mask)
>> {
>> struct radix_tree_preload *rtp;
>> struct radix_tree_node *node;
>> int ret = -ENOMEM;
>>
>> preempt_disable();
>>
>>
>> Seems obvious why it explodes..
>
> Oh right. Thanks Peter. So just calling blk_queue_bypass_start() before
> radix_tree_preload() should fix it. Junichi, can you please give it
> a try.
Thank you! It just works.
This is a revised patch.
With 749fefe677 ("block: lift the initial queue bypass mode on
blk_register_queue() instead of blk_init_allocated_queue()"),
the following warning appears when multipath is used with
CONFIG_PREEMPT=y.
This patch moves blk_queue_bypass_start() before radix_tree_preload()
to avoid the sleeping call while preemption is disabled.
BUG: scheduling while atomic: multipath/2460/0x0002
1 lock held by multipath/2460:
#0: (>type_lock){..}, at: []
dm_lock_md_type+0x17/0x19 [dm_mod]
Modules linked in: ...
Pid: 2460, comm: multipath Tainted: GW3.7.0-rc2 #1
Call Trace:
[] __schedule_bug+0x6a/0x78
[] __schedule+0xb4/0x5e0
[] schedule+0x64/0x66
[] schedule_timeout+0x39/0xf8
[] ? put_lock_stats+0xe/0x29
[] ? lock_release_holdtime+0xb6/0xbb
[] wait_for_common+0x9d/0xee
[] ? try_to_wake_up+0x206/0x206
[] ? kfree_call_rcu+0x1c/0x1c
[] wait_for_completion+0x1d/0x1f
[] wait_rcu_gp+0x5d/0x7a
[] ? wait_rcu_gp+0x7a/0x7a
[] ? complete+0x21/0x53
[] synchronize_rcu+0x1e/0x20
[] blk_queue_bypass_start+0x5d/0x62
[] blkcg_activate_policy+0x73/0x270
[] ? kmem_cache_alloc_node_trace+0xc7/0x108
[] cfq_init_queue+0x80/0x28e
[] ? dm_blk_ioctl+0xa7/0xa7 [dm_mod]
[] elevator_init+0xe1/0x115
[] ? blk_queue_make_request+0x54/0x59
[] blk_init_allocated_queue+0x8c/0x9e
[] dm_setup_md_queue+0x36/0xaa [dm_mod]
[] table_load+0x1bd/0x2c8 [dm_mod]
[] ctl_ioctl+0x1d6/0x236 [dm_mod]
[] ? table_clear+0xaa/0xaa [dm_mod]
[] dm_ctl_ioctl+0x13/0x17 [dm_mod]
[] do_vfs_ioctl+0x3fb/0x441
[] ? file_has_perm+0x8a/0x99
[] sys_ioctl+0x5e/0x82
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
Signed-off-by: Jun'ichi Nomura
Cc: Vivek Goyal
Cc: Tejun Heo
Cc: Jens Axboe
Cc: Alasdair G Kergon
---
block/blk-cgroup.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index d0b7703..954f4be 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -791,10 +791,10 @@ int blkcg_activate_policy(struct request_queue *q,
if (!blkg)
return -ENOMEM;
- preloaded = !radix_tree_preload(GFP_KERNEL);
-
blk_queue_bypass_start(q);
+ preloaded = !radix_tree_preload(GFP_KERNEL);
+
/* make sure the root blkg exists and count the existing blkgs */
spin_lock_irq(q->queue_lock);
--
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/2] staging: csr: Remove CsrEventHandle
Sure, I will. Actually, I sent new patch already :) On Tue, Oct 30, 2012 at 6:58 AM, Greg KH wrote: > > On Sun, Oct 28, 2012 at 03:45:24AM +0900, SeongJae Park wrote: > > No one use CsrEventHandle, No one call functions using it as parameter. > > So those are not need to be here. > > > > Signed-off-by: SeongJae Park > > --- > > drivers/staging/csr/csr_framework_ext.h | 61 > > - > > drivers/staging/csr/csr_framework_ext_types.h |2 - > > 2 files changed, 63 deletions(-) > > Sorry, but someone already did this. Look at the linux-next tree to see > the patch there that cleaned up part of this. But, the second file you > changed here still applies, so can you redo this, and the 2/2 patch and > resend them? > > 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 08/12] VMCI: resource object implementation.
On Mon, Oct 29, 2012 at 06:04:58PM -0700, George Zhang wrote:
> +static struct vmci_resource *vmci_resource_lookup(struct vmci_handle handle)
> +{
> + struct vmci_resource *r, *resource = NULL;
> + struct hlist_node *node;
> + unsigned int idx = vmci_resource_hash(handle);
> +
> + BUG_ON(VMCI_HANDLE_EQUAL(handle, VMCI_INVALID_HANDLE));
You just crashed a machine, with no chance for recovery. Not a good
idea. Never a good idea. Customers just lost data, and now they are
mad. Make sure you at least print out your email address so they know
who to blame :)
Seriously, never BUG() in a driver, warn, sure, but this just looks like
a debugging assert(). Please remove all of these, they are sprinkled
all over the driver code here, I'm only responding to one of them here.
Even better yet, properly handle the error and keep on going, that's
what the rest of the kernel does. Or should :)
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/
[PATCH] staging: csr: Remove struct CsrEvent
Nobody use struct CsrEvent. So, remove it.
Signed-off-by: SeongJae Park
---
drivers/staging/csr/csr_framework_ext_types.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/csr/csr_framework_ext_types.h
b/drivers/staging/csr/csr_framework_ext_types.h
index 627556a..575598c 100644
--- a/drivers/staging/csr/csr_framework_ext_types.h
+++ b/drivers/staging/csr/csr_framework_ext_types.h
@@ -19,24 +19,10 @@
#ifdef __KERNEL__
-struct CsrEvent {
- /* wait_queue for waking the kernel thread */
- wait_queue_head_t wakeup_q;
- unsigned int wakeup_flag;
-};
-
-typedef struct CsrEvent CsrEventHandle;
typedef struct semaphore CsrMutexHandle;
#else /* __KERNEL __ */
-struct CsrEvent {
- pthread_cond_t event;
- pthread_mutex_t mutex;
- u32 eventBits;
-};
-
-typedef struct CsrEvent CsrEventHandle;
typedef pthread_mutex_t CsrMutexHandle;
#endif /* __KERNEL__ */
--
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 05/12] VMCI: event handling implementation.
On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> +static void event_signal_destroy(struct kref *kref)
> +{
> + struct vmci_subscription *entry =
> + container_of(kref, struct vmci_subscription, kref);
> +
> + complete(>done);
> +}
Didn't you just leak memory here? What frees the structure up?
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 05/12] VMCI: event handling implementation.
On Mon, Oct 29, 2012 at 06:04:27PM -0700, George Zhang wrote:
> +/*
> + * Releases the given VMCISubscription.
> + * Fires the destroy event if the reference count has gone to zero.
> + */
> +static void event_release(struct vmci_subscription *entry)
> +{
> + kref_put(>kref, event_signal_destroy);
> +}
Same question as before with the kref_put() call, what is handling the
locking here? It looks like a race to me.
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 04/12] VMCI: device driver implementaton.
On Mon, Oct 29, 2012 at 06:04:15PM -0700, George Zhang wrote:
> +static int __init vmci_core_init(void)
> +{
> + int result;
> +
> + result = vmci_ctx_init();
> + if (result < VMCI_SUCCESS) {
> + pr_err("Failed to initialize VMCIContext (result=%d).\n",
> + result);
If you are going to use pr_* functions, it's usually a good idea to
define pr_fmt in a consistant way so that it shows up the same across
all of your .c files. See other drivers for examples of how to do this
properly.
> + return -EINVAL;
> + }
> +
> + result = vmci_datagram_init();
> + if (result < VMCI_SUCCESS) {
> + pr_err("Failed to initialize VMCIDatagram (result=%d).\n",
> + result);
> + return -EINVAL;
> + }
> +
> + result = vmci_event_init();
> + if (result < VMCI_SUCCESS) {
> + pr_err("Failed to initialize VMCIEvent (result=%d).\n", result);
> + return -EINVAL;
> + }
You don't free and unwind things properly if things go wrong here, why
not?
> +
> + return 0;
> +}
> +
> +static void __exit vmci_core_exit(void)
> +{
> + vmci_event_exit();
> +}
> +
> +static int __init vmci_drv_init(void)
> +{
> + int error;
> +
> + error = vmci_core_init();
> + if (error)
> + return error;
> +
> + if (!vmci_disable_guest) {
> + error = vmci_guest_init();
> + if (error) {
> + pr_warn("Failed to initialize guest personality
> (err=%d).\n",
> + error);
> + } else {
> + vmci_guest_personality_initialized = true;
> + pr_info("Guest personality initialized and is %s\n",
> + vmci_guest_code_active() ?
> + "active" : "inactive");
> + }
> + }
> +
> + if (!vmci_disable_host) {
> + error = vmci_host_init();
> + if (error) {
> + pr_warn("Unable to initialize host personality
> (err=%d).\n",
> + error);
> + } else {
> + vmci_host_personality_initialized = true;
> + pr_info("Initialized host personality\n");
> + }
> + }
> +
> + if (!vmci_guest_personality_initialized &&
> + !vmci_host_personality_initialized) {
> + vmci_core_exit();
> + return -ENODEV;
> + }
> +
> + pr_debug("Module is initialized\n");
Really? You need this message still?
> + return 0;
> +}
> +module_init(vmci_drv_init);
> +
> +static void __exit vmci_drv_exit(void)
> +{
> + if (vmci_guest_personality_initialized)
> + vmci_guest_exit();
> +
> + if (vmci_host_personality_initialized)
> + vmci_host_exit();
> +
> + vmci_core_exit();
> + pr_debug("Module is unloaded\n");
Same here, is this really needed?
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 04/12] VMCI: device driver implementaton.
On Mon, Oct 29, 2012 at 06:04:15PM -0700, George Zhang wrote:
> +/*
> + * vmci_get_context_id() - Gets the current context ID.
> + *
> + * Returns the current context ID. Note that since this is accessed only
> + * from code running in the host, this always returns the host context ID.
> + */
> +u32 vmci_get_context_id(void)
> +{
> + if (vmci_guest_code_active()) {
> + return vmci_get_vm_context_id();
> + } else if (vmci_host_code_active()) {
> + return VMCI_HOST_CONTEXT_ID;
> + } else {
> + return VMCI_INVALID_ID;
> + }
> +}
> +EXPORT_SYMBOL_GPL(vmci_get_context_id);
checkpatch didn't complain about too many { } here?
> +/*
> + * vmci_version() - Returns the version of the driver.
> + *
> + * Returns the version of the VMCI driver.
> + */
> +u32 vmci_version(void)
> +{
> + return VMCI_VERSION;
> +}
> +EXPORT_SYMBOL_GPL(vmci_version);
Why is this needed? Why would a kernel driver ever care about this?
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 00/12] VMCI for Linux upstreaming
On Mon, Oct 29, 2012 at 06:03:28PM -0700, George Zhang wrote: > drivers/misc/Kconfig |1 > drivers/misc/Makefile |2 > drivers/misc/vmw_vmci/Kconfig | 16 > drivers/misc/vmw_vmci/Makefile| 43 Meta comment here, why drivers/misc/? The other hypervisor infrastructures all have their own directory under drivers/ Should we be moving everything to drivers/hyperv/ somehow? 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 v3 4/9] clear the memory to store struct page
At 10/30/2012 05:10 AM, Andrew Morton Wrote: > On Fri, 26 Oct 2012 17:44:06 +0800 > Wen Congyang wrote: > >> This patch has been acked by kosaki motohiro. Is it OK to be merged >> into -mm tree? > > I'd already merged the v2 patchset when you later sent out the v3 > patchset which contains some of the material from v2 plus more things. > > I can drop all of v2 and remerge v3. But I see from the discussion > under "[PATCH v3 6/9] memory-hotplug: update mce_bad_pages when > removing the memory" that you intend to send out a v4 patchset. OK, I will send out a v4 patchset. Do I need to resend the patch which is in -mm tree and has no comment? Thanks Wen Congyang > > This is all a bit of a mess. Piecemeal picking-and-choosing of various > patches from various iterations of the same patchset is confusing and > error-prone. > > Please, take a look at the current -mm tree at > http://ozlabs.org/~akpm/mmots/ then come up with a plan for us. We can > either add new patches or we can drop old patches and replace 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/ > -- 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 01/12] VMCI: context implementation.
On Mon, Oct 29, 2012 at 06:03:42PM -0700, George Zhang wrote:
> +/*
> + * Releases the VMCI context. If this is the last reference to
> + * the context it will be deallocated. A context is created with
> + * a reference count of one, and on destroy, it is removed from
> + * the context list before its reference count is
> + * decremented. Thus, if we reach zero, we are sure that nobody
> + * else are about to increment it (they need the entry in the
> + * context list for that). This function musn't be called with a
> + * lock held.
> + */
> +void vmci_ctx_release(struct vmci_ctx *context)
> +{
> + ASSERT(context);
> + kref_put(>kref, ctx_free_ctx);
> +}
> +
Hm, are you _sure_ you should be calling this without a lock held?
That's usually kref-101, you MUST hold a lock when calling put,
otherwise you can race a kref_get() call, and all hell can break loose.
Because of this, some saner people (like Al Viro), have suggested that I
force the kref_put() and kref_get() calls pass in a spinlock just to
enforce this.
So, tell me what I'm missing here, and why you put the comment here
saying that it really is supposed to be called without a lock held? How
is that safe?
confused,
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 01/12] VMCI: context implementation.
On Mon, Oct 29, 2012 at 06:03:42PM -0700, George Zhang wrote:
> VMCI Context code maintains state for vmci and allows the driver to
> communicate with multiple VMs.
>
Very minor nit, wrap your changelog comments at 72 columns or at the
least, 80. Didn't checkpatch complain about that?
> +/*
> + * vmci_context_id_to_host_vmid() - Map CID to HostID
> + * @context_id: Context ID of VMCI context.
> + * @host_vmid: Host VM ID data
> + * @host_vmid_len: Length of Host VM ID Data.
> + *
> + * Maps a context ID to the host specific (process/world) ID
> + * of the VM/VMX. This function is not used on Linux systems
> + * and should be ignored.
> + */
> +int vmci_context_id_to_host_vmid(u32 context_id,
> + void *host_vmid, size_t host_vmid_len)
> +{
> + return VMCI_ERROR_UNAVAILABLE;
> +}
> +EXPORT_SYMBOL_GPL(vmci_context_id_to_host_vmid);
Why even have this function if it doesn't do anything?
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 2/4] arch/arm: move secure_computing into trace
On Mon, Oct 29, 2012 at 05:41:20PM -0700, Kees Cook wrote: > From: Will Drewry > > There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE > path in entry-common.S. In order to add support for > CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too badly, > seccomp was moved into the syscall_trace_enter() handler. > > Additionally, the return value for secure_computing() is now checked > and a -1 value will result in the system call being skipped. This is too ugly. Just expand the calls of ptrace_syscall_trace() into both callers and do secure_computing() hookup in there. And for pity sake, would somebody rename the damn thing? It's *dripping* with marketdroidese... -- 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: [git pull] PCI pull request for 2.6.29
On Wed, Jan 7, 2009 at 2:30 PM, Jesse Barnes wrote: > > Arjan van de Ven (1): > resource: allow MMIO exclusivity for device drivers > hi, all commit e8de1481fd7126ee9e93d6889da6f00c05e1e019 Author: Arjan van de Ven Date: Wed Oct 22 19:55:31 2008 -0700 resource: allow MMIO exclusivity for device drivers only user is e1000e driver. and real fix http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4a7703582836f55a1cbad0e2c1c6ebbee3f9b3a7 is already in the upsteam for https://bugzilla.redhat.com/show_bug.cgi?id=459202 so wonder if e8de1481fd7126ee9e93d6889da6f00c05e1e019 should be reverted from upstream? Thanks Yinghai -- 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: x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."
Am 30.10.2012 00:01, schrieb Greg Kroah-Hartman: Can you test out 3.6.5-rc1 and see if that works properly for you or not? It should have all of the fixes in it already. Just in time before I receive my new "memory layout" which might not have the problem with 3.6.4. ;) 3.6.5-rc1 booted just fine, thanks a lot. Regards, Alexander -- 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 2/9] uuid: use random32_get_bytes()
On Mon, 2012-10-29 at 16:52 -0400, Theodore Ts'o wrote: > On Sun, Oct 28, 2012 at 04:18:59PM +0900, Akinobu Mita wrote: > > Use random32_get_bytes() to generate 16 bytes of pseudo-random bytes. > > > > Signed-off-by: Akinobu Mita > > Since your patch is going to allow users to set the random seed, it > means that what had previously been a bad security bug has just become > a grievous security bug. If you are going to be generating UUID's > they _must_ use a truly random random generator, since the whole point > of uuid's is that they be unique. If someone can trivially set the > random seed of a prng, and thus cause the uuid generator to generate, > well, non-unique UUID's, the results can range anywhere from > confusion, to file system corruption and data loss. > > Fortunately, there is only one user of lib/uuid.c, and that's the > btrfs file system. > > Chris and the Btrfs folks --- my recommendation would be to ditch the > use of uuid_be_gen, "git rm lib/uuid.c" with extreme prejudice, and > use generate_random_uuid() which was coded over a decade ago in > drivers/char/random.c. Not only does this properly use the kernel > random number generator, but it also creates a UUID with the correct > format. (It's not enough to set the UUID version to 4; you also need > to set the UUID variant to be DCE if you want to be properly compliant > with RFC 4122 --- see section 4.1.1.) The uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE, that is done in __uuid_gen_common() with "b[8] = (b[8] & 0x3F) | 0x80". To deal with random number generation issue, how about use get_random_bytes() in __uuid_gen_common()? > The btrfs file system doesn't generate uuid's in any critical fast > paths as near as I can determine, so it should be perfectly safe to > use uuid_generate() --- I also would drop the whole distinction > between little-endian and big-endian uuid's, BTW. RFC 4122 is quite > explicit about how uuid's should be encoded, and it's in internet byte > order. This is what OSF/DCE uses, and it's what the rest of the world > (Microsoft, SAP AG, Apple, GNOME, KDE) uses as well. uuid_be complies RFC4122, it uses internet byte order. But EFI uses little endian. Best Regards, Huang Ying -- 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: drm i915 hangs on heavy io load
On Tue, 30 Oct 2012 10:01:38 +0900 Norbert Preining wrote: > Hi Dave, > > On Di, 30 Okt 2012, Dave Airlie wrote: > > > Thanks, running now with SNA. Let us see what happens. > > > > Please don't, we ain't going to find the bug any quicker changing > > variables, if the only thing that changed on your system was the > > Sorry, didn't know. I supposed from the email of Chris that I should > try it "to stress different code path" ... anyway, disabling it again. > > > How long does it take you to reproduce, and does it happen when in > > Very hard to say, most of the times it is in a few days scale. > Though it happened also after a few hours once. > > > actual use. On my laptop I've noticed I come back to it sometimes > > and > > Concerning actual use: I had instances on several occassions. Just > 30min ago it was while working with shotwell on my photo collection, > tagging photos. So there should not be a big disk activity or so, but > a lot of screen redraws etc when going through the photos. > On other times it was locked screen without screen saver. > > Concerning coming back: For me it never worked. I always have to > reboot to get a working state again. Ok, to be more specific. GNome3 > is dead. I can close the windows normally with kbd shortcuts and some > mouse interaction, but no new windows, no moving etc. > > > gnome-shell is dead. This never happened pre 3.7-rc's. But for me > > its a 3-4 day window so far for it to die, which makes bisecting it > > a bit > > That sounds pretty much like my case, but since I often don't use > the laptop for 2 days or so, it might be a bit longer. > > > of a major problem. and I'm just finished bisecting the last > > Ironlake regression that took over a month. > > Ouch ... > > > I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 > > final to 3.7-rc1 or maybe -rc2. > > Ok, thanks. I will try. > > Best wishes > > Norbert Hi Norbert. In addition to the above, if this truly appears to be related to i/o, can we try to decrease the time to failure with some serious i/o tests? Off the top of my head I am not sure what's available, but surely Google should be able to find something. -- Ben Widawsky, 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: [PATCH v2 10/12] memory-hotplug: memory_hotplug: clear zone when removing the memory
At 10/29/2012 11:34 PM, Jianguo Wu Wrote:
> On 2012/10/23 18:30, we...@cn.fujitsu.com wrote:
>> From: Yasuaki Ishimatsu
>>
>> When a memory is added, we update zone's and pgdat's start_pfn and
>> spanned_pages in the function __add_zone(). So we should revert them
>> when the memory is removed.
>>
>> The patch adds a new function __remove_zone() to do this.
>>
>> CC: David Rientjes
>> CC: Jiang Liu
>> CC: Len Brown
>> CC: Christoph Lameter
>> Cc: Minchan Kim
>> CC: Andrew Morton
>> CC: KOSAKI Motohiro
>> Signed-off-by: Yasuaki Ishimatsu
>> Signed-off-by: Wen Congyang
>> ---
>> mm/memory_hotplug.c | 207
>> +++
>> 1 files changed, 207 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 03153cf..55a228d 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -312,10 +312,213 @@ static int __meminit __add_section(int nid, struct
>> zone *zone,
>> return register_new_memory(nid, __pfn_to_section(phys_start_pfn));
>> }
>>
>> +/* find the smallest valid pfn in the range [start_pfn, end_pfn) */
>> +static int find_smallest_section_pfn(int nid, struct zone *zone,
>> + unsigned long start_pfn,
>> + unsigned long end_pfn)
>> +{
>> +struct mem_section *ms;
>> +
>> +for (; start_pfn < end_pfn; start_pfn += PAGES_PER_SECTION) {
>> +ms = __pfn_to_section(start_pfn);
>> +
>> +if (unlikely(!valid_section(ms)))
>> +continue;
>> +
>> +if (unlikely(pfn_to_nid(start_pfn)) != nid)
>
> if (unlikely(pfn_to_nid(start_pfn) != nid))
Thanks for pointing it out. I will fix it soon.
Wen Congyang
>
>> +continue;
>> +
>> +if (zone && zone != page_zone(pfn_to_page(start_pfn)))
>> +continue;
>> +
>> +return start_pfn;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/* find the biggest valid pfn in the range [start_pfn, end_pfn). */
>> +static int find_biggest_section_pfn(int nid, struct zone *zone,
>> +unsigned long start_pfn,
>> +unsigned long end_pfn)
>> +{
>> +struct mem_section *ms;
>> +unsigned long pfn;
>> +
>> +/* pfn is the end pfn of a memory section. */
>> +pfn = end_pfn - 1;
>> +for (; pfn >= start_pfn; pfn -= PAGES_PER_SECTION) {
>> +ms = __pfn_to_section(pfn);
>> +
>> +if (unlikely(!valid_section(ms)))
>> +continue;
>> +
>> +if (unlikely(pfn_to_nid(pfn)) != nid)
>
> if (unlikely(pfn_to_nid(pfn) != nid))
>
>> +continue;
>> +
>> +if (zone && zone != page_zone(pfn_to_page(pfn)))
>> +continue;
>> +
>> +return pfn;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void shrink_zone_span(struct zone *zone, unsigned long start_pfn,
>> + unsigned long end_pfn)
>> +{
>> +unsigned long zone_start_pfn = zone->zone_start_pfn;
>> +unsigned long zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
>> +unsigned long pfn;
>> +struct mem_section *ms;
>> +int nid = zone_to_nid(zone);
>> +
>> +zone_span_writelock(zone);
>> +if (zone_start_pfn == start_pfn) {
>> +/*
>> + * If the section is smallest section in the zone, it need
>> + * shrink zone->zone_start_pfn and zone->zone_spanned_pages.
>> + * In this case, we find second smallest valid mem_section
>> + * for shrinking zone.
>> + */
>> +pfn = find_smallest_section_pfn(nid, zone, end_pfn,
>> +zone_end_pfn);
>> +if (pfn) {
>> +zone->zone_start_pfn = pfn;
>> +zone->spanned_pages = zone_end_pfn - pfn;
>> +}
>> +} else if (zone_end_pfn == end_pfn) {
>> +/*
>> + * If the section is biggest section in the zone, it need
>> + * shrink zone->spanned_pages.
>> + * In this case, we find second biggest valid mem_section for
>> + * shrinking zone.
>> + */
>> +pfn = find_biggest_section_pfn(nid, zone, zone_start_pfn,
>> + start_pfn);
>> +if (pfn)
>> +zone->spanned_pages = pfn - zone_start_pfn + 1;
>> +}
>> +
>> +/*
>> + * The section is not biggest or smallest mem_section in the zone, it
>> + * only creates a hole in the zone. So in this case, we need not
>> + * change the zone. But perhaps, the zone has only hole data. Thus
>> + * it check the zone has only hole or not.
>> + */
>> +pfn = zone_start_pfn;
>> +for (; pfn < zone_end_pfn; pfn += PAGES_PER_SECTION) {
>> +ms = __pfn_to_section(pfn);
>> +
>> +if
[PATCH 2/4] arch/arm: move secure_computing into trace
From: Will Drewry
There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE
path in entry-common.S. In order to add support for
CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too badly,
seccomp was moved into the syscall_trace_enter() handler.
Additionally, the return value for secure_computing() is now checked
and a -1 value will result in the system call being skipped.
Signed-off-by: Will Drewry
Signed-off-by: Kees Cook
---
arch/arm/kernel/entry-common.S |9 ++---
arch/arm/kernel/ptrace.c |3 +++
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 3471175..c781012 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -418,13 +418,8 @@ local_restart:
stmdb sp!, {r4, r5} @ push fifth and sixth args
#ifdef CONFIG_SECCOMP
- tst r10, #_TIF_SECCOMP
- beq 1f
- mov r0, scno
- bl __secure_computing
- add r0, sp, #S_R0 + S_OFF @ pointer to regs
- ldmia r0, {r0 - r3} @ have to reload r0 - r3
-1:
+ tst r10, #_TIF_SECCOMP @ is seccomp enabled?
+ bne __sys_trace
#endif
tst r10, #_TIF_SYSCALL_WORK @ are we tracing syscalls?
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 739db3a..aa4d93f 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -923,6 +923,9 @@ static int ptrace_syscall_trace(struct pt_regs *regs, int
scno,
current_thread_info()->syscall = scno;
+ if (dir == PTRACE_SYSCALL_ENTER && secure_computing(scno) == -1)
+ return -1;
+
if (!test_thread_flag(TIF_SYSCALL_TRACE))
return scno;
--
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] hrtimer: Printing timer info when hitting BUG_ON()
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().
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);
}
--
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/
[RFC v2] Support volatile range for anon vma
This patch introudces new madvise behavior MADV_VOLATILE and MADV_NOVOLATILE for anonymous pages. It's different with John Stultz's version which considers only tmpfs while this patch considers only anonymous pages so this cannot cover John's one. If below idea is proved as reasonable, I hope we can unify both concepts by madvise/fadvise. Rationale is following as. Many allocators call munmap(2) when user call free(3) if ptr is in mmaped area. But munmap isn't cheap because it have to clean up all pte entries and unlinking a vma so overhead would be increased linearly by mmaped area's size. Volatile conecept of Robert Love could be very useful for reducing free(3) overhead. Allocators can do madvise(MADV_VOLATILE) instead of munmap(2)(Of course, they need to manage volatile mmaped area to reduce shortage of address space and sometime ends up unmaping them). The madvise(MADV_VOLATILE|NOVOLATILE) is very cheap opeartion because 1) it just marks the flag in VMA and 2) if memory pressure happens, VM can discard pages of volatile VMA instead of swapping out when volatile pages is selected as victim by normal VM aging policy. 3) freed mmaped area doesn't include any meaningful data so there is no point to swap them out. Allocator should call madvise(MADV_NOVOLATILE) before reusing for allocating that area to user. Otherwise, accessing of volatile range will meet SIGBUS error. The downside is that we have to age anon lru list although we don't have swap because I don't want to discard volatile pages by top priority when memory pressure happens as volatile in this patch means "We don't need to swap out because user can handle the situation which data are disappear suddenly", NOT "They are useless so hurry up to reclaim them". So I want to apply same aging rule of nomal pages to them. Anon background aging of non-swap system would be a trade-off for getting good feature. Even, we had done it two years ago until merge [1] and I believe free(3) performance gain will beat loss of anon lru aging's overead once all of allocator start to use madvise. (This patch doesn't include background aging in case of non-swap system but it's trivial if we decide) I hope seeing opinions from others before diving into glibc or bionic. Welcome to any comment. [1] 74e3f3c3, vmscan: prevent background aging of anon page in no swap system Changelog * from RFC v1 * add clear comment of purge - Christoph * Change patch descritpion Cc: John Stultz Cc: Andrew Morton Cc: Christoph Lameter Cc: Android Kernel Team Cc: Robert Love Cc: Mel Gorman Cc: Hugh Dickins Cc: Dave Hansen Cc: Rik van Riel Cc: Dave Chinner Cc: Neil Brown Cc: Mike Hommey Cc: Taras Glek Cc: KOSAKI Motohiro Cc: Christoph Lameter Cc: KAMEZAWA Hiroyuki Signed-off-by: Minchan Kim --- include/asm-generic/mman-common.h |3 + include/linux/mm.h|9 ++- include/linux/mm_types.h |5 ++ include/linux/rmap.h | 24 ++- mm/ksm.c |4 +- mm/madvise.c | 32 +- mm/memory.c |2 + mm/migrate.c |6 +- mm/rmap.c | 126 +++-- mm/vmscan.c |3 + 10 files changed, 202 insertions(+), 12 deletions(-) diff --git a/include/asm-generic/mman-common.h b/include/asm-generic/mman-common.h index d030d2c..5f8090d 100644 --- a/include/asm-generic/mman-common.h +++ b/include/asm-generic/mman-common.h @@ -34,6 +34,9 @@ #define MADV_SEQUENTIAL2 /* expect sequential page references */ #define MADV_WILLNEED 3 /* will need these pages */ #define MADV_DONTNEED 4 /* don't need these pages */ +#define MADV_VOLATILE 5 /* pages will disappear suddenly */ +#define MADV_NOVOLATILE 6 /* pages will not disappear */ + /* common parameters: try to keep these consistent across architectures */ #define MADV_REMOVE9 /* remove these pages & resources */ diff --git a/include/linux/mm.h b/include/linux/mm.h index 311be90..78c8c08 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -120,6 +120,13 @@ extern unsigned int kobjsize(const void *objp); #define VM_PFN_AT_MMAP 0x4000 /* PFNMAP vma that is fully mapped at mmap time */ #define VM_MERGEABLE 0x8000 /* KSM may merge identical pages */ +/* + * Recently, Konstantin removed a few flags but not merged yet + * so we will get a room for new flag for supporting 32 bit. + * Thanks, Konstantin! + */ +#define VM_VOLATILE0x1 + /* Bits set in the VMA until the stack is in its final location */ #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ) @@ -143,7 +150,7 @@ extern unsigned int kobjsize(const void *objp); * Special vmas that are non-mergable, non-mlock()able. * Note: mm/huge_memory.c VM_NO_THP depends on this definition. */
Re: Regression from 3.4.9 to 3.4.16 "stable" kernel
On Mon, Oct 29, 2012 at 4:03 PM, Greg Kroah-Hartman wrote: > On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote: >> Both systems feel much more sluggish than usual with 3.4.16 running. >> Reverted them both back to earlier kernels (3.4.9, 3.4.4-PAE), >> and the usual responsive feel has returned. >> >> Vague, I know, but something bad happened in there somewhere. > > That's too vague for me to do anything with, sorry. Bisection would be > good if you can figure out how to measure this. yes, at least you can post boot log of working kernel and not working kernel. then we could figure out if there is any corner case is not handled or uncovered. -- 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-audit: reconstruct path names from syscall events?
On Thu, Oct 11, 2012 at 10:27 AM, Mark Moseley wrote:
> On Wed, Oct 10, 2012 at 4:07 PM, Mark Moseley wrote:
>> On Wed, Oct 10, 2012 at 4:00 PM, Steve Grubb wrote:
>>> On Wednesday, October 10, 2012 03:45:08 PM Mark Moseley wrote:
On Tue, Oct 9, 2012 at 4:54 PM, Al Viro wrote:
> Again, relying on pathnames for forensics (or security in general) is
> a serious mistake (cue unprintable comments about apparmor and similar
> varieties of snake oil). And using audit as poor man's ktrace analog
> is... misguided, to put it very mildly.
Caveat: I'm just a sysadmin, so this stuff is as darn near "magic" as
I get to see on a regular basis, so it's safe to expect some naivety
and/or misguidedness on my part :)
I'm just using it as a log of files that have been written/changed on
moderately- to heavily-used systems. If there's another in-kernel
mechanism that'd be better suited for that sort of thing (at least
without adding a lot of overhead), I'd be definitely eager to know
about it. It's a web hosting environment, with customer files all
solely on NFS, so writes to the same directory can come from an
arbitrary number of servers. When they get swamped with write
requests, the amount of per-client stats exposed by our Netapp and
Oracle NFS servers is often only enough to point us at a client server
with an abusive user on it (but not much more, without turning on
debugging). Having logs of who's doing writes would be quite useful,
esp when writes aren't happening at that exact moment and wouldn't
show up in tools like iotop. The audit subsystem seemed like the best
fit for this kind of thing, but I'm more than open to whatever works.
>>>
>>> The audit system is the best fit. But I think Al is saying there are some
>>> limitations. i know that Eric pushed some patches a while back that makes a
>>> stronger effort at collecting some of this information. What kernel are you
>>> using?
Would you happen to have a pointer to those patches? I've been surfing
the archives and not gotten lucky yet with finding the applicable
patchset.
>> Yup, understood. I've been playing with a variety of boxes, but mostly
>> within the 3.0.x and 3.2.x series. I'll drop 3.5.6 on some of these
>> boxes and see if my issues are already fixed (and proceed directly to
>> foot-in-mouth chagrined stage -- usually takes slightly longer to get
>> to that stage).
>
> Just gave 3.5.6 a shot and in these two particular cases, the result
> is the same: chroot'd actions are logged in the audit entry relative
> to the chroot, and the unlinkat/chmodat/chownat audit log entries only
> have one item with the bare filename and no indication of directory.
renameat seems to be the toughest of all of them (where
unlinkat/chmodat/chownat give you a hint in another audit entry). This
is doing a renameat(), from /home/moseley/tmp/tmp/renameat/1/a1 to
/home/moseley/tmp/tmp/renameat/2/a2
type=SYSCALL msg=audit(1351557710.520:74211): arch=c03e
syscall=264 success=yes exit=0 a0=3 a1=40075c a2=4 a3=400759 items=4
ppid=22742 pid=15181 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts17 ses=1727 comm="rename" exe="/tmp/rename"
key=(null)
type=CWD msg=audit(1351557710.520:74211): cwd="/tmp"
type=PATH msg=audit(1351557710.520:74211): item=0 name="/tmp"
inode=2367550 dev=08:02 mode=040775 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1351557710.520:74211): item=1 name="/tmp"
inode=2367551 dev=08:02 mode=040775 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1351557710.520:74211): item=2 name="a1"
inode=2367552 dev=08:02 mode=0100664 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1351557710.520:74211): item=3 name="a2"
inode=2367552 dev=08:02 mode=0100664 ouid=1000 ogid=1000 rdev=00:00
Anything else I could/should be trying? I'm more than willing to
experiment. I just always assume I'm missing some key flag or
something.
Here's the simple example code ... and, yes, I *do* know how to use
variables, just didn't bother here ;)
#include
#include
#include
#include
int main() {
DIR *a;
DIR *b;
char* dir1 = "/home/moseley/tmp/tmp/renameat/1";
char* dir2 = "/home/moseley/tmp/tmp/renameat/2";
a = opendir( dir1 );
b = opendir( dir2 );
int afd = dirfd( a );
int bfd = dirfd( b );
renameat( afd, "a1", bfd, "a2" );
}
--
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] x86/ioapic: Fix the vector_irq[] is corrupted randomly
> -Original Message- > From: Siddha, Suresh B > Sent: Tuesday, October 30, 2012 4:24 AM > To: Liu, Chuansheng > Cc: mi...@redhat.com; h...@zytor.com; t...@linutronix.de; > ying...@kernel.org; x...@kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] x86/ioapic: Fix the vector_irq[] is corrupted randomly > > On Tue, 2012-10-30 at 00:15 +0800, Chuansheng Liu wrote: > > Not all irq chips are IO-APIC chip. > > > > In our system, there are many demux GPIO interrupts except for the > > io-apic chip interrupts, and these GPIO interrupts are belonged > > to other irq chips, the chip data is not type of struct irq_cfg > > either. > > > > But in function __setup_vector_irq(), it listed all allocated irqs, > > and presume all irq chip is ioapic_chip and the chip data is type > > of struct irq_cfg, it possibly causes the vector_irq is corrupted > > randomly. > > > > For example, one irq 258 is not io-apic chip irq, in __setup_vector_irq(), > > the chip data is forced to be used as struct irq_cfg, then the value > > cfg->domain and cfg->vector are wrong to be used to write vector_irq: > > vector = cfg->vector; > > per_cpu(vector_irq, cpu)[vector] = irq; > > > > This patch use the .flags to identify if the irq chip is io-apic. > > I have a feeling that your gpio driver is abusing the 'chip_data' in the > struct irq_data. Shouldn't the driver be using 'handler_data' instead? Not abusing. There are many driver codes which has their own chip and chip_data. For example, langwell_gpio.c, the chip_data type is struct lnw_gpio; gpio_omap.c, the chip_data type is struct gpio_bank; In these cases, if we abused the gpio chip_data type with struct irq_cfg, we will get very wrong cfg->vector, the value maybe 1 or 1000, anyway, it is a random value. > > From include/linux/irq.h: > * @handler_data: per-IRQ data for the irq_chip methods > * @chip_data: platform-specific per-chip private data for the chip > * methods, to allow shared chip implementations > > Also, how are these routed to the processors and the mechanism of the > vector assignment for these irq's? I presume irq_cfg is needed for the > setup and the interrupt migration from one cpu to another. Normally gpio chip just has only one base irq is related with io-apic interrupt, other allocated *VIRTUAL* irqs are based on this base irq, so no vector assign to them. But in code __setup_vector_irq(), it list all allocated irqs which include the *VIRTUAL* irqs, It causes this case that chip_data type is abused. > > What am I missing? > > thanks, > suresh
[PATCH 12/12] VMCI: Some header and config files.
VMCI head config patch Adds all the necessary files to enable building of the VMCI module with the Linux Makefiles and Kconfig systems. Also adds the header files used for building modules against the driver. Signed-off-by: George Zhang --- drivers/misc/Kconfig|1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 + drivers/misc/vmw_vmci/Makefile | 43 + drivers/misc/vmw_vmci/vmci_common_int.h | 34 + include/linux/vmw_vmci_api.h| 85 +++ include/linux/vmw_vmci_defs.h | 977 +++ 7 files changed, 1158 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/vmw_vmci/Kconfig create mode 100644 drivers/misc/vmw_vmci/Makefile create mode 100644 drivers/misc/vmw_vmci/vmci_common_int.h create mode 100644 include/linux/vmw_vmci_api.h create mode 100644 include/linux/vmw_vmci_defs.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2661f6e..fe38c7a 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -517,4 +517,5 @@ source "drivers/misc/lis3lv02d/Kconfig" source "drivers/misc/carma/Kconfig" source "drivers/misc/altera-stapl/Kconfig" source "drivers/misc/mei/Kconfig" +source "drivers/misc/vmw_vmci/Kconfig" endmenu diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 456972f..21ed953 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -51,3 +51,5 @@ obj-y += carma/ obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/ obj-$(CONFIG_INTEL_MEI)+= mei/ +obj-$(CONFIG_MAX8997_MUIC) += max8997-muic.o +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/ diff --git a/drivers/misc/vmw_vmci/Kconfig b/drivers/misc/vmw_vmci/Kconfig new file mode 100644 index 000..55015e7 --- /dev/null +++ b/drivers/misc/vmw_vmci/Kconfig @@ -0,0 +1,16 @@ +# +# VMware VMCI device +# + +config VMWARE_VMCI + tristate "VMware VMCI Driver" + depends on X86 + help + This is VMware's Virtual Machine Communication Interface. It enables + high-speed communication between host and guest in a virtual + environment via the VMCI virtual device. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called vmw_vmci. diff --git a/drivers/misc/vmw_vmci/Makefile b/drivers/misc/vmw_vmci/Makefile new file mode 100644 index 000..be09746 --- /dev/null +++ b/drivers/misc/vmw_vmci/Makefile @@ -0,0 +1,43 @@ + +# +# Linux driver for VMware's VMCI device. +# +# Copyright (C) 2007-2012, VMware, Inc. All Rights Reserved. +# +# This program is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the +# Free Software Foundation; version 2 of the License and no later version. +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or +# NON INFRINGEMENT. See the GNU General Public License for more +# details. +# +# Maintained by: Andrew Stiegmann +# + + +# +# Makefile for the VMware VMCI +# + +obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci.o + +vmw_vmci-y += vmci_context.o +vmw_vmci-y += vmci_datagram.o +vmw_vmci-y += vmci_doorbell.o +vmw_vmci-y += vmci_driver.o +vmw_vmci-y += vmci_event.o +vmw_vmci-y += vmci_guest.o +vmw_vmci-y += vmci_handle_array.o +vmw_vmci-y += vmci_host.o +vmw_vmci-y += vmci_queue_pair.o +vmw_vmci-y += vmci_resource.o +vmw_vmci-y += vmci_route.o + +vmci: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m modules + +clean: + $(MAKE) -C ../../.. SUBDIRS=$$PWD CONFIG_VMWARE_VMCI=m clean diff --git a/drivers/misc/vmw_vmci/vmci_common_int.h b/drivers/misc/vmw_vmci/vmci_common_int.h new file mode 100644 index 000..77667ec --- /dev/null +++ b/drivers/misc/vmw_vmci/vmci_common_int.h @@ -0,0 +1,34 @@ +/* + * VMware VMCI Driver + * + * Copyright (C) 2012 VMware, Inc. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation version 2 and no later version. + * + * This program is distributed in the hope that 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. + */ + +#ifndef _VMCI_COMMONINT_H_ +#define _VMCI_COMMONINT_H_ + +#include + +#define ASSERT(cond) BUG_ON(!(cond)) + +#define PCI_VENDOR_ID_VMWARE 0x15AD +#define PCI_DEVICE_ID_VMWARE_VMCI 0x0740 +#define
[PATCH 11/12] VMCI: host side driver implementation.
VMCI host side driver code implementation.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_host.c | 1046 +
1 files changed, 1046 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_host.c
diff --git a/drivers/misc/vmw_vmci/vmci_host.c
b/drivers/misc/vmw_vmci/vmci_host.c
new file mode 100644
index 000..9cab365
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_host.c
@@ -0,0 +1,1046 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_handle_array.h"
+#include "vmci_common_int.h"
+#include "vmci_queue_pair.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_resource.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+
+#define VMCI_UTIL_NUM_RESOURCES 1
+
+enum {
+ VMCI_NOTIFY_RESOURCE_QUEUE_PAIR = 0,
+ VMCI_NOTIFY_RESOURCE_DOOR_BELL = 1,
+};
+
+enum {
+ VMCI_NOTIFY_RESOURCE_ACTION_NOTIFY = 0,
+ VMCI_NOTIFY_RESOURCE_ACTION_CREATE = 1,
+ VMCI_NOTIFY_RESOURCE_ACTION_DESTROY = 2,
+};
+
+/*
+ * VMCI driver initialization. This block can also be used to
+ * pass initial group membership etc.
+ */
+struct vmci_init_blk {
+ u32 cid;
+ u32 flags;
+};
+
+/* VMCIqueue_pairAllocInfo_VMToVM */
+struct vmci_qp_alloc_info_vmvm {
+ struct vmci_handle handle;
+ u32 peer;
+ u32 flags;
+ u64 produce_size;
+ u64 consume_size;
+ u64 produce_page_file;/* User VA. */
+ u64 consume_page_file;/* User VA. */
+ u64 produce_page_file_size; /* Size of the file name array. */
+ u64 consume_page_file_size; /* Size of the file name array. */
+ s32 result;
+ u32 _pad;
+};
+
+/* VMCISetNotifyInfo: Used to pass notify flag's address to the host driver. */
+struct vmci_set_notify_info {
+ u64 notify_uva;
+ s32 result;
+ u32 _pad;
+};
+
+/*
+ * Per-instance host state
+ */
+struct vmci_host_dev {
+ struct vmci_ctx *context;
+ int user_version;
+ enum vmci_obj_type ct_type;
+ struct mutex lock; /* Mutex lock for vmci context access */
+};
+
+static struct vmci_ctx *host_context;
+static bool vmci_host_device_initialized;
+static atomic_t vmci_host_active_users = ATOMIC_INIT(0);
+
+/*
+ * Determines whether the VMCI host personality is
+ * available. Since the core functionality of the host driver is
+ * always present, all guests could possibly use the host
+ * personality. However, to minimize the deviation from the
+ * pre-unified driver state of affairs, we only consider the host
+ * device active if there is no active guest device or if there
+ * are VMX'en with active VMCI contexts using the host device.
+ */
+bool vmci_host_code_active(void)
+{
+ return vmci_host_device_initialized &&
+ (!vmci_guest_code_active() ||
+atomic_read(_host_active_users) > 0);
+}
+
+/*
+ * Called on open of /dev/vmci.
+ */
+static int vmci_host_open(struct inode *inode, struct file *filp)
+{
+ struct vmci_host_dev *vmci_host_dev;
+
+ vmci_host_dev = kzalloc(sizeof(struct vmci_host_dev), GFP_KERNEL);
+ if (vmci_host_dev == NULL)
+ return -ENOMEM;
+
+ vmci_host_dev->ct_type = VMCIOBJ_NOT_SET;
+ mutex_init(_host_dev->lock);
+ filp->private_data = vmci_host_dev;
+
+ return 0;
+}
+
+/*
+ * Called on close of /dev/vmci, most often when the process
+ * exits.
+ */
+static int vmci_host_close(struct inode *inode, struct file *filp)
+{
+ struct vmci_host_dev *vmci_host_dev = filp->private_data;
+
+ ASSERT(vmci_host_dev);
+
+ if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) {
+ ASSERT(vmci_host_dev->context);
+
+ vmci_ctx_release_ctx(vmci_host_dev->context);
+ vmci_host_dev->context = NULL;
+
+ /*
+* The number of active contexts is used to track whether any
+* VMX'en are using the host personality. It is incremented when
+* a context is created through the IOCTL_VMCI_INIT_CONTEXT
+* ioctl.
+*/
+ atomic_dec(_host_active_users);
+ }
+ vmci_host_dev->ct_type = VMCIOBJ_NOT_SET;
+
+ kfree(vmci_host_dev);
+
[PATCH 10/12] VMCI: guest side driver implementation.
VMCI guest side driver code implementation.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_guest.c | 765
1 files changed, 765 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_guest.c
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c
b/drivers/misc/vmw_vmci/vmci_guest.c
new file mode 100644
index 000..23f5e9e
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -0,0 +1,765 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+
+#define VMCI_UTIL_NUM_RESOURCES 1
+
+static bool vmci_disable_msi;
+module_param_named(disable_msi, vmci_disable_msi, bool, 0);
+MODULE_PARM_DESC(disable_msi, "Disable MSI use in driver - (default=0)");
+
+static bool vmci_disable_msix;
+module_param_named(disable_msix, vmci_disable_msix, bool, 0);
+MODULE_PARM_DESC(disable_msix, "Disable MSI-X use in driver - (default=0)");
+
+static u32 ctx_update_sub_id = VMCI_INVALID_ID;
+static u32 vm_context_id = VMCI_INVALID_ID;
+
+struct vmci_guest_device {
+ struct device *dev; /* PCI device we are attached to */
+ void __iomem *iobase;
+
+ unsigned int irq;
+ unsigned int intr_type;
+ bool exclusive_vectors;
+ struct msix_entry msix_entries[VMCI_MAX_INTRS];
+
+ struct tasklet_struct datagram_tasklet;
+ struct tasklet_struct bm_tasklet;
+
+ void *data_buffer;
+ void *notification_bitmap;
+};
+
+/* vmci_dev singleton device and supporting data*/
+static struct vmci_guest_device *vmci_dev_g;
+static DEFINE_SPINLOCK(vmci_dev_spinlock);
+
+static atomic_t vmci_num_guest_devices = ATOMIC_INIT(0);
+
+bool vmci_guest_code_active(void)
+{
+ return atomic_read(_num_guest_devices) != 0;
+}
+
+u32 vmci_get_vm_context_id(void)
+{
+ if (vm_context_id == VMCI_INVALID_ID) {
+ u32 result;
+ struct vmci_datagram get_cid_msg;
+ get_cid_msg.dst =
+ vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID,
+VMCI_GET_CONTEXT_ID);
+ get_cid_msg.src = VMCI_ANON_SRC_HANDLE;
+ get_cid_msg.payload_size = 0;
+ result = vmci_send_datagram(_cid_msg);
+ if (result >= 0)
+ vm_context_id = result;
+ }
+ return vm_context_id;
+}
+
+/*
+ * VM to hypervisor call mechanism. We use the standard VMware naming
+ * convention since shared code is calling this function as well.
+ */
+int vmci_send_datagram(struct vmci_datagram *dg)
+{
+ unsigned long flags;
+ int result;
+
+ /* Check args. */
+ if (dg == NULL)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /*
+* Need to acquire spinlock on the device because the datagram
+* data may be spread over multiple pages and the monitor may
+* interleave device user rpc calls from multiple
+* VCPUs. Acquiring the spinlock precludes that
+* possibility. Disabling interrupts to avoid incoming
+* datagrams during a "rep out" and possibly landing up in
+* this function.
+*/
+ spin_lock_irqsave(_dev_spinlock, flags);
+
+ if (vmci_dev_g) {
+ iowrite8_rep(vmci_dev_g->iobase + VMCI_DATA_OUT_ADDR,
+dg, VMCI_DG_SIZE(dg));
+ result = ioread32(vmci_dev_g->iobase + VMCI_RESULT_LOW_ADDR);
+ } else {
+ result = VMCI_ERROR_UNAVAILABLE;
+ }
+
+ spin_unlock_irqrestore(_dev_spinlock, flags);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(vmci_send_datagram);
+
+/*
+ * Gets called with the new context id if updated or resumed.
+ * Context id.
+ */
+static void vmci_guest_cid_update(u32 sub_id,
+ const struct vmci_event_data *event_data,
+ void *client_data)
+{
+ const struct vmci_event_payld_ctx *ev_payload =
+ vmci_event_data_const_payload(event_data);
+
+ if (sub_id != ctx_update_sub_id) {
+ pr_devel("Invalid subscriber (ID=0x%x).\n", sub_id);
+ return;
+ }
+
+ if (!event_data ||
[PATCH 09/12] VMCI: routing implementation.
VMCI routing code is responsible for routing between various hosts/guests
as well as routing in nested scenarios.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_route.c | 237
drivers/misc/vmw_vmci/vmci_route.h | 30 +
2 files changed, 267 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_route.c
create mode 100644 drivers/misc/vmw_vmci/vmci_route.h
diff --git a/drivers/misc/vmw_vmci/vmci_route.c
b/drivers/misc/vmw_vmci/vmci_route.c
new file mode 100644
index 000..8aa43ee
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_route.c
@@ -0,0 +1,237 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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 "vmci_common_int.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_route.h"
+
+/*
+ * Make a routing decision for the given source and destination handles.
+ * This will try to determine the route using the handles and the available
+ * devices. Will set the source context if it is invalid.
+ */
+int vmci_route(struct vmci_handle *src,
+ const struct vmci_handle *dst,
+ bool from_guest,
+ enum vmci_route *route)
+{
+ bool has_host_device = vmci_host_code_active();
+ bool has_guest_device = vmci_guest_code_active();
+
+ ASSERT(src);
+ ASSERT(dst);
+ ASSERT(route);
+
+ *route = VMCI_ROUTE_NONE;
+
+ /*
+* "from_guest" is only ever set to true by
+* IOCTL_VMCI_DATAGRAM_SEND (or by the vmkernel equivalent),
+* which comes from the VMX, so we know it is coming from a
+* guest.
+*
+* To avoid inconsistencies, test these once. We will test
+* them again when we do the actual send to ensure that we do
+* not touch a non-existent device.
+*/
+
+ /* Must have a valid destination context. */
+ if (VMCI_INVALID_ID == dst->context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /* Anywhere to hypervisor. */
+ if (VMCI_HYPERVISOR_CONTEXT_ID == dst->context) {
+
+ /*
+* If this message already came from a guest then we
+* cannot send it to the hypervisor. It must come
+* from a local client.
+*/
+ if (from_guest)
+ return VMCI_ERROR_DST_UNREACHABLE;
+
+ /*
+* We must be acting as a guest in order to send to
+* the hypervisor.
+*/
+ if (!has_guest_device)
+ return VMCI_ERROR_DEVICE_NOT_FOUND;
+
+ /* And we cannot send if the source is the host context. */
+ if (VMCI_HOST_CONTEXT_ID == src->context)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ /*
+* If the client passed the ANON source handle then
+* respect it (both context and resource are invalid).
+* However, if they passed only an invalid context,
+* then they probably mean ANY, in which case we
+* should set the real context here before passing it
+* down.
+*/
+ if (VMCI_INVALID_ID == src->context &&
+ VMCI_INVALID_ID != src->resource)
+ src->context = vmci_get_context_id();
+
+ /* Send from local client down to the hypervisor. */
+ *route = VMCI_ROUTE_AS_GUEST;
+ return VMCI_SUCCESS;
+ }
+
+ /* Anywhere to local client on host. */
+ if (VMCI_HOST_CONTEXT_ID == dst->context) {
+ /*
+* If it is not from a guest but we are acting as a
+* guest, then we need to send it down to the host.
+* Note that if we are also acting as a host then this
+* will prevent us from sending from local client to
+* local client, but we accept that restriction as a
+* way to remove any ambiguity from the host context.
+*/
+ if (src->context == VMCI_HYPERVISOR_CONTEXT_ID) {
+ /*
+* If the hypervisor is the source, this is
+* host local communication. The hypervisor
+* may send vmci event datagrams to the host
+* itself, but it will
[PATCH 08/12] VMCI: resource object implementation.
VMCI resource tracks all used resources within the vmci code.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_resource.c | 237 +
drivers/misc/vmw_vmci/vmci_resource.h | 59
2 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.c
create mode 100644 drivers/misc/vmw_vmci/vmci_resource.h
diff --git a/drivers/misc/vmw_vmci/vmci_resource.c
b/drivers/misc/vmw_vmci/vmci_resource.c
new file mode 100644
index 000..a2f5fd0
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_resource.c
@@ -0,0 +1,237 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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 "vmci_common_int.h"
+#include "vmci_resource.h"
+#include "vmci_driver.h"
+
+
+#define VMCI_RESOURCE_HASH_BITS 7
+#define VMCI_RESOURCE_HASH_BUCKETS (1 << VMCI_RESOURCE_HASH_BITS)
+
+struct vmci_hash_table {
+ spinlock_t lock;
+ struct hlist_head entries[VMCI_RESOURCE_HASH_BUCKETS];
+};
+
+static struct vmci_hash_table vmci_resource_table = {
+ .lock = __SPIN_LOCK_UNLOCKED(vmci_resource_table.lock),
+};
+
+static unsigned int vmci_resource_hash(struct vmci_handle handle)
+{
+ return hash_32(VMCI_HANDLE_TO_RESOURCE_ID(handle),
+ VMCI_RESOURCE_HASH_BITS);
+}
+
+/*
+ * Gets a resource (if one exists) matching given handle from the hash table.
+ */
+static struct vmci_resource *vmci_resource_lookup(struct vmci_handle handle)
+{
+ struct vmci_resource *r, *resource = NULL;
+ struct hlist_node *node;
+ unsigned int idx = vmci_resource_hash(handle);
+
+ BUG_ON(VMCI_HANDLE_EQUAL(handle, VMCI_INVALID_HANDLE));
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(r, node,
+_resource_table.entries[idx], node) {
+ u32 rid = VMCI_HANDLE_TO_RESOURCE_ID(r->handle);
+ u32 cid = VMCI_HANDLE_TO_CONTEXT_ID(r->handle);
+
+ if (rid == VMCI_HANDLE_TO_RESOURCE_ID(handle) &&
+ (cid == VMCI_HANDLE_TO_CONTEXT_ID(handle) ||
+cid == VMCI_INVALID_ID)) {
+ resource = r;
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return resource;
+}
+
+/*
+ * Find an unused resource ID and return it. The first
+ * VMCI_RESERVED_RESOURCE_ID_MAX are reserved so we start from
+ * its value + 1.
+ * Returns VMCI resource id on success, VMCI_INVALID_ID on failure.
+ */
+static u32 vmci_resource_find_id(u32 context_id)
+{
+ static u32 resource_id = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+ u32 old_rid = resource_id;
+ u32 current_rid;
+
+ /*
+* Generate a unique resource ID. Keep on trying until we wrap around
+* in the RID space.
+*/
+ BUG_ON(old_rid <= VMCI_RESERVED_RESOURCE_ID_MAX);
+
+ do {
+ struct vmci_handle handle;
+
+ current_rid = resource_id;
+ resource_id++;
+ if (unlikely(resource_id == VMCI_INVALID_ID)) {
+ /* Skip the reserved rids. */
+ resource_id = VMCI_RESERVED_RESOURCE_ID_MAX + 1;
+ }
+
+ handle = vmci_make_handle(context_id, current_rid);
+ if (!vmci_resource_lookup(handle))
+ return current_rid;
+ } while (resource_id != old_rid);
+
+ return VMCI_INVALID_ID;
+}
+
+
+int vmci_resource_add(struct vmci_resource *resource,
+ enum vmci_resource_type resource_type,
+ struct vmci_handle handle)
+
+{
+ unsigned int idx;
+ int result;
+
+ BUG_ON(!resource);
+
+ spin_lock(_resource_table.lock);
+
+ if (handle.resource == VMCI_INVALID_ID) {
+ handle.resource = vmci_resource_find_id(handle.context);
+ if (handle.resource == VMCI_INVALID_ID) {
+ result = VMCI_ERROR_NO_HANDLE;
+ goto out;
+ }
+ } else if (vmci_resource_lookup(handle)) {
+ result = VMCI_ERROR_ALREADY_EXISTS;
+ goto out;
+ }
+
+ resource->handle = handle;
+ resource->type = resource_type;
+ INIT_HLIST_NODE(>node);
+ kref_init(>kref);
+ init_completion(>done);
+
+ idx = vmci_resource_hash(resource->handle);
+ BUG_ON(idx >=
[PATCH 06/12] VMCI: handle array implementation.
VMCI handle code adds support for dynamic arrays that will grow if they need to.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_handle_array.c | 162 +
drivers/misc/vmw_vmci/vmci_handle_array.h | 46
2 files changed, 208 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.c
create mode 100644 drivers/misc/vmw_vmci/vmci_handle_array.h
diff --git a/drivers/misc/vmw_vmci/vmci_handle_array.c
b/drivers/misc/vmw_vmci/vmci_handle_array.c
new file mode 100644
index 000..c7db831
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_handle_array.c
@@ -0,0 +1,162 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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 "vmci_handle_array.h"
+
+static size_t handle_arr_calc_size(size_t capacity)
+{
+ return sizeof(struct vmci_handle_arr) +
+ capacity * sizeof(struct vmci_handle);
+}
+
+struct vmci_handle_arr *vmci_handle_arr_create(size_t capacity)
+{
+ struct vmci_handle_arr *array;
+
+ if (capacity == 0)
+ capacity = VMCI_HANDLE_ARRAY_DEFAULT_SIZE;
+
+ array = kmalloc(handle_arr_calc_size(capacity), GFP_ATOMIC);
+ if (!array)
+ return NULL;
+
+ array->capacity = capacity;
+ array->size = 0;
+
+ return array;
+}
+
+void vmci_handle_arr_destroy(struct vmci_handle_arr *array)
+{
+ kfree(array);
+}
+
+void vmci_handle_arr_append_entry(struct vmci_handle_arr **array_ptr,
+ struct vmci_handle handle)
+{
+ struct vmci_handle_arr *array;
+
+ BUG_ON(!array_ptr || !*array_ptr);
+ array = *array_ptr;
+
+ if (unlikely(array->size >= array->capacity)) {
+ /* reallocate. */
+ struct vmci_handle_arr *new_array;
+ size_t new_capacity = array->capacity * VMCI_ARR_CAP_MULT;
+ size_t new_size = handle_arr_calc_size(new_capacity);
+
+ new_array = krealloc(array, new_size, GFP_ATOMIC);
+ if (!new_array)
+ return;
+
+ new_array->capacity = new_capacity;
+ *array_ptr = array = new_array;
+ }
+
+ array->entries[array->size] = handle;
+ array->size++;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if entry not found.
+ */
+struct vmci_handle vmci_handle_arr_remove_entry(struct vmci_handle_arr *array,
+ struct vmci_handle entry_handle)
+{
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+ size_t i;
+
+ BUG_ON(!array);
+
+ for (i = 0; i < array->size; i++) {
+ if (VMCI_HANDLE_EQUAL(array->entries[i], entry_handle)) {
+ handle = array->entries[i];
+ array->size--;
+ array->entries[i] = array->entries[array->size];
+ array->entries[array->size] = VMCI_INVALID_HANDLE;
+ break;
+ }
+ }
+
+ return handle;
+}
+
+/*
+ * Handle that was removed, VMCI_INVALID_HANDLE if array was empty.
+ */
+struct vmci_handle vmci_handle_arr_remove_tail(struct vmci_handle_arr *array)
+{
+ struct vmci_handle handle = VMCI_INVALID_HANDLE;
+
+ BUG_ON(!array);
+
+ if (array->size) {
+ array->size--;
+ handle = array->entries[array->size];
+ array->entries[array->size] = VMCI_INVALID_HANDLE;
+ }
+
+ return handle;
+}
+
+/*
+ * Handle at given index, VMCI_INVALID_HANDLE if invalid index.
+ */
+struct vmci_handle
+vmci_handle_arr_get_entry(const struct vmci_handle_arr *array, size_t index)
+{
+ BUG_ON(!array);
+
+ if (unlikely(index >= array->size))
+ return VMCI_INVALID_HANDLE;
+
+ return array->entries[index];
+}
+
+size_t vmci_handle_arr_get_size(const struct vmci_handle_arr *array)
+{
+ BUG_ON(!array);
+
+ return array->size;
+}
+
+bool vmci_handle_arr_has_entry(const struct vmci_handle_arr *array,
+ struct vmci_handle entry_handle)
+{
+ size_t i;
+
+ BUG_ON(!array);
+
+ for (i = 0; i < array->size; i++)
+ if (VMCI_HANDLE_EQUAL(array->entries[i], entry_handle))
+ return true;
+
+ return false;
+}
+
+/*
+ * NULL if the array is empty. Otherwise, a pointer to the array
+ * of VMCI handles in the handle array.
+ */
+struct vmci_handle
[PATCH 05/12] VMCI: event handling implementation.
VMCI event code that manages event handlers and handles callbacks when specific
events fire.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_event.c | 371
drivers/misc/vmw_vmci/vmci_event.h | 25 ++
2 files changed, 396 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_event.c
create mode 100644 drivers/misc/vmw_vmci/vmci_event.h
diff --git a/drivers/misc/vmw_vmci/vmci_event.c
b/drivers/misc/vmw_vmci/vmci_event.c
new file mode 100644
index 000..a058b6f
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_event.c
@@ -0,0 +1,371 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+#include
+#include
+
+#include "vmci_driver.h"
+#include "vmci_event.h"
+
+#define EVENT_MAGIC 0xEABE
+#define VMCI_EVENT_MAX_ATTEMPTS 10
+
+struct vmci_subscription {
+ u32 id;
+ u32 event;
+ struct kref kref;
+ struct completion done; /* unregistered, ready to be freed */
+ vmci_event_cb callback;
+ void *callback_data;
+ struct list_head node; /* on one of subscriber lists */
+ bool run_delayed;
+};
+
+static struct list_head subscriber_array[VMCI_EVENT_MAX];
+static DEFINE_MUTEX(subscriber_mutex);
+
+struct delayed_event_info {
+ struct work_struct work;
+ struct vmci_subscription *sub;
+ u8 event_payload[sizeof(struct vmci_event_data_max)];
+};
+
+int __init vmci_event_init(void)
+{
+ int i;
+
+ for (i = 0; i < VMCI_EVENT_MAX; i++)
+ INIT_LIST_HEAD(_array[i]);
+
+ return VMCI_SUCCESS;
+}
+
+void vmci_event_exit(void)
+{
+ int e;
+
+ /* We free all memory at exit. */
+ for (e = 0; e < VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur, *p2;
+ list_for_each_entry_safe(cur, p2, _array[e], node) {
+
+ /*
+* We should never get here because all events
+* should have been unregistered before we try
+* to unload the driver module. Also, delayed
+* callbacks could still be firing so this
+* cleanup would not be safe. Still it is
+* better to free the memory than not ... so
+* we leave this code in just in case
+*/
+ pr_warn("Unexpected free events occuring.\n");
+ kfree(cur);
+ }
+ }
+
+}
+
+/*
+ * Gets a reference to the given VMCISubscription.
+ */
+static struct vmci_subscription *event_get(struct vmci_subscription *entry)
+{
+ kref_get(>kref);
+
+ return entry;
+}
+
+static void event_signal_destroy(struct kref *kref)
+{
+ struct vmci_subscription *entry =
+ container_of(kref, struct vmci_subscription, kref);
+
+ complete(>done);
+}
+
+/*
+ * Releases the given VMCISubscription.
+ * Fires the destroy event if the reference count has gone to zero.
+ */
+static void event_release(struct vmci_subscription *entry)
+{
+ kref_put(>kref, event_signal_destroy);
+}
+
+/*
+ * Find entry. Assumes lock is held.
+ */
+static struct vmci_subscription *event_find(u32 sub_id)
+{
+ int e;
+
+ for (e = 0; e < VMCI_EVENT_MAX; e++) {
+ struct vmci_subscription *cur;
+ list_for_each_entry(cur, _array[e], node) {
+ if (cur->id == sub_id)
+ return cur;
+ }
+ }
+ return NULL;
+}
+
+/*
+ * Calls the specified callback in a delayed context.
+ */
+static void event_delayed_dispatch(struct work_struct *work)
+{
+ struct delayed_event_info *event_info =
+ container_of(work, struct delayed_event_info, work);
+ struct vmci_subscription *sub = event_info->sub;
+ struct vmci_event_data *ed;
+
+ BUG_ON(!sub);
+
+ ed = (struct vmci_event_data *)event_info->event_payload;
+
+ sub->callback(sub->id, ed, sub->callback_data);
+ event_release(sub);
+
+ kfree(event_info);
+}
+
+static void event_schedule_delayed(const struct vmci_event_msg *event_msg,
+ struct vmci_subscription *s)
+{
+ struct delayed_event_info *event_info;
+
+ event_info = kzalloc(sizeof(*event_info), GFP_ATOMIC);
+ if (!event_info)
[PATCH 04/12] VMCI: device driver implementaton.
VMCI driver code implementes both the host and guest personalities of the VMCI
driver.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_driver.c | 159 +++
drivers/misc/vmw_vmci/vmci_driver.h | 50 +++
2 files changed, 209 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_driver.c
create mode 100644 drivers/misc/vmw_vmci/vmci_driver.h
diff --git a/drivers/misc/vmw_vmci/vmci_driver.c
b/drivers/misc/vmw_vmci/vmci_driver.c
new file mode 100644
index 000..1ca0c7e
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_driver.c
@@ -0,0 +1,159 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+
+#include "vmci_driver.h"
+#include "vmci_event.h"
+
+static bool vmci_disable_host;
+module_param_named(disable_host, vmci_disable_host, bool, 0);
+MODULE_PARM_DESC(disable_host,
+"Disable driver host personality (default=enabled)");
+
+static bool vmci_disable_guest;
+module_param_named(disable_guest, vmci_disable_guest, bool, 0);
+MODULE_PARM_DESC(disable_guest,
+"Disable driver guest personality (default=enabled)");
+
+static bool vmci_guest_personality_initialized;
+static bool vmci_host_personality_initialized;
+
+/*
+ * vmci_get_context_id() - Gets the current context ID.
+ *
+ * Returns the current context ID. Note that since this is accessed only
+ * from code running in the host, this always returns the host context ID.
+ */
+u32 vmci_get_context_id(void)
+{
+ if (vmci_guest_code_active()) {
+ return vmci_get_vm_context_id();
+ } else if (vmci_host_code_active()) {
+ return VMCI_HOST_CONTEXT_ID;
+ } else {
+ return VMCI_INVALID_ID;
+ }
+}
+EXPORT_SYMBOL_GPL(vmci_get_context_id);
+
+/*
+ * vmci_version() - Returns the version of the driver.
+ *
+ * Returns the version of the VMCI driver.
+ */
+u32 vmci_version(void)
+{
+ return VMCI_VERSION;
+}
+EXPORT_SYMBOL_GPL(vmci_version);
+
+static int __init vmci_core_init(void)
+{
+ int result;
+
+ result = vmci_ctx_init();
+ if (result < VMCI_SUCCESS) {
+ pr_err("Failed to initialize VMCIContext (result=%d).\n",
+ result);
+ return -EINVAL;
+ }
+
+ result = vmci_datagram_init();
+ if (result < VMCI_SUCCESS) {
+ pr_err("Failed to initialize VMCIDatagram (result=%d).\n",
+ result);
+ return -EINVAL;
+ }
+
+ result = vmci_event_init();
+ if (result < VMCI_SUCCESS) {
+ pr_err("Failed to initialize VMCIEvent (result=%d).\n", result);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void __exit vmci_core_exit(void)
+{
+ vmci_event_exit();
+}
+
+static int __init vmci_drv_init(void)
+{
+ int error;
+
+ error = vmci_core_init();
+ if (error)
+ return error;
+
+ if (!vmci_disable_guest) {
+ error = vmci_guest_init();
+ if (error) {
+ pr_warn("Failed to initialize guest personality
(err=%d).\n",
+ error);
+ } else {
+ vmci_guest_personality_initialized = true;
+ pr_info("Guest personality initialized and is %s\n",
+ vmci_guest_code_active() ?
+ "active" : "inactive");
+ }
+ }
+
+ if (!vmci_disable_host) {
+ error = vmci_host_init();
+ if (error) {
+ pr_warn("Unable to initialize host personality
(err=%d).\n",
+ error);
+ } else {
+ vmci_host_personality_initialized = true;
+ pr_info("Initialized host personality\n");
+ }
+ }
+
+ if (!vmci_guest_personality_initialized &&
+ !vmci_host_personality_initialized) {
+ vmci_core_exit();
+ return -ENODEV;
+ }
+
+ pr_debug("Module is initialized\n");
+ return 0;
+}
+module_init(vmci_drv_init);
+
+static void __exit vmci_drv_exit(void)
+{
+ if (vmci_guest_personality_initialized)
+ vmci_guest_exit();
+
+ if (vmci_host_personality_initialized)
+ vmci_host_exit();
+
+
[PATCH 03/12] VMCI: doorbell implementation.
VMCI doorbell code allows for notifcations between host and guest.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_doorbell.c | 673 +
drivers/misc/vmw_vmci/vmci_doorbell.h | 53 +++
2 files changed, 726 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.c
create mode 100644 drivers/misc/vmw_vmci/vmci_doorbell.h
diff --git a/drivers/misc/vmw_vmci/vmci_doorbell.c
b/drivers/misc/vmw_vmci/vmci_doorbell.c
new file mode 100644
index 000..ebe4180
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_doorbell.c
@@ -0,0 +1,673 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+#include
+#include
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_resource.h"
+#include "vmci_driver.h"
+#include "vmci_route.h"
+
+
+#define VMCI_DOORBELL_INDEX_BITS 6
+#define VMCI_DOORBELL_INDEX_TABLE_SIZE (1 << VMCI_DOORBELL_INDEX_BITS)
+#define VMCI_DOORBELL_HASH(_idx) hash_32(_idx, VMCI_DOORBELL_INDEX_BITS)
+
+/*
+ * DoorbellEntry describes the a doorbell notification handle allocated by the
+ * host.
+ */
+struct dbell_entry {
+ struct vmci_resource resource;
+ struct hlist_node node;
+ struct work_struct work;
+ vmci_callback notify_cb;
+ void *client_data;
+ u32 idx;
+ u32 priv_flags;
+ bool run_delayed;
+ atomic_t active;/* Only used by guest personality */
+};
+
+/* The VMCI index table keeps track of currently registered doorbells. */
+struct dbell_index_table {
+ spinlock_t lock;/* Index table lock */
+ struct hlist_head entries[VMCI_DOORBELL_INDEX_TABLE_SIZE];
+};
+
+static struct dbell_index_table vmci_doorbell_it = {
+ .lock = __SPIN_LOCK_UNLOCKED(vmci_doorbell_it.lock),
+};
+
+/*
+ * The max_notify_idx is one larger than the currently known bitmap index in
+ * use, and is used to determine how much of the bitmap needs to be scanned.
+ */
+static u32 max_notify_idx;
+
+/*
+ * The notify_idx_count is used for determining whether there are free entries
+ * within the bitmap (if notify_idx_count + 1 < max_notify_idx).
+ */
+static u32 notify_idx_count;
+
+/*
+ * The last_notify_idx_reserved is used to track the last index handed out - in
+ * the case where multiple handles share a notification index, we hand out
+ * indexes round robin based on last_notify_idx_reserved.
+ */
+static u32 last_notify_idx_reserved;
+
+/* This is a one entry cache used to by the index allocation. */
+static u32 last_notify_idx_released = PAGE_SIZE;
+
+
+/*
+ * Utility function that retrieves the privilege flags associated
+ * with a given doorbell handle. For guest endpoints, the
+ * privileges are determined by the context ID, but for host
+ * endpoints privileges are associated with the complete
+ * handle. Hypervisor endpoints are not yet supported.
+ */
+int vmci_dbell_get_priv_flags(struct vmci_handle handle, u32 *priv_flags)
+{
+ if (priv_flags == NULL || handle.context == VMCI_INVALID_ID)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if (handle.context == VMCI_HOST_CONTEXT_ID) {
+ struct dbell_entry *entry;
+ struct vmci_resource *resource;
+
+ resource = vmci_resource_by_handle(handle,
+ VMCI_RESOURCE_TYPE_DOORBELL);
+ if (!resource)
+ return VMCI_ERROR_NOT_FOUND;
+
+ entry = container_of(resource, struct dbell_entry, resource);
+ *priv_flags = entry->priv_flags;
+ vmci_resource_put(resource);
+ } else if (handle.context == VMCI_HYPERVISOR_CONTEXT_ID) {
+ /*
+* Hypervisor endpoints for notifications are not
+* supported (yet).
+*/
+ return VMCI_ERROR_INVALID_ARGS;
+ } else {
+ *priv_flags = vmci_context_get_priv_flags(handle.context);
+ }
+
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Find doorbell entry by bitmap index.
+ */
+static struct dbell_entry *dbell_index_table_find(u32 idx)
+{
+ u32 bucket = VMCI_DOORBELL_HASH(idx);
+ struct dbell_entry *dbell;
+ struct hlist_node *node;
+
+ BUG_ON(!vmci_guest_code_active());
+
+ hlist_for_each_entry(dbell, node, _doorbell_it.entries[bucket],
+
[PATCH 02/12] VMCI: datagram implementation.
VMCI datagram Implements datagrams to allow data to be sent between host and
guest.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_datagram.c | 520 +
drivers/misc/vmw_vmci/vmci_datagram.h | 55 +++
2 files changed, 575 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.c
create mode 100644 drivers/misc/vmw_vmci/vmci_datagram.h
diff --git a/drivers/misc/vmw_vmci/vmci_datagram.c
b/drivers/misc/vmw_vmci/vmci_datagram.c
new file mode 100644
index 000..55bf882
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_datagram.c
@@ -0,0 +1,520 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+
+#include "vmci_common_int.h"
+#include "vmci_datagram.h"
+#include "vmci_resource.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+#include "vmci_route.h"
+
+/*
+ * struct datagram_entry describes the datagram entity. It is used for datagram
+ * entities created only on the host.
+ */
+struct datagram_entry {
+ struct vmci_resource resource;
+ u32 flags;
+ bool run_delayed;
+ vmci_datagram_recv_cb recv_cb;
+ void *client_data;
+ u32 priv_flags;
+};
+
+struct delayed_datagram_info {
+ struct datagram_entry *entry;
+ struct vmci_datagram msg;
+ struct work_struct work;
+ bool in_dg_host_queue;
+};
+
+static atomic_t delayed_dg_host_queue_size;
+
+
+/*
+ * Create a datagram entry given a handle pointer.
+ */
+static int dg_create_handle(u32 resource_id,
+ u32 flags,
+ u32 priv_flags,
+ vmci_datagram_recv_cb recv_cb,
+ void *client_data, struct vmci_handle *out_handle)
+{
+ int result;
+ u32 context_id;
+ struct vmci_handle handle;
+ struct datagram_entry *entry;
+
+ ASSERT(recv_cb != NULL);
+ ASSERT(out_handle != NULL);
+ ASSERT(!(priv_flags & ~VMCI_PRIVILEGE_ALL_FLAGS));
+
+ if ((flags & VMCI_FLAG_WELLKNOWN_DG_HND) != 0)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ if ((flags & VMCI_FLAG_ANYCID_DG_HND) != 0) {
+ context_id = VMCI_INVALID_ID;
+ } else {
+ context_id = vmci_get_context_id();
+ if (context_id == VMCI_INVALID_ID)
+ return VMCI_ERROR_NO_RESOURCES;
+ }
+
+ handle = vmci_make_handle(context_id, resource_id);
+
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ pr_warn("Failed allocating memory for datagram entry.\n");
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ entry->run_delayed = (flags & VMCI_FLAG_DG_DELAYED_CB) ? true : false;
+ entry->flags = flags;
+ entry->recv_cb = recv_cb;
+ entry->client_data = client_data;
+ entry->priv_flags = priv_flags;
+
+ /* Make datagram resource live. */
+ result = vmci_resource_add(>resource,
+ VMCI_RESOURCE_TYPE_DATAGRAM,
+ handle);
+ if (result != VMCI_SUCCESS) {
+ pr_warn("Failed to add new resource (handle=0x%x:0x%x), error:
%d\n",
+ handle.context, handle.resource, result);
+ kfree(entry);
+ return result;
+ }
+
+ *out_handle = vmci_resource_handle(>resource);
+ return VMCI_SUCCESS;
+}
+
+int __init vmci_datagram_init(void)
+{
+ atomic_set(_dg_host_queue_size, 0);
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Internal utilility function with the same purpose as
+ * vmci_datagram_get_priv_flags that also takes a context_id.
+ */
+static int vmci_datagram_get_priv_flags(u32 context_id,
+ struct vmci_handle handle,
+ u32 *priv_flags)
+{
+ ASSERT(priv_flags);
+ ASSERT(context_id != VMCI_INVALID_ID);
+
+ if (context_id == VMCI_HOST_CONTEXT_ID) {
+ struct datagram_entry *src_entry;
+ struct vmci_resource *resource;
+
+ resource = vmci_resource_by_handle(handle,
+ VMCI_RESOURCE_TYPE_DATAGRAM);
+ if (!resource)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ src_entry = container_of(resource, struct datagram_entry,
+
[PATCH 01/12] VMCI: context implementation.
VMCI Context code maintains state for vmci and allows the driver to communicate
with multiple VMs.
Signed-off-by: George Zhang
---
drivers/misc/vmw_vmci/vmci_context.c | 1290 ++
drivers/misc/vmw_vmci/vmci_context.h | 177 +
2 files changed, 1467 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/vmw_vmci/vmci_context.c
create mode 100644 drivers/misc/vmw_vmci/vmci_context.h
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
new file mode 100644
index 000..d4680dd
--- /dev/null
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -0,0 +1,1290 @@
+/*
+ * VMware VMCI Driver
+ *
+ * Copyright (C) 2012 VMware, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation version 2 and no later version.
+ *
+ * This program is distributed in the hope that 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
+#include
+
+#include "vmci_common_int.h"
+#include "vmci_queue_pair.h"
+#include "vmci_datagram.h"
+#include "vmci_doorbell.h"
+#include "vmci_context.h"
+#include "vmci_driver.h"
+#include "vmci_event.h"
+
+/*
+ * List of current VMCI contexts.
+ */
+static struct {
+ struct list_head head;
+ spinlock_t lock; /* Spinlock for context list operations */
+} ctx_list;
+
+/* Used by contexts that did not set up notify flag pointers */
+static bool ctx_dummy_notify;
+
+static void ctx_signal_notify(struct vmci_ctx *context)
+{
+ *context->notify = true;
+}
+
+static void ctx_clear_notify(struct vmci_ctx *context)
+{
+ *context->notify = false;
+}
+
+/*
+ * If nothing requires the attention of the guest, clears both
+ * notify flag and call.
+ */
+static void ctx_clear_notify_call(struct vmci_ctx *context)
+{
+ if (context->pending_datagrams == 0 &&
+ vmci_handle_arr_get_size(context->pending_doorbell_array) == 0)
+ ctx_clear_notify(context);
+}
+
+/*
+ * Sets the context's notify flag iff datagrams are pending for this
+ * context. Called from vmci_setup_notify().
+ */
+void vmci_ctx_check_signal_notify(struct vmci_ctx *context)
+{
+ ASSERT(context);
+
+ spin_lock(>lock);
+ if (context->pending_datagrams)
+ ctx_signal_notify(context);
+ spin_unlock(>lock);
+}
+
+int __init vmci_ctx_init(void)
+{
+ INIT_LIST_HEAD(_list.head);
+ spin_lock_init(_list.lock);
+
+ return VMCI_SUCCESS;
+}
+
+/*
+ * Allocates and initializes a VMCI context.
+ */
+int vmci_ctx_init_ctx(u32 cid,
+ u32 priv_flags,
+ uintptr_t event_hnd,
+ int user_version,
+ const struct cred *cred,
+ struct vmci_ctx **out_context)
+{
+ struct vmci_ctx *context;
+ int result;
+
+ if (priv_flags & ~VMCI_PRIVILEGE_ALL_FLAGS) {
+ pr_devel("Invalid flag (flags=0x%x) for VMCI context.\n",
+priv_flags);
+ return VMCI_ERROR_INVALID_ARGS;
+ }
+
+ if (user_version == 0)
+ return VMCI_ERROR_INVALID_ARGS;
+
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
+ if (context == NULL) {
+ pr_warn("Failed to allocate memory for VMCI context.\n");
+ return VMCI_ERROR_NO_MEM;
+ }
+
+ INIT_LIST_HEAD(>list_item);
+ INIT_LIST_HEAD(>datagram_queue);
+
+ context->user_version = user_version;
+
+ context->queue_pair_array = vmci_handle_arr_create(0);
+ if (!context->queue_pair_array) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ context->doorbell_array = vmci_handle_arr_create(0);
+ if (!context->doorbell_array) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ context->pending_doorbell_array = vmci_handle_arr_create(0);
+ if (!context->pending_doorbell_array) {
+ result = VMCI_ERROR_NO_MEM;
+ goto error;
+ }
+
+ INIT_LIST_HEAD(>notifier_list);
+
+ spin_lock_init(>lock);
+
+ kref_init(>kref);
+
+ /* Inititialize host-specific VMCI context. */
+ init_waitqueue_head(>host_context.wait_queue);
+
+ context->priv_flags = priv_flags;
+
+ if (cred)
+ context->cred = get_cred(cred);
+
+ context->notify = _dummy_notify;
+ context->notify_page = NULL;
+
+ /*
+* If we collide with an existing context we generate a new
+* and use it instead. The VMX will determine if regeneration
+* is okay. Since there isn't 4B - 16 VMs running on
[PATCH 00/12] VMCI for Linux upstreaming
* * * This series of VMCI linux upstreaming patches include latest udpate from VMware. -split guest, host and core driver code into different files -use EXPORT_SYMBOLS_GPL -remove vmci_device_get and vmci_device_release APIs -simplify the event deliver mechanism -driver ioctl code cleanup -sparse clean * * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post. * * * VMCI allows virtual machines to communicate with host kernel modules and the VMware hypervisors. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets, a socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines. In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as HGFS and VMCI Sockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself. Outside the virtual machine, the host side support of the VMCI kernel module makes the same VMCI kernel API available to VMCI endpoints on the host. In addition to this, the host side manages each VMCI device in a virtual machine through a context object. This context object serves to identify the virtual machine for communication, and to track the resource consumption of the given VMCI device. Both operations related to communication between the virtual machine and the host kernel, and those related to the management of the VMCI device state in the host kernel, are invoked by the user level component of the hypervisor through a set of ioctls on the VMCI device node. To provide seamless support for nested virtualization, where a virtual machine may use both a VMCI PCI device to talk to its hypervisor, and the VMCI host side support to run nested virtual machines, the VMCI host and virtual machine support are combined in a single kernel module. For additional information about the use of VMCI and in particular VMCI Sockets, please refer to the VMCI Socket Programming Guide available at https://www.vmware.com/support/developer/vmci-sdk/. --- George Zhang (12): VMCI: context implementation. VMCI: datagram implementation. VMCI: doorbell implementation. VMCI: device driver implementaton. VMCI: event handling implementation. VMCI: handle array implementation. VMCI: queue pairs implementation. VMCI: resource object implementation. VMCI: routing implementation. VMCI: guest side driver implementation. VMCI: host side driver implementation. VMCI: Some header and config files. drivers/misc/Kconfig |1 drivers/misc/Makefile |2 drivers/misc/vmw_vmci/Kconfig | 16 drivers/misc/vmw_vmci/Makefile| 43 drivers/misc/vmw_vmci/vmci_common_int.h | 34 drivers/misc/vmw_vmci/vmci_context.c | 1290 +++ drivers/misc/vmw_vmci/vmci_context.h | 177 + drivers/misc/vmw_vmci/vmci_datagram.c | 520 drivers/misc/vmw_vmci/vmci_datagram.h | 55 drivers/misc/vmw_vmci/vmci_doorbell.c | 673 + drivers/misc/vmw_vmci/vmci_doorbell.h | 53 drivers/misc/vmw_vmci/vmci_driver.c | 159 + drivers/misc/vmw_vmci/vmci_driver.h | 50 drivers/misc/vmw_vmci/vmci_event.c| 371 +++ drivers/misc/vmw_vmci/vmci_event.h| 25 drivers/misc/vmw_vmci/vmci_guest.c| 765 ++ drivers/misc/vmw_vmci/vmci_handle_array.c | 162 + drivers/misc/vmw_vmci/vmci_handle_array.h | 46 drivers/misc/vmw_vmci/vmci_host.c | 1046 + drivers/misc/vmw_vmci/vmci_queue_pair.c | 3556 + drivers/misc/vmw_vmci/vmci_queue_pair.h | 191 ++ drivers/misc/vmw_vmci/vmci_resource.c | 237 ++
Re: drm i915 hangs on heavy io load
Hi Dave,
On Di, 30 Okt 2012, Dave Airlie wrote:
> > Thanks, running now with SNA. Let us see what happens.
>
> Please don't, we ain't going to find the bug any quicker changing
> variables, if the only thing that changed on your system was the
Sorry, didn't know. I supposed from the email of Chris that I should try
it "to stress different code path" ... anyway, disabling it again.
> How long does it take you to reproduce, and does it happen when in
Very hard to say, most of the times it is in a few days scale.
Though it happened also after a few hours once.
> actual use. On my laptop I've noticed I come back to it sometimes and
Concerning actual use: I had instances on several occassions. Just 30min
ago it was while working with shotwell on my photo collection, tagging
photos. So there should not be a big disk activity or so, but a lot
of screen redraws etc when going through the photos.
On other times it was locked screen without screen saver.
Concerning coming back: For me it never worked. I always have to reboot
to get a working state again. Ok, to be more specific. GNome3 is dead.
I can close the windows normally with kbd shortcuts and some mouse
interaction, but no new windows, no moving etc.
> gnome-shell is dead. This never happened pre 3.7-rc's. But for me its
> a 3-4 day window so far for it to die, which makes bisecting it a bit
That sounds pretty much like my case, but since I often don't use
the laptop for 2 days or so, it might be a bit longer.
> of a major problem. and I'm just finished bisecting the last Ironlake
> regression that took over a month.
Ouch ...
> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> final to 3.7-rc1 or maybe -rc2.
Ok, thanks. I will try.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
QUALL (vb.)
To speak with the voice of one who requires another to do something
for them.
--- Douglas Adams, The Meaning of Liff
--
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: drm i915 hangs on heavy io load
On Tue, Oct 30, 2012 at 10:49 AM, Norbert Preining wrote: > On Mo, 29 Okt 2012, Tino Keitel wrote: >> Section "Device" >> Option "AccelMethod" "SNA" >> Identifier "Card0" >> Driver "intel" >> EndSection > > Thanks, running now with SNA. Let us see what happens. Please don't, we ain't going to find the bug any quicker changing variables, if the only thing that changed on your system was the kernel then we need to figure out which kernel changes caused it and remove them. Changing userspace is only complicating things and making it less likely we'll ever find the regressions. Once we find the regression, changing userspace optiosn to help understand it is more reasonable. How long does it take you to reproduce, and does it happen when in actual use. On my laptop I've noticed I come back to it sometimes and gnome-shell is dead. This never happened pre 3.7-rc's. But for me its a 3-4 day window so far for it to die, which makes bisecting it a bit of a major problem. and I'm just finished bisecting the last Ironlake regression that took over a month. I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 final to 3.7-rc1 or maybe -rc2. Dave. -- 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] hwmon: da9055: Fix chan_mux[DA9055_ADC_ADCIN3] setting
On Mon, Oct 29, 2012 at 04:34:38PM +0800, Axel Lin wrote:
> Set chan_mux[DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3.
>
> Signed-off-by: Axel Lin
> ---
> Hi,
> This looks like a typo, but I don't have a hardware to test it.
> Axel
> drivers/hwmon/da9055-hwmon.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/da9055-hwmon.c b/drivers/hwmon/da9055-hwmon.c
> index 0b41f2c..3a3377c 100644
> --- a/drivers/hwmon/da9055-hwmon.c
> +++ b/drivers/hwmon/da9055-hwmon.c
> @@ -54,7 +54,7 @@ static const u8 chan_mux[DA9055_ADC_TJUNC + 1] = {
> [DA9055_ADC_VSYS] = DA9055_ADC_MUX_VSYS,
> [DA9055_ADC_ADCIN1] = DA9055_ADC_MUX_ADCIN1,
> [DA9055_ADC_ADCIN2] = DA9055_ADC_MUX_ADCIN2,
> - [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN1,
> + [DA9055_ADC_ADCIN3] = DA9055_ADC_MUX_ADCIN3,
> [DA9055_ADC_TJUNC] = DA9055_ADC_MUX_T_SENSE,
> };
Very much loks like a typo.
David, Ashish, any comments ? I would like to get your Ack before applying it.
Thanks,
Guenter
--
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/4] arch/arm: support seccomp
This adds support for seccomp BPF to ARM. When built with the seccomp
improvement patch waiting in linux-next ("seccomp: Make syscall skipping
and nr changes more consistent"), this passes the seccomp regression
test suite: https://github.com/redpig/seccomp
Thanks,
-Kees
--
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: drm i915 hangs on heavy io load
On Mo, 29 Okt 2012, Tino Keitel wrote:
> Section "Device"
> Option "AccelMethod" "SNA"
> Identifier "Card0"
> Driver "intel"
> EndSection
Thanks, running now with SNA. Let us see what happens.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
RECULVER (n.)
The sort of remark only ever made during Any Questions.
--- Douglas Adams, The Meaning of Liff
--
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/4] hwmon, fam15h_power: Change email address, MAINTAINERS entry
On Mon, Oct 29, 2012 at 06:50:47PM +0100, Andreas Herrmann wrote: > > Signed-off-by: Andreas Herrmann Applied. Thanks, Guenter -- 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: [PULL REQ] IXP4xx changes for Linux 3.7
On 18/10/12 09:01, Krzysztof Halasa wrote: > Hi, > > > Unfortunately, as I already explained to you in > https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very > limited (and this isn't a paid job) and I'm in no way able to do what > you require. This, coupled with my inability to make the patches end up > upstream any other way, will make me post relevant MAINTAINERS changes > shortly. > > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > this point. Given the raised barriers to participate, probably aimed at > paid maintainers, I have to quit doing this. > > BTW since Imre has probably even much less time, it would be a good time > to find someone to maintain IXP4xx code. I will be publishing (from time > to time) my tree (I'm using the hw myself), so even simple > cherry-picking would probably make some sense. I maintain a tree for the ep93xx, which is another legacy arm soc. I also do this as a hobbyist, not as a paid position. Pushing patches to mainline via arm-soc has been very easy. Basically I branch from Linus's tree (typically 3.x-rc1), apply patches to one of a bunch of branches (-devel, -fixes, etc) and then send pull requests to the arm-soc maintainers prior to the merge window. I also have a aggregate branch which is tested in next. It takes very little of my time to maintain this tree. I cannot see how it could be any harder than sending to Linus directly. Also, the arm-soc maintainers, Arnd and Olof, have been very helpful in getting me started with my maintainer tree, and in learning the development flow. I would also rather get flamed by the arm-soc guys than Linus when I make a mistake :-). ~Ryan -- 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/4] arch/arm: add syscall_get_arch
From: Will Drewry
Provide an ARM implementation of syscall_get_arch. This is a pre-requisite
for CONFIG_HAVE_ARCH_SECCOMP_FILTER.
Signed-off-by: Will Drewry
Signed-off-by: Kees Cook
---
arch/arm/include/asm/syscall.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
index 9fdded6..803f433 100644
--- a/arch/arm/include/asm/syscall.h
+++ b/arch/arm/include/asm/syscall.h
@@ -7,6 +7,8 @@
#ifndef _ASM_ARM_SYSCALL_H
#define _ASM_ARM_SYSCALL_H
+#include /* for AUDIT_ARCH_* */
+#include /* for ELF_EM */
#include
#include
@@ -95,4 +97,15 @@ static inline void syscall_set_arguments(struct task_struct
*task,
memcpy(>ARM_r0 + i, args, n * sizeof(args[0]));
}
+static inline int syscall_get_arch(struct task_struct *task,
+ struct pt_regs *regs)
+{
+ /* ARM tasks don't change audit architectures on the fly. */
+#ifdef __ARMEB__
+ return AUDIT_ARCH_ARMEB;
+#else
+ return AUDIT_ARCH_ARM;
+#endif
+}
+
#endif /* _ASM_ARM_SYSCALL_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/
[PATCH 4/4] arch/arm: select HAVE_ARCH_SECCOMP_FILTER
From: Will Drewry Reflect architectural support for seccomp filter. Signed-off-by: Will Drewry Signed-off-by: Kees Cook --- arch/arm/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ade7e92..0e8d490 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -21,6 +21,7 @@ config ARM select HAVE_AOUT select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL select HAVE_ARCH_KGDB + select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT select HAVE_C_RECORDMCOUNT -- 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 3/4] arch/arm: allow a scno of -1 to not cause a SIGILL
From: Will Drewry On tracehook-friendly platforms, a system call number of -1 falls through without running much code or taking much action. ARM is different. This adds a lightweight check to arm_syscall() to make sure that ARM behaves the same way. Signed-off-by: Will Drewry Signed-off-by: Kees Cook --- arch/arm/kernel/traps.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c index b0179b8..f303ea6 100644 --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -540,6 +540,10 @@ asmlinkage int arm_syscall(int no, struct pt_regs *regs) struct thread_info *thread = current_thread_info(); siginfo_t info; + /* Emulate/fallthrough. */ + if (no == -1) + return regs->ARM_r0; + if ((no >> 16) != (__ARM_NR_BASE>> 16)) return bad_syscall(no, regs); -- 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/
[REGRESSION] i915: failure to interoperate with HP ZR30w using an X230
I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able to work with an HP ZR30w 30" 2560x1600 display. I saw the following messages in the dmesg: [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! .. which I didn't see before; the exact same mini-displayport to displayport cable connecting the same Lenovo X230 laptop to exactly the same ZRW 30 display worked just fine with the 3.6.0 kernel. So I bisected the problem, and found the following commit. Reverting this commit made the problem go away. Maybe we should revert 0c96c65b48fb in mainline? Let me know if you'd like me to do any further debugging. Thanks, - Ted commit 6c34ed3be47036c173f7f43df112f93fbd89026f Author: Jani Nikula Date: Wed Sep 26 18:43:10 2012 +0300 drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream. The dithering introduced in commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson Date: Tue Dec 13 15:41:00 2011 -0800 drm/i915/dp: Dither down to 6bpc if it makes the mode fit stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter Date: Fri Aug 10 11:10:20 2012 +0200 Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect. v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson Signed-off-by: Jani Nikula Reviewed-by: Adam Jackson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman - Ted -- 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: drm i915 hangs on heavy io load
Hi Chris,
On So, 28 Okt 2012, Chris Wilson wrote:
> > I pulled the whole branch into my compile branch, and removed everything
> > from kernel cmd line regarding rc6, and got the
> > [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > [drm] capturing error event; look for more information in
> > /debug/dri/0/i915_error_state
> > [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
> > [drm:i915_reset] *ERROR* Failed to reset chip.
> > new i915_error_state.gz at the same place.
> >
> > So it seems that the patches in the ilk-wa-pile branch do not help.
>
> Yeah, looks like we have another issue to contend with, so can you
> please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org)
> so that we don't lose track of it.
I have seen this here:
https://bugs.freedesktop.org/show_bug.cgi?id=55984
does it make sense to start a new bug for that?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCREMBY (n.)
The dehydrated felt-tip pen attached by a string to the 'Don't Forget'
board in the kitchen which has never worked in living memory but which
no one can be bothered to throw away.
--- Douglas Adams, The Meaning of Liff
--
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] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
[resending, because the first post got rejected due to non-plaintext] Hi Guraraja, I am interested in this thread. I've been trying Gururaja's patches for audio as well. I rebased Guraja's patches on top of Matt's EDMA patches which were applied to the beaglebone 3.7 kernel repo. With some fixes to make it compile with CONFIG_DUMMY_REGULATOR enabled, Currently it breaks at set_dai_fmt in davinci-mcasp.c when an audio file is played. Could you try my tree on EVM? dts changes may be required to use mcasp1 on EVM, https://github.com/joelagnel/linux-kernel/commits/3.7 v3.7-rc2-fixes to v3.7-rc2-audio commits are Gururaja's patches which I applied, and after that are my commits to enable config , add dt data and some fixes. Thanks, Joel On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja wrote: > > Matt, > > On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: > > 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage > > exposes a bug in the AM33XX clock data for mcasp. After moving to > > clk_get() usage, the _init() of all registered hwmods fails on mcasp0 > > due to incorrect clock data causing clk_get() to fail. This causes all > > successive hwmods to fail to _init() leaving them in a bad state. > > > > This patch updates the mcasp clock entries so clk_get() will succeed. > > It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx > > boot. > > > I want to test Audio on AM335x Evm with your EDMA patches. I have few > patches for AM335x. > Can you share the link to the repo & branch on which I need to rebase? > The patches are related to mcasp dt node, mcasp pinmux in dt, etc... > > > > ..snip.. > ..snip.. > > > > > Thanks & Regards, > Gururaja > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 3.7-rc3
On Sunday, October 28, 2012 12:59:49 PM Linus Torvalds wrote: > It's been a week, time for -rc3! > > Nothing particularly stands out here. Lots of small fixes, exemplified > by the series of memory leak fixes in usb serial drivers. Just a lot > of random stuff.. > > Most of it is drivers (all over: drm, wireless, staging, usb, sound), > but there's a few filesystem updates (nfs, btrfs, ext4), arch updates > (arm, x86 and m68k) and just random stuff. Shortlog appended. Unfortunately, s2disk is broken with this one and previous -rc. In the majority of cases it just hangs the machine during hibernation, although sometimes it returns to user space reporting freezing problems, suspicions RCU usage and similar stuff, pretty much without any useful debug information. I'm quite confident that v3.6 was OK (and -stable based on that too), so it most likely is a recent regression. The in-kernel hibernation (ie. "echo disk > /sys/power/state") works no problem. So does suspend to RAM on my test boxes. So far I have been able to reproduce this 100% of the time on two machines with Intel CPUs and graphics driven by i915. I _suspect_ that this may be related to VT switching, because s2disk does some ugly things in that area which are not done by the in-kernel code. Dunno. Anyway, it looks like nothing short of bisection is going to help debug this, but I'm afraid I won't have the time to bisect within the next two weeks, so if anyone can reproduce this issue and will be able to bisect it, please help (openSUSE/Tumbleweed users anyone?). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, 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: [PATCH 2/3] ext4: introduce ext4_error_remove_page
On 10/30/12 04:07, Andi Kleen wrote: > Theodore Ts'o writes: >> Note that the problem that we're dealing with is buffered writes; so >> it's quite possible that the process which wrote the file, thus >> dirtying the page cache, has already exited; so there's no way we can >> guarantee we can inform the process which wrote the file via a signal >> or a error code return. > > Is that any different from other IO errors? It doesn't need to > be better. IMO, it is different in that next read from disk will likely succeed. (and read corrupted data) For IO errors come from disk failure, next read will likely fail again so we don't have to remember it somewhere. >> Also, if you're going to keep this state in memory, what happens if >> the inode gets pushed out of memory? > > You lose the error, just like you do today with any other IO error. -- Jun'ichi Nomura, NEC 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/
[GIT PULL] cputime: Cleanups and optimizations
Ingo, Please pull the latest cputime cleanups that can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git tags/cputime-cleanups-for-mingo for you to fetch changes up to 3e1df4f506836e6bea1ab61cf88c75c8b1840643: cputime: Separate irqtime accounting from generic vtime (2012-10-29 21:31:32 +0100) It is based on top of tip:sched/core of today. Tested on x86 and powerpc. Built-tested only on ia64 and s390. Thanks. Cputime cleanups and optimizations: * Gather vtime headers that were a bit scattered around * Separate irqtime and vtime namespaces that were colliding, resulting in useless calls to irqtime accounting. * Slightly optimize irq and guest vtime accounting. Signed-off-by: Frederic Weisbecker Frederic Weisbecker (5): vtime: Gather vtime declarations to their own header file vtime: Make vtime_account_system() irqsafe kvm: Directly account vtime to system on guest switch cputime: Specialize irq vtime hooks cputime: Separate irqtime accounting from generic vtime arch/ia64/kernel/time.c |8 arch/powerpc/kernel/time.c |4 ++-- arch/s390/kernel/vtime.c|4 arch/s390/kvm/kvm-s390.c|4 include/linux/hardirq.h | 15 +++--- include/linux/kernel_stat.h |9 + include/linux/kvm_host.h| 12 +-- include/linux/vtime.h | 47 +++ kernel/sched/cputime.c | 20 +- kernel/softirq.c|6 +++--- 10 files changed, 89 insertions(+), 40 deletions(-) create mode 100644 include/linux/vtime.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: [dm-crypt] cryptsetup not working under 3.6 - RT patch set seem to break it
On Mon, 29 Oct 2012, Tvrtko Ursulin wrote:
> On 29/10/12 20:14, Tvrtko Ursulin wrote:
> > Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> > guess it is worth a shot. I'll let you know what happens without -rt.
>
> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
>
> Copying in linux-rt-users.
>
> To recap, 3.6 RT seems to break dm-crypt. Try it like this:
>
> cryptsetup --debug --key-file=- luksOpen /some/luks/formatted/file any-label
>
> And kernel will fail like this:
>
> Kernel says this:
> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
>
> I think crypto modules are not getting auto loaded for some reason, but even
> if I load them manually before hand and still breaks in the same way.
I don't think it's a module problem. That code is not very helpful due
to _NOT_ showing the error number so it's hard to decode what actually
fails.
I put this on my todo list, but TBH it's low on my radar. If you are
interested then try to capture the failure with the function
tracer. Put a tracing_off() call into the failure code path, i.e.:
ret = crypt_alloc_tfms(cc, cipher_api);
if (ret < 0) {
+ tracing_off();
ti->error = "Error allocating crypto tfm";
goto bad;
}
Enable the function tracer before doing the cryptsetup invocation and
after that read out the trace, compress it and put it somewhere to
download or send it to me in private mail if you don't have a place to
put it.
I can decode the trace, but I don't have the capacity at the moment to
setup all the necessary stuff here and do the debugging myself.
Thanks,
tglx
--
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/5] fat: add mutex lock to fat_build_inode
On Sun, 28 Oct 2012 10:53:43 +0900 Namjae Jeon wrote: > From: Namjae Jeon > > fat_nfs_get_inode does not hold i_mutex of parent directory.So add > lock to fat_build_inode. Well.. why? Presumably this patch fixes some race. A good description of that race would be useful - partly because others may then be able to suggest alternative ways of fixing that bug. I'll merge these patches for some testing. I did merge these patches three weekes ago: fat-modify-nfs-mount-option.patch fat-exportfs-rebuild-inode-if-ilookup-fails.patch fat-exportfs-rebuild-inode-if-ilookup-fails-fix.patch fat-exportfs-rebuild-directory-inode-if-fat_dget-fails.patch documentation-update-nfs-option-in-filesystem-vfattxt.patch But I have no record of Bruce or Ogawa having reviewed/acked 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/
[ANNOUNCE] 3.4.15-rt25
Dear RT Folks,
I'm pleased to announce the 3.4.15-rt25 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
Head SHA1: 7fe212b3cf8cb2ba4dda85345130f7d3b0412e0f
Or to build 3.4.15-rt25 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.15.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.15-rt25.patch.xz
You can also build from 3.4.15-rt24 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/incr/patch-3.4.15-rt24-rt25.patch.xz
Enjoy,
-- Steve
Changes from 3.4.15-rt24:
---
Steven Rostedt (1):
Linux 3.4.15-rt25
Thomas Gleixner (1):
rcu: rcutiny: Prevent RCU stall
kernel/rcutiny_plugin.h |2 +-
localversion-rt |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/kernel/rcutiny_plugin.h b/kernel/rcutiny_plugin.h
index 22ecea0..97e359b 100644
--- a/kernel/rcutiny_plugin.h
+++ b/kernel/rcutiny_plugin.h
@@ -572,7 +572,7 @@ static noinline void rcu_read_unlock_special(struct
task_struct *t)
rcu_preempt_cpu_qs();
/* Hardware IRQ handlers cannot block. */
- if (in_irq() || in_serving_softirq()) {
+ if (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_OFFSET)) {
local_irq_restore(flags);
return;
}
diff --git a/localversion-rt b/localversion-rt
index b2111a2..c5b71f9 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt24
+-rt25
--
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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at "running init tables"
Hi again, On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote: > Are you able to go back to the current master, and get me a > log/screenshot with "nouveau.debug=trace" appended to your kernel > options? Hmmm I did just that on v3.7-rc3-8-g35fd3dc and it doesn't seem to output more stuff: http://mathieu.csetco.com/nouveau.jpeg -- Mathieu Chouquet-Stringer math...@csetco.com The sun itself sees not till heaven clears. -- William Shakespeare -- -- 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 3/4] cpufreq, powernow-k8: Change email address
On Tue, Oct 30, 2012 at 12:33:15AM +0100, Rafael J. Wysocki wrote: > On Monday, October 29, 2012 06:52:21 PM Andreas Herrmann wrote: > > > > Signed-off-by: Andreas Herrmann > > Am I supposed to take this one? Yes please. Thanks. -- Regards/Gruss, Boris. -- 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] dma: tegra: avoid channel lock up after free
Also code looks not thread-safe, is it ok? For example we can protect prepare functions with a spinlock and add tegra_dma_terminate_all_locked for calling on channel freeing under spinlock to avoid reschedule. What do you think? -- 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 3/4] cpufreq, powernow-k8: Change email address
On Monday, October 29, 2012 06:52:21 PM Andreas Herrmann wrote: > > Signed-off-by: Andreas Herrmann Am I supposed to take this one? Rafael > --- > drivers/cpufreq/powernow-k8.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c > index c16a3a5..e3ebb4f 100644 > --- a/drivers/cpufreq/powernow-k8.c > +++ b/drivers/cpufreq/powernow-k8.c > @@ -5,7 +5,7 @@ > * http://www.gnu.org/licenses/gpl.html > * > * Maintainer: > - * Andreas Herrmann > + * Andreas Herrmann > * > * Based on the powernow-k7.c module written by Dave Jones. > * (C) 2003 Dave Jones on behalf of SuSE Labs > -- I speak only for myself. Rafael J. Wysocki, 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: memcg/cgroup: do not fail fail on pre_destroy callbacks
Hello, Michal. > Tejun is planning to build on top of that and make some more cleanups > in the cgroup core (namely get rid of of the whole retry code in > cgroup_rmdir). I applied 1-3 to the following branch which is based on top of v3.6. git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git cgroup-destroy-updates I'll follow up with updates to the destroy path which will replace #4. #5 and #6 should be stackable on top. So, Andrew, there's likely be a conflict in the near future. Just dropping #4-#6 till Michal and I sort it out should be enough. Thanks. -- tejun -- 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] dma: tegra: avoid channel lock up after free
Fixed channel "lock up" after free.
Lock scenario: Channel 1 was allocated and prepared as slave_sg, used and freed.
Now preparation of cyclic dma on channel 1 will fail with err "DMA configuration
conflict" because tdc->isr_handler still selected to handle_once_dma_done.
This happens because tegra_dma_abort_all() won't be called on channel freeing
if pending list is empty or channel not busy. We need to clear isr_handler
on channel freeing to avoid locking. Also I added small optimization to prepare
functions, so current channel type checked before making allocations.
Signed-off-by: Dmitry Osipenko
---
drivers/dma/tegra20-apb-dma.c | 60 ++-
1 file changed, 25 insertions(+), 35 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 4d816be..5a557af 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -681,11 +681,6 @@ static void tegra_dma_terminate_all(struct dma_chan *dc)
bool was_busy;
spin_lock_irqsave(>lock, flags);
- if (list_empty(>pending_sg_req)) {
- spin_unlock_irqrestore(>lock, flags);
- return;
- }
-
if (!tdc->busy)
goto skip_dma_stop;
@@ -896,6 +891,15 @@ static struct dma_async_tx_descriptor
*tegra_dma_prep_slave_sg(
return NULL;
}
+ /*
+* Make sure that mode should not be conflicting with currently
+* configured mode.
+*/
+ if (tdc->isr_handler && tdc->isr_handler != handle_once_dma_done) {
+ dev_err(tdc2dev(tdc), "DMA configured in cyclic mode\n");
+ return NULL;
+ }
+
ret = get_transfer_param(tdc, direction, _ptr, _seq, ,
_size, _bw);
if (ret < 0)
@@ -968,20 +972,9 @@ static struct dma_async_tx_descriptor
*tegra_dma_prep_slave_sg(
if (flags & DMA_CTRL_ACK)
dma_desc->txd.flags = DMA_CTRL_ACK;
- /*
-* Make sure that mode should not be conflicting with currently
-* configured mode.
-*/
- if (!tdc->isr_handler) {
- tdc->isr_handler = handle_once_dma_done;
- tdc->cyclic = false;
- } else {
- if (tdc->cyclic) {
- dev_err(tdc2dev(tdc), "DMA configured in cyclic
mode\n");
- tegra_dma_desc_put(tdc, dma_desc);
- return NULL;
- }
- }
+
+ tdc->isr_handler = handle_once_dma_done;
+ tdc->cyclic = false;
return _desc->txd;
}
@@ -1024,6 +1017,16 @@ struct dma_async_tx_descriptor
*tegra_dma_prep_dma_cyclic(
}
/*
+* Make sure that mode should not be conflicting with currently
+* configured mode.
+*/
+ if (tdc->isr_handler &&
+ tdc->isr_handler != handle_cont_sngl_cycle_dma_done) {
+ dev_err(tdc2dev(tdc), "DMA configuration conflict\n");
+ return NULL;
+ }
+
+ /*
* We only support cycle transfer when buf_len is multiple of
* period_len.
*/
@@ -1097,20 +1100,8 @@ struct dma_async_tx_descriptor
*tegra_dma_prep_dma_cyclic(
sg_req->last_sg = true;
dma_desc->txd.flags = 0;
- /*
-* Make sure that mode should not be conflicting with currently
-* configured mode.
-*/
- if (!tdc->isr_handler) {
- tdc->isr_handler = handle_cont_sngl_cycle_dma_done;
- tdc->cyclic = true;
- } else {
- if (!tdc->cyclic) {
- dev_err(tdc2dev(tdc), "DMA configuration conflict\n");
- tegra_dma_desc_put(tdc, dma_desc);
- return NULL;
- }
- }
+ tdc->isr_handler = handle_cont_sngl_cycle_dma_done;
+ tdc->cyclic = true;
return _desc->txd;
}
@@ -1145,8 +1136,7 @@ static void tegra_dma_free_chan_resources(struct dma_chan
*dc)
dev_dbg(tdc2dev(tdc), "Freeing channel %d\n", tdc->id);
- if (tdc->busy)
- tegra_dma_terminate_all(dc);
+ tegra_dma_terminate_all(dc);
spin_lock_irqsave(>lock, flags);
list_splice_init(>pending_sg_req, _req_list);
--
1.7.12
--
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: Nouveau regression between 3.6 and 3.7-rc3: driver stuck at "running init tables"
On Tue, 2012-10-30 at 00:06 +0100, Mathieu Chouquet-Stringer wrote: > Hi Ben, Hey Mathieu, > > I haven't been able to boot any 3.7 kernels since there's a regression > which freezes my machine hard (a lenovo t530 with the dreaded optimus > thing). > > 3.6 used to work but 3.7 get stuck at (copied by hand but I have an ugly > screenshot if you'd like): > nouveau [ VBIOS][:01:00.0] running init tables Are you able to go back to the current master, and get me a log/screenshot with "nouveau.debug=trace" appended to your kernel options? Thanks, Ben. > > Note my uefi settings weren't modified during the whole thing. > > I've bisected the issue and git found that commit 4196fa is the one > causing trouble (looking at the diff, it's pretty big): > > Author: Ben Skeggs > Date: Tue Jul 10 14:36:38 2012 +1000 > > drm/nouveau/i2c: port to subdev interfaces > > v2/v3: Ben Skeggs > - fix typo in default bus selection > - fix accidental loss of destructor > > v4: Dmitry Eremin-Solenikov > - fix typo causing incorrect default i2c port settings when no BMP data > > While bisecting the matter, I had a couple of messages like the > following (6 actually). The addresses were always different (I could > send another ugly screenshot if you'd like). > > Condition still not met after 2000ms, skipping following opcodes > > followed by: > > Parsing VBIOUS init table 1 at offset 0x8183 > > At this point, the kernel was frozen hard (sysrq wasn't working)... > > I'm attaching the output of lspci and my kernel config. > > If you'd like me to add some debug statements or if you need more info, > feel free, I'd love to help. > > Cheers, > -- 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/
