Re: [PATCH V5 09/18] MIPS: Loongson: Add swiotlb to support big memory (>4GB).

[Huacai Chen]

Hi, David,

Seems like you are the original author of code in
arch/mips/cavium-octeon/dma-octeon.c. Could you please tell me why we
need mb() in alloc_coherent(), map_page(), map_sg()? It seems like
because of cache coherency (CPU write some data, then map the page for
a device, if without mb(), then device may read wrong data.) but I'm
not sure.

On Tue, Aug 14, 2012 at 1:54 AM, Konrad Rzeszutek Wilk
 wrote:
>> +static void *loongson_dma_alloc_coherent(struct device *dev, size_t size,
>> + dma_addr_t *dma_handle, gfp_t gfp, struct 
>> dma_attrs *attrs)
>> +{
>> + void *ret;
>> +
>> + if (dma_alloc_from_coherent(dev, size, dma_handle, ))
>> + return ret;
>> +
>> + /* ignore region specifiers */
>> + gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
>> +
>> +#ifdef CONFIG_ZONE_DMA
>> + if (dev == NULL)
>> + gfp |= __GFP_DMA;
>
> When would this happen? dev == NULL?
>
>> + else if (dev->coherent_dma_mask <= DMA_BIT_MASK(24))
>> + gfp |= __GFP_DMA;
>> + else
>> +#endif
>> +#ifdef CONFIG_ZONE_DMA32
>> + if (dev->coherent_dma_mask <= DMA_BIT_MASK(32))
>> + gfp |= __GFP_DMA32;
>> + else
>
> Why the 'else'
>> +#endif
>> + ;
>
> why?
>> + gfp |= __GFP_NORETRY;
>> +
>> + ret = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
>> + mb();
>
> Why the 'mb()' ? Can you just do
> return swiotlb_alloc_coherent(...)
>
>> + return ret;
>> +}
>> +
>> +static void loongson_dma_free_coherent(struct device *dev, size_t size,
>> + void *vaddr, dma_addr_t dma_handle, struct 
>> dma_attrs *attrs)
>> +{
>> + int order = get_order(size);
>> +
>> + if (dma_release_from_coherent(dev, order, vaddr))
>> + return;
>> +
>> + swiotlb_free_coherent(dev, size, vaddr, dma_handle);
>> +}
>> +
>> +static dma_addr_t loongson_dma_map_page(struct device *dev, struct page 
>> *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + dma_addr_t daddr = swiotlb_map_page(dev, page, offset, size,
>> + dir, attrs);
>> + mb();
>
> Please do 'return swiotlb_map_page(..)'..
>
> But if you are doing that why don't you just set the dma_ops.map_page = 
> swiotlb_map_page
> ?
>
>
>> + return daddr;
>> +}
>> +
>> +static int loongson_dma_map_sg(struct device *dev, struct scatterlist *sg,
>> + int nents, enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + int r = swiotlb_map_sg_attrs(dev, sg, nents, dir, NULL);
>> + mb();
>> +
>> + return r;
>> +}
>> +
>> +static void loongson_dma_sync_single_for_device(struct device *dev,
>> + dma_addr_t dma_handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + swiotlb_sync_single_for_device(dev, dma_handle, size, dir);
>> + mb();
>> +}
>> +
>> +static void loongson_dma_sync_sg_for_device(struct device *dev,
>> + struct scatterlist *sg, int nents,
>> + enum dma_data_direction dir)
>> +{
>> + swiotlb_sync_sg_for_device(dev, sg, nents, dir);
>> + mb();
>> +}
>> +
>
> I am not really sure why you have these extra functions, when you could
> just modify the dma_ops to point to the swiotlb ones
>
>> +static dma_addr_t loongson_unity_phys_to_dma(struct device *dev, 
>> phys_addr_t paddr)
>> +{
>> + return (paddr < 0x1000) ?
>> + (paddr | 0x8000) : paddr;
>> +}
>> +
>> +static phys_addr_t loongson_unity_dma_to_phys(struct device *dev, 
>> dma_addr_t daddr)
>> +{
>> + return (daddr < 0x9000 && daddr >= 0x8000) ?
>> + (daddr & 0x0fff) : daddr;
>> +}
>> +
>> +struct loongson_dma_map_ops {
>> + struct dma_map_ops dma_map_ops;
>> + dma_addr_t (*phys_to_dma)(struct device *dev, phys_addr_t paddr);
>> + phys_addr_t (*dma_to_phys)(struct device *dev, dma_addr_t daddr);
>> +};
>> +
>> +dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>> +{
>> + struct loongson_dma_map_ops *ops = container_of(get_dma_ops(dev),
>> + struct loongson_dma_map_ops, 
>> dma_map_ops);
>> +
>> + return ops->phys_to_dma(dev, paddr);
>> +}
>> +
>> +phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
>> +{
>> + struct loongson_dma_map_ops *ops = container_of(get_dma_ops(dev),
>> + struct loongson_dma_map_ops, 
>> dma_map_ops);
>> +
>> + return ops->dma_to_phys(dev, daddr);
>> +}
>> +
>> +static int loongson_dma_set_mask(struct device *dev, u64 mask)
>> +{
>> + /* Loongson doesn't support DMA above 32-bit */
>> + if (mask > DMA_BIT_MASK(32))
>> + 

Re: psmouse synaptics: "hardware appears to be different" bail out

[Andreas Mohr]

Hi,

On Fri, Jul 20, 2012 at 08:21:45PM +0200, Andreas Mohr wrote:
> Hi,
> 
> On Mon, Jul 16, 2012 at 03:07:19PM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 16, 2012 at 11:44:53PM +0200, Andreas Mohr wrote:
> > > Hi,
> > > 
> > > just found the following in dmesg after resume
> > > (currently running -rc7):
> > > 
> > > [ 9312.672073] psmouse serio2: synaptics: hardware appears to be
> > > different: id(149271-149271), model(114865-114865), caps(d04771-d04773),
> > > ext(a4-a4).
> > > 
> > > Acer Aspire One A110L here.
> > > 
> > > Any clever thoughts about this?
> > > Just thought that it might be useful to report it,
> > > especially since the function (in drivers/input/mouse/synaptics.c)
> > > bails out right after this check/message.
> > 
> > Hmm, we do not really expect the touchpad change it's caracteristics at
> > all during its lifetime, so no clever ideas here... It looks like a
> > single bit error, but KBC should have signalled parity error in this
> > case...
> 
> OK, that might be true in fact.
> I disassembled that device recently (and did quite a bit of work),
> so perhaps the touchpad connection isn't as reliable as I'd want it to
> be...
> 
> 
> Problem is that now (and some other times, too) S2R resume
> ended up with a dead x.org keyboard (synaptics i.e. mouse pointer
> was still working fine).
> Remote login was ok.
> 
> In dmesg, I found:
> 
> [   13.694115] atkbd serio0: Spurious NAK on isa0060/serio0. Some
> program might be trying to access hardware directly.
> 
> and then
> 
> [ 8278.484469] atkbd serio0: Spurious ACK on isa0060/serio0. Some
> program might be trying to access hardware directly.
> 
> which is the one that occurred around the time of the S2R breakage.
> I then triggered a remote pm-suspend,
> and after S2R keyboard WAS FINE AGAIN, with NO dmesg error logged this
> time!!

Hi,

happened again, this time with different but quite ominous messages
("Unable to initialize device."):

[15520.944017] PM: resume of devices complete after 1049.856 msecs
[15520.950597] PM: resume devices took 1.060 seconds
[15520.950787] PM: Finishing wakeup.
[15520.950793] Restarting tasks ... done.
[15520.990705] video LNXVIDEO:00: Restoring backlight state
[15521.107761] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[15521.107774] Bluetooth: BNEP filters: protocol multicast
[15521.287109] Bluetooth: RFCOMM TTY layer initialized
[15521.287158] Bluetooth: RFCOMM socket layer initialized
[15521.287168] Bluetooth: RFCOMM ver 1.11
[15521.347768] atkbd serio0: Spurious ACK on isa0060/serio0. Some
program might be trying to access hardware directly.
[15521.352164] mmc0: new SDHC card at address b368
[15521.357576] mmcblk0: mmc0:b368   14.9 GiB 
[15521.370884]  mmcblk0: p1
[15521.540130] psmouse serio2: synaptics: Unable to initialize device.
[15522.644250] psmouse serio2: synaptics: Touchpad model: 1, fw: 7.2,
id: 0x1c0b1, caps: 0xd04773/0xa4/0xa
[15522.700396] input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio2/input/input12
[15523.299199] r8169 :02:00.0: eth1: link down

Identical symptoms: touchpad mighty fine, keyboard DEAD. Remote pm-suspend
fixed everything.
This time this occurred at the first suspend after initial kernel bootup
(not sure about previous incidents).

Log of the subsequent second resume that managed to repair the state:

[16584.645148] PM: resume of devices complete after 1052.387 msecs
[16584.648803] PM: resume devices took 1.050 seconds
[16584.648996] PM: Finishing wakeup.
[16584.649002] Restarting tasks ... done.
[16584.684401] video LNXVIDEO:00: Restoring backlight state
[16585.041476] mmc0: new SDHC card at address b368
[16585.055439] mmcblk0: mmc0:b368   14.9 GiB 
[16585.058917]  mmcblk0: p1
[16585.330295] r8169 :02:00.0: eth1: link up

Note the large amount of *missing* input device messages (all due to error
condition?) in the non-fatal case.


"Some program might be trying to access hardware directly." - mayhaps
on resume we've got some BIOS DMI handlers fumbling things
that they shouldn't fumble?

Still running -rc7, though (time for upgrade treadmill, I know ;).

Thanks,

Andreas Mohr
--
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: [ 10/44] ALSA: hda - remove quirk for Dell Vostro 1015

[Takashi Iwai]

At Tue, 14 Aug 2012 07:17:43 +0200,
David Henningsson wrote:
> 
> On 08/14/2012 12:02 AM, Greg Kroah-Hartman wrote:
> > From: Greg KH 
> >
> > 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> As my previous email states, I still object to this patch being applied 
> to 3.0 (it is for 3.2+). Repeating that text now:
> 
> This patch will not work on 3.0 because there is no model=auto fallback, 
> so please remove it from 3.0-stable-queue.

Right, Greg, could you remove this patch from the 3.0 queue?
This will cause a regression on 3.0.


thanks,

Takashi

> 
> In the original patch [1], the cc to stable was written as this:
> 
> Cc: sta...@kernel.org (3.2+)
> 
> Is there a better way to specify what kernels it should and should not 
> be applied to, as it doesn't seem to have worked in this case?
> 
> [1] 
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=e9fc83cb2e5877801a255a37ddbc5be996ea8046
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 02/12] dm: Use bioset's front_pad for dm_rq_clone_bio_info

[Jun'ichi Nomura]

On 08/07/12 07:08, Kent Overstreet wrote:
>  struct dm_rq_clone_bio_info {
>   struct bio *orig;
>   struct dm_rq_target_io *tio;
> + struct bio clone;
>  };
...
> - pools->bs = bioset_create(pool_size, 0);
> + pools->bs = bioset_create(pool_size,
> +   offsetof(struct dm_rq_clone_bio_info, orig));
>   if (!pools->bs)
>   goto free_tio_pool_and_out;

Shouldn't this be offsetof(struct dm_rq_clone_bio_info, clone)?

-- 
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/

Re: [PATCH 0/7] zram/zsmalloc promotion

[Nitin Gupta]

On 08/13/2012 07:35 PM, Greg Kroah-Hartman wrote:
> On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote:
>> This patchset promotes zram/zsmalloc from staging.
>> Both are very clean and zram is used by many embedded product
>> for a long time.
>>
>> [1-3] are patches not merged into linux-next yet but needed
>> it as base for [4-5] which promotes zsmalloc.
>> Greg, if you merged [1-3] already, skip them.
> 
> I've applied 1-3 and now 4, but that's it, I can't apply the rest
> without getting acks from the -mm maintainers, sorry.  Please work with
> them to get those acks, and then I will be glad to apply the rest (after
> you resend them of course...)
>

On a second thought, I think zsmalloc should stay in drivers/block/zram
since zram is now the only user of zsmalloc since zcache and ramster are
moving to another allocator. Secondly, zsmalloc does not provide
standard slab like interface, so should not be part of mm/. At the best,
it could be moved to lib/ with header in include/linux just like genalloc.

Thanks,
Nitin

--
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] drivers/mmc: Add realtek pcie sdmmc host driver

[wei_wang]

From: Wei WANG 

Realtek PCI-E SD/MMC card host driver is used to access SD/MMC card,
with the help of Realtek PCI-E card reader MFD driver.

Signed-off-by: Wei WANG 
---
 drivers/mmc/host/Kconfig  |7 +
 drivers/mmc/host/Makefile |2 +
 drivers/mmc/host/rtsx_pci_sdmmc.c | 1348 +
 3 files changed, 1357 insertions(+)
 create mode 100644 drivers/mmc/host/rtsx_pci_sdmmc.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index aa131b3..d6f0c01 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -612,3 +612,10 @@ config MMC_USHC
 
  Note: These controllers only support SDIO cards and do not
  support MMC or SD memory cards.
+
+config MMC_REALTEK_PCI
+   tristate "Realtek PCI-E SD/MMC Card Interface Driver"
+   depends on MFD_RTSX_PCI
+   help
+ Say Y here to include driver code to support SD/MMC card interface
+ of Realtek PCI-E driver-based card reader
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 8922b06..4679ba3 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -45,6 +45,8 @@ obj-$(CONFIG_MMC_JZ4740)  += jz4740_mmc.o
 obj-$(CONFIG_MMC_VUB300)   += vub300.o
 obj-$(CONFIG_MMC_USHC) += ushc.o
 
+obj-$(CONFIG_MMC_REALTEK_PCI)  += rtsx_pci_sdmmc.o
+
 obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-pltfm.o
 obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
 obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)  += sdhci-esdhc-imx.o
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
new file mode 100644
index 000..a71abbf
--- /dev/null
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -0,0 +1,1348 @@
+/* Realtek PCI-Express SD/MMC Card Interface driver
+ *
+ * Copyright(c) 2009 Realtek Semiconductor Corp. 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; either version 2, or (at your option) any
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ *
+ * Author:
+ *   Wei WANG 
+ *   No. 450, Shenhu Road, Suzhou Industry Park, Suzhou, China
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_RW_REG_CNT 1024
+
+#define RTSX_MAX_BLOCK_COUNT   65536
+#define RTSX_MAX_BLOCK_LENGTH  2048
+
+/* SD Tuning Data Structure
+ * Record continuous timing phase path
+ */
+struct timing_phase_path {
+   int start;
+   int end;
+   int mid;
+   int len;
+};
+
+struct realtek_pci_sdmmc {
+   struct platform_device  *pdev;
+   struct rtsx_pcr *pcr;
+   struct mmc_host *mmc;
+   struct mmc_request  *mrq;
+
+   struct mutexhost_mutex;
+
+   booleject;
+   boolinitial_mode;
+   boolddr_mode;
+};
+
+static inline struct device *sdmmc_dev(struct realtek_pci_sdmmc *host)
+{
+   return &(host->pdev->dev);
+}
+
+static inline void sd_clear_error(struct realtek_pci_sdmmc *host)
+{
+   rtsx_pci_write_register(host->pcr, CARD_STOP,
+   SD_STOP | SD_CLR_ERR, SD_STOP | SD_CLR_ERR);
+}
+
+#ifdef CONFIG_MMC_DEBUG
+
+static void sd_print_debug_regs(struct realtek_pci_sdmmc *host)
+{
+   struct rtsx_pcr *pcr = host->pcr;
+   u16 i;
+   u8 *ptr;
+
+   /* Print SD host internal registers */
+   rtsx_pci_init_cmd(pcr);
+   for (i = 0xFDA0; i <= 0xFDAE; i++)
+   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
+   for (i = 0xFD52; i <= 0xFD69; i++)
+   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
+   rtsx_pci_send_cmd(pcr, 100);
+
+   ptr = rtsx_pci_get_cmd_data(pcr);
+   for (i = 0xFDA0; i <= 0xFDAE; i++)
+   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   for (i = 0xFD52; i <= 0xFD69; i++)
+   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+}
+
+#else
+
+#define sd_print_debug_regs(host)
+
+#endif
+
+static int sd_read_data(struct realtek_pci_sdmmc *host, u8 *cmd, u16 byte_cnt,
+   u8 *buf, int buf_len, int timeout)
+{
+   struct rtsx_pcr *pcr = host->pcr;
+   int err, i;
+   u8 trans_mode;
+
+   dev_dbg(sdmmc_dev(host), "%s: SD/MMC CMD %d\n",
+   __func__, cmd[0] - 0x40);
+
+   if (!buf)
+   buf_len = 0;
+
+   if ((cmd[0] & 0x3F) == 

[PATCH v2] media: davinci: fix section mismatch warnings

[Prabhakar Lad]

From: Lad, Prabhakar 

This patch fixes section mismatch warnings for
davinci video drivers.

Signed-off-by: Lad, Prabhakar 
Signed-off-by: Manjunath Hadli 
---
 Changes for v2:
 1: Annotate probe with __devinit.
 2: Fixed the commit message.

 drivers/media/video/davinci/dm355_ccdc.c   |2 +-
 drivers/media/video/davinci/dm644x_ccdc.c  |2 +-
 drivers/media/video/davinci/isif.c |2 +-
 drivers/media/video/davinci/vpfe_capture.c |2 +-
 drivers/media/video/davinci/vpif.c |2 +-
 drivers/media/video/davinci/vpss.c |2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 5b68847..ce0e413 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -965,7 +965,7 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
 };
 
-static int __init dm355_ccdc_probe(struct platform_device *pdev)
+static int __devinit dm355_ccdc_probe(struct platform_device *pdev)
 {
void (*setup_pinmux)(void);
struct resource *res;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
index 9303fe5..ee7942b 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -957,7 +957,7 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
 };
 
-static int __init dm644x_ccdc_probe(struct platform_device *pdev)
+static int __devinit dm644x_ccdc_probe(struct platform_device *pdev)
 {
struct resource *res;
int status = 0;
diff --git a/drivers/media/video/davinci/isif.c 
b/drivers/media/video/davinci/isif.c
index 5278fe7..b99d542 100644
--- a/drivers/media/video/davinci/isif.c
+++ b/drivers/media/video/davinci/isif.c
@@ -1032,7 +1032,7 @@ static struct ccdc_hw_device isif_hw_dev = {
},
 };
 
-static int __init isif_probe(struct platform_device *pdev)
+static int __devinit isif_probe(struct platform_device *pdev)
 {
void (*setup_pinmux)(void);
struct resource *res;
diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 49a845f..843b138 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1829,7 +1829,7 @@ static struct vpfe_device *vpfe_initialize(void)
  * itself to the V4L2 driver and initializes fields of each
  * device objects
  */
-static __init int vpfe_probe(struct platform_device *pdev)
+static __devinit int vpfe_probe(struct platform_device *pdev)
 {
struct vpfe_subdev_info *sdinfo;
struct vpfe_config *vpfe_cfg;
diff --git a/drivers/media/video/davinci/vpif.c 
b/drivers/media/video/davinci/vpif.c
index b3637af..9bd3caa 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -417,7 +417,7 @@ int vpif_channel_getfid(u8 channel_id)
 }
 EXPORT_SYMBOL(vpif_channel_getfid);
 
-static int __init vpif_probe(struct platform_device *pdev)
+static int __devinit vpif_probe(struct platform_device *pdev)
 {
int status = 0;
 
diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 3e5cf27..146e4b0 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -357,7 +357,7 @@ void dm365_vpss_set_pg_frame_size(struct vpss_pg_frame_size 
frame_size)
 }
 EXPORT_SYMBOL(dm365_vpss_set_pg_frame_size);
 
-static int __init vpss_probe(struct platform_device *pdev)
+static int __devinit vpss_probe(struct platform_device *pdev)
 {
struct resource *r1, *r2;
char *platform_name;
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 10/44] ALSA: hda - remove quirk for Dell Vostro 1015

[David Henningsson]

On 08/14/2012 12:02 AM, Greg Kroah-Hartman wrote:

From: Greg KH 

3.0-stable review patch.  If anyone has any objections, please let me know.


As my previous email states, I still object to this patch being applied 
to 3.0 (it is for 3.2+). Repeating that text now:


This patch will not work on 3.0 because there is no model=auto fallback, 
so please remove it from 3.0-stable-queue.


In the original patch [1], the cc to stable was written as this:

Cc: sta...@kernel.org (3.2+)

Is there a better way to specify what kernels it should and should not 
be applied to, as it doesn't seem to have worked in this case?


[1] 
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=e9fc83cb2e5877801a255a37ddbc5be996ea8046


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
--
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] m68k: select CONFIG_GENERIC_ATOMIC64 for all m68k CPU types

[Fengguang Wu]

On Tue, Aug 14, 2012 at 02:45:33PM +1000, g...@snapgear.com wrote:
> From: Greg Ungerer 
> 
> There is no specific atomic64 support code for any m68k CPUs, so we should
> select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection
> of this and select it for all m68k.
>
> Signed-off-by: Greg Ungerer 

Signed-off-by: Fengguang Wu 

Thanks for the complete solution!
--
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] davinci: fix build warning when CONFIG_DEBUG_SECTION_MISMATCH is enabled

[Prabhakar Lad]

Hi Mauro,

Please drop this patch which is queued for 3.7, the actual fix should be
to annotate probe with __devinit. I'll be sending V2 with the correct fix.

Thx,
--Prabhakar

On Monday 13 August 2012 03:02 PM, Prabhakar Lad wrote:
> From: Lad, Prabhakar 
> 
> Signed-off-by: Lad, Prabhakar 
> Signed-off-by: Manjunath Hadli 
> ---
>  drivers/media/video/davinci/dm355_ccdc.c   |2 +-
>  drivers/media/video/davinci/dm644x_ccdc.c  |2 +-
>  drivers/media/video/davinci/isif.c |2 +-
>  drivers/media/video/davinci/vpfe_capture.c |2 +-
>  drivers/media/video/davinci/vpif.c |2 +-
>  drivers/media/video/davinci/vpss.c |2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
> b/drivers/media/video/davinci/dm355_ccdc.c
> index 5b68847..2eb7dbd 100644
> --- a/drivers/media/video/davinci/dm355_ccdc.c
> +++ b/drivers/media/video/davinci/dm355_ccdc.c
> @@ -1060,7 +1060,7 @@ static int dm355_ccdc_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static struct platform_driver dm355_ccdc_driver = {
> +static __refdata struct platform_driver dm355_ccdc_driver = {
>   .driver = {
>   .name   = "dm355_ccdc",
>   .owner = THIS_MODULE,
> diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
> b/drivers/media/video/davinci/dm644x_ccdc.c
> index 9303fe5..3ffb7f2 100644
> --- a/drivers/media/video/davinci/dm644x_ccdc.c
> +++ b/drivers/media/video/davinci/dm644x_ccdc.c
> @@ -1068,7 +1068,7 @@ static const struct dev_pm_ops dm644x_ccdc_pm_ops = {
>   .resume = dm644x_ccdc_resume,
>  };
>  
> -static struct platform_driver dm644x_ccdc_driver = {
> +static __refdata struct platform_driver dm644x_ccdc_driver = {
>   .driver = {
>   .name   = "dm644x_ccdc",
>   .owner = THIS_MODULE,
> diff --git a/drivers/media/video/davinci/isif.c 
> b/drivers/media/video/davinci/isif.c
> index 5278fe7..6ce4249 100644
> --- a/drivers/media/video/davinci/isif.c
> +++ b/drivers/media/video/davinci/isif.c
> @@ -1148,7 +1148,7 @@ static int isif_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> -static struct platform_driver isif_driver = {
> +static __refdata struct platform_driver isif_driver = {
>   .driver = {
>   .name   = "isif",
>   .owner = THIS_MODULE,
> diff --git a/drivers/media/video/davinci/vpfe_capture.c 
> b/drivers/media/video/davinci/vpfe_capture.c
> index 49a845f..572d8f0 100644
> --- a/drivers/media/video/davinci/vpfe_capture.c
> +++ b/drivers/media/video/davinci/vpfe_capture.c
> @@ -2066,7 +2066,7 @@ static const struct dev_pm_ops vpfe_dev_pm_ops = {
>   .resume = vpfe_resume,
>  };
>  
> -static struct platform_driver vpfe_driver = {
> +static __refdata struct platform_driver vpfe_driver = {
>   .driver = {
>   .name = CAPTURE_DRV_NAME,
>   .owner = THIS_MODULE,
> diff --git a/drivers/media/video/davinci/vpif.c 
> b/drivers/media/video/davinci/vpif.c
> index b3637af..a058fed 100644
> --- a/drivers/media/video/davinci/vpif.c
> +++ b/drivers/media/video/davinci/vpif.c
> @@ -490,7 +490,7 @@ static const struct dev_pm_ops vpif_pm = {
>  #define vpif_pm_ops NULL
>  #endif
>  
> -static struct platform_driver vpif_driver = {
> +static __refdata struct platform_driver vpif_driver = {
>   .driver = {
>   .name   = "vpif",
>   .owner = THIS_MODULE,
> diff --git a/drivers/media/video/davinci/vpss.c 
> b/drivers/media/video/davinci/vpss.c
> index 3e5cf27..8f682d8 100644
> --- a/drivers/media/video/davinci/vpss.c
> +++ b/drivers/media/video/davinci/vpss.c
> @@ -460,7 +460,7 @@ static int __devexit vpss_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static struct platform_driver vpss_driver = {
> +static __refdata struct platform_driver vpss_driver = {
>   .driver = {
>   .name   = "vpss",
>   .owner = THIS_MODULE,
> 

--
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] m68k: select CONFIG_GENERIC_ATOMIC64 for all m68k CPU types

[gerg]

From: Greg Ungerer 

There is no specific atomic64 support code for any m68k CPUs, so we should
select CONFIG_GENERIC_ATOMC64 for all. Remove the existing per CPU selection
of this and select it for all m68k.

Signed-off-by: Greg Ungerer 
---
 arch/m68k/Kconfig |1 +
 arch/m68k/Kconfig.cpu |4 
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 0b0f8b8..26bfa46 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -5,6 +5,7 @@ config M68K
select HAVE_AOUT if MMU
select HAVE_GENERIC_HARDIRQS
select GENERIC_IRQ_SHOW
+   select GENERIC_ATOMIC64
select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
select GENERIC_CPU_DEVICES
select GENERIC_STRNCPY_FROM_USER if MMU
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 43a9f8f..765e375 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -56,7 +56,6 @@ config MCPU32
 config M68020
bool "68020 support"
depends on MMU
-   select GENERIC_ATOMIC64
select CPU_HAS_ADDRESS_SPACES
help
  If you anticipate running this kernel on a computer with a MC68020
@@ -67,7 +66,6 @@ config M68020
 config M68030
bool "68030 support"
depends on MMU && !MMU_SUN3
-   select GENERIC_ATOMIC64
select CPU_HAS_ADDRESS_SPACES
help
  If you anticipate running this kernel on a computer with a MC68030
@@ -77,7 +75,6 @@ config M68030
 config M68040
bool "68040 support"
depends on MMU && !MMU_SUN3
-   select GENERIC_ATOMIC64
select CPU_HAS_ADDRESS_SPACES
help
  If you anticipate running this kernel on a computer with a MC68LC040
@@ -88,7 +85,6 @@ config M68040
 config M68060
bool "68060 support"
depends on MMU && !MMU_SUN3
-   select GENERIC_ATOMIC64
select CPU_HAS_ADDRESS_SPACES
help
  If you anticipate running this kernel on a computer with a MC68060
-- 
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/32] provide interfaces to access PCIe capabilities registers

[Bjorn Helgaas]

On Wed, Aug 1, 2012 at 8:54 AM, Jiang Liu  wrote:
> From: Jiang Liu 
>
> As suggested by Bjorn Helgaas and Don Dutile in threads
> http://www.spinics.net/lists/linux-pci/msg15663.html, we could improve access
> to PCIe capabilities register in to way:
> 1) cache content of PCIe Capabilities Register into struct pce_dev to avoid
>repeatedly reading this register because it's read only.
> 2) provide access functions for PCIe Capabilities registers to hide 
> differences
>among PCIe base specifications, so the caller don't need to handle those
>differences.
>
> This patch set applies to
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci-next

Would you mind rebasing this to v3.6-rc1?  I think you posted this
when my branch was still 3.5-based, and there are some upstream
changes that cause minor conflicts here.

You currently have:

int pci_pcie_capability_change_word(struct pci_dev *dev, int pos,
u16 set_bits, u16 clear_bits)

I think this is a bit awkward because the function name doesn't
suggest *how* the word will be changed, and the clearing happens
before the setting (opposite the parameter order).  Something like:

int pci_pcie_capability_mask_and_set_word(..., u16 mask, u16 set) or
int pci_pcie_capability_clear_and_set_word(..., u16 clear, u16 set)

would be more obvious.  If you use "mask_and_set", I think the
function should do "(val & mask) | set" with the complement being at
the call site.  If you use "clear_and_set", I think it's OK to do
"(val & ~mask) | set" as in your current patch.

I know I suggested the "pci_pcie_capability_*" names, but they're
getting a bit unwieldy, especially if we do "mask_and_set" or similar.
 There are already several "pcie_*" functions, so maybe we should
drop the leading "pci_" from these and just have:

pcie_capability_read_word
pcie_capability_write_word
pcie_capability_mask_and_set_word

Bjorn
--
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: Backports mailing list

[David Miller]

From: "Luis R. Rodriguez" 
Date: Mon, 13 Aug 2012 13:42:53 -0700

> I was hoping we can get a mailing list set up on vger for the
> project, perhaps backpo...@vger.kernel.org, so we don't flood the
> other mailing lists with random kernel backport junk. Please let me
> know if this is reasonable.

It would have been so much easier if you simply just asked for this
instead of giving me a life story of all of these projects to read.

backpo...@vger.kernel.org has been created
--
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] mmc: card: Skip secure option for MoviNAND.

[Kyungmin Park]

and also you should update "MMC_QUIRK_MOVINAND_SECURE" also.

On 8/14/12, Kyungmin Park  wrote:
> Hi Ian,
>
> "MMC_QUIRK_SKIP_SECURE"? It seems it support secure discard but want
> to skip. but it's wrong. it's broken feature at listed MoviNAND.
> As linus suggested, SECURE_BROKEN is better.
>
> Thank you,
> Kyungmin Park
>
> On 8/14/12, IAN CHEN  wrote:
>> For several MoviNAND, there are some known issue with secure option.
>> For these specific MoviNAND device, we skip secure option.
>>
>> Signed-off-by: Ian Chen 
>> ---
>>  drivers/mmc/card/block.c |   24 +++-
>>  include/linux/mmc/card.h |1 +
>>  2 files changed, 24 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index f1c84de..a01cc14 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1411,7 +1411,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
>> struct request *req)
>>  /* complete ongoing async transfer before issuing discard */
>>  if (card->host->areq)
>>  mmc_blk_issue_rw_rq(mq, NULL);
>> -if (req->cmd_flags & REQ_SECURE)
>> +if (req->cmd_flags & REQ_SECURE &&
>> +!(card->quirks & MMC_QUIRK_SKIP_SECURE))
>>  ret = mmc_blk_issue_secdiscard_rq(mq, req);
>>  else
>>  ret = mmc_blk_issue_discard_rq(mq, req);
>> @@ -1716,6 +1717,7 @@ force_ro_fail:
>>  #define CID_MANFID_SANDISK  0x2
>>  #define CID_MANFID_TOSHIBA  0x11
>>  #define CID_MANFID_MICRON   0x13
>> +#define CID_MANFID_SAMSUNG  0x15
>>
>>  static const struct mmc_fixup blk_fixups[] =
>>  {
>> @@ -1752,6 +1754,26 @@ static const struct mmc_fixup blk_fixups[] =
>>  MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
>>MMC_QUIRK_LONG_READ_TIME),
>>
>> +/*
>> + * Some issue about secure erase/secure trim for Samsung MoviNAND
>> + */
>> +MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
>> +  MMC_QUIRK_MOVINAND_SECURE),
>> +
>>  END_FIXUP
>>  };
>>
>> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
>> index 111aca5..b639a92 100644
>> --- a/include/linux/mmc/card.h
>> +++ b/include/linux/mmc/card.h
>> @@ -239,6 +239,7 @@ struct mmc_card {
>>  #define MMC_QUIRK_BLK_NO_CMD23  (1<<7)  /* Avoid CMD23 for 
>> regular
>> multiblock */
>>  #define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8)   /* Avoid sending 512
>> bytes in */
>>  #define MMC_QUIRK_LONG_READ_TIME (1<<9) /* Data read time > CSD 
>> says */
>> +#define MMC_QUIRK_SKIP_SECURE (1<<10)   /* Skip secure for 
>> erase/trim */
>>  /* byte mode */
>>  unsigned intpoweroff_notify_state;  /* eMMC4.5 notify feature */
>>  #define MMC_NO_POWER_NOTIFICATION   0
>> --
>> 1.7.0.4
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [PATCH v2] mmc: card: Skip secure option for MoviNAND.

[Kyungmin Park]

Hi Ian,

"MMC_QUIRK_SKIP_SECURE"? It seems it support secure discard but want
to skip. but it's wrong. it's broken feature at listed MoviNAND.
As linus suggested, SECURE_BROKEN is better.

Thank you,
Kyungmin Park

On 8/14/12, IAN CHEN  wrote:
> For several MoviNAND, there are some known issue with secure option.
> For these specific MoviNAND device, we skip secure option.
>
> Signed-off-by: Ian Chen 
> ---
>  drivers/mmc/card/block.c |   24 +++-
>  include/linux/mmc/card.h |1 +
>  2 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index f1c84de..a01cc14 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -1411,7 +1411,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
> struct request *req)
>   /* complete ongoing async transfer before issuing discard */
>   if (card->host->areq)
>   mmc_blk_issue_rw_rq(mq, NULL);
> - if (req->cmd_flags & REQ_SECURE)
> + if (req->cmd_flags & REQ_SECURE &&
> + !(card->quirks & MMC_QUIRK_SKIP_SECURE))
>   ret = mmc_blk_issue_secdiscard_rq(mq, req);
>   else
>   ret = mmc_blk_issue_discard_rq(mq, req);
> @@ -1716,6 +1717,7 @@ force_ro_fail:
>  #define CID_MANFID_SANDISK   0x2
>  #define CID_MANFID_TOSHIBA   0x11
>  #define CID_MANFID_MICRON0x13
> +#define CID_MANFID_SAMSUNG   0x15
>
>  static const struct mmc_fixup blk_fixups[] =
>  {
> @@ -1752,6 +1754,26 @@ static const struct mmc_fixup blk_fixups[] =
>   MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
> MMC_QUIRK_LONG_READ_TIME),
>
> + /*
> +  * Some issue about secure erase/secure trim for Samsung MoviNAND
> +  */
> + MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> + MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
> +   MMC_QUIRK_MOVINAND_SECURE),
> +
>   END_FIXUP
>  };
>
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 111aca5..b639a92 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -239,6 +239,7 @@ struct mmc_card {
>  #define MMC_QUIRK_BLK_NO_CMD23   (1<<7)  /* Avoid CMD23 for 
> regular
> multiblock */
>  #define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8)/* Avoid sending 512
> bytes in */
>  #define MMC_QUIRK_LONG_READ_TIME (1<<9)  /* Data read time > CSD 
> says */
> +#define MMC_QUIRK_SKIP_SECURE (1<<10)/* Skip secure for 
> erase/trim */
>   /* byte mode */
>   unsigned intpoweroff_notify_state;  /* eMMC4.5 notify feature */
>  #define MMC_NO_POWER_NOTIFICATION0
> --
> 1.7.0.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [PATCH 5/5] Fixes a potential bug in android/logger.c

[Cruz Julian Bishop]

On Mon, 2012-08-13 at 19:01 -0700, Greg KH wrote:
> On Thu, Aug 02, 2012 at 09:50:44AM +1000, Ryan Mallon wrote:
> > On 01/08/12 14:54, Cruz Julian Bishop wrote:
> > > Previously, when calling is_between(a, b, c), the calculation was wrong.
> > > It counted C as between A and B if C was equal to B, but not A.
> > > 
> > > Example of this are:
> > > 
> > > is_between(1, 10, 10) = 1 (Expected: 0)
> > > is_between(1, 10, 1) = 0 (Expected: 0)
> > > is_between(20, 10, 10) = 1 (Expected: 0)
> > > 
> > > And so on and so forth.
> > > 
> > > Obviously, ten is not a number between one and ten - only two to eight 
> > > are, so I made this patch :)
> > 
> > Is nine not a number between one and ten? :-p.
> > 
> > The question with a patch like this is whether the function's
> > documentation, which says it returns 1 if a < c < b is wrong, or whether
> > the implementation, which does a < c <= b is wrong. If the documentation
> > is wrong, and something is relying on the current implementation, then
> > this patch might actually break things.
> 
> I agree, which is correct?  I'd stick with the code for now, care to fix
> the comment instead?
> 
> greg k-h

Sure, I'll send a new patch for it soon


--
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] mmc: card: Skip secure option for MoviNAND.

[IAN CHEN]

For several MoviNAND, there are some known issue with secure option.
For these specific MoviNAND device, we skip secure option.

Signed-off-by: Ian Chen 
---
 drivers/mmc/card/block.c |   24 +++-
 include/linux/mmc/card.h |1 +
 2 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index f1c84de..a01cc14 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1411,7 +1411,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
struct request *req)
/* complete ongoing async transfer before issuing discard */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
-   if (req->cmd_flags & REQ_SECURE)
+   if (req->cmd_flags & REQ_SECURE &&
+   !(card->quirks & MMC_QUIRK_SKIP_SECURE))
ret = mmc_blk_issue_secdiscard_rq(mq, req);
else
ret = mmc_blk_issue_discard_rq(mq, req);
@@ -1716,6 +1717,7 @@ force_ro_fail:
 #define CID_MANFID_SANDISK 0x2
 #define CID_MANFID_TOSHIBA 0x11
 #define CID_MANFID_MICRON  0x13
+#define CID_MANFID_SAMSUNG 0x15

 static const struct mmc_fixup blk_fixups[] =
 {
@@ -1752,6 +1754,26 @@ static const struct mmc_fixup blk_fixups[] =
MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
  MMC_QUIRK_LONG_READ_TIME),

+   /*
+* Some issue about secure erase/secure trim for Samsung MoviNAND
+*/
+   MMC_FIXUP("M8G2FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("MAG4FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("MBG8FA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("MCGAFA", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("VAL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("VYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("KYL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+   MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_MOVINAND_SECURE),
+
END_FIXUP
 };

diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 111aca5..b639a92 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -239,6 +239,7 @@ struct mmc_card {
 #define MMC_QUIRK_BLK_NO_CMD23 (1<<7)  /* Avoid CMD23 for regular
multiblock */
 #define MMC_QUIRK_BROKEN_BYTE_MODE_512 (1<<8)  /* Avoid sending 512
bytes in */
 #define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD 
says */
+#define MMC_QUIRK_SKIP_SECURE (1<<10)  /* Skip secure for erase/trim */
/* byte mode */
unsigned intpoweroff_notify_state;  /* eMMC4.5 notify feature */
 #define MMC_NO_POWER_NOTIFICATION  0
-- 
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH repost] kvm: drop parameter validation

[Gleb Natapov]

On Mon, Aug 13, 2012 at 05:59:32PM -0300, Marcelo Tosatti wrote:
> On Mon, Aug 13, 2012 at 05:30:53PM +0300, Gleb Natapov wrote:
> > On Mon, Aug 13, 2012 at 01:43:58PM +0300, Michael S. Tsirkin wrote:
> > > We validate irq pin number when routing is setup, so
> > > code handling illegal irq # in pic and ioapic on each injection
> > > is never called.
> > > Drop it.
> > > 
> > I would leave BUG_ON there for a while.
> 
> Which BUG_ON?
> 
I mean changing if() to BUG_ON().

BUG_ON (!(irq >= 0 && irq < PIC_NUM_PINS))

> > 
> > > Signed-off-by: Michael S. Tsirkin 
> > > ---
> > > 
> > > Reposting, applies without changes to kvm/next.
> > > 
> > >  arch/x86/kvm/i8259.c | 16 +++-
> > >  virt/kvm/ioapic.c| 35 +--
> > >  2 files changed, 24 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> > > index 1df8fb9..277ec0d 100644
> > > --- a/arch/x86/kvm/i8259.c
> > > +++ b/arch/x86/kvm/i8259.c
> > > @@ -190,17 +190,15 @@ void kvm_pic_update_irq(struct kvm_pic *s)
> > >  
> > >  int kvm_pic_set_irq(struct kvm_pic *s, int irq, int irq_source_id, int 
> > > level)
> > >  {
> > > - int ret = -1;
> > > + int ret, irq_level;
> > >  
> > >   pic_lock(s);
> > > - if (irq >= 0 && irq < PIC_NUM_PINS) {
> > > - int irq_level = __kvm_irq_line_state(>irq_states[irq],
> > > -  irq_source_id, level);
> > > - ret = pic_set_irq1(>pics[irq >> 3], irq & 7, irq_level);
> > > - pic_update_irq(s);
> > > - trace_kvm_pic_set_irq(irq >> 3, irq & 7, s->pics[irq >> 3].elcr,
> > > -   s->pics[irq >> 3].imr, ret == 0);
> > > - }
> > > + irq_level = __kvm_irq_line_state(>irq_states[irq],
> > > +  irq_source_id, level);
> > > + ret = pic_set_irq1(>pics[irq >> 3], irq & 7, irq_level);
> > > + pic_update_irq(s);
> > > + trace_kvm_pic_set_irq(irq >> 3, irq & 7, s->pics[irq >> 3].elcr,
> > > +   s->pics[irq >> 3].imr, ret == 0);
> > >   pic_unlock(s);
> > >  
> > >   return ret;
> > > diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> > > index ef61d52..4d824c7 100644
> > > --- a/virt/kvm/ioapic.c
> > > +++ b/virt/kvm/ioapic.c
> > > @@ -197,28 +197,27 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, 
> > > int irq, int irq_source_id,
> > >   u32 old_irr;
> > >   u32 mask = 1 << irq;
> > >   union kvm_ioapic_redirect_entry entry;
> > > - int ret = 1;
> > > + int ret, irq_level;
> > >  
> > >   spin_lock(>lock);
> > >   old_irr = ioapic->irr;
> > > - if (irq >= 0 && irq < IOAPIC_NUM_PINS) {
> > > - int irq_level = __kvm_irq_line_state(>irq_states[irq],
> > > -  irq_source_id, level);
> > > - entry = ioapic->redirtbl[irq];
> > > - irq_level ^= entry.fields.polarity;
> > > - if (!irq_level)
> > > - ioapic->irr &= ~mask;
> > > - else {
> > > - int edge = (entry.fields.trig_mode == IOAPIC_EDGE_TRIG);
> > > - ioapic->irr |= mask;
> > > - if ((edge && old_irr != ioapic->irr) ||
> > > - (!edge && !entry.fields.remote_irr))
> > > - ret = ioapic_service(ioapic, irq);
> > > - else
> > > - ret = 0; /* report coalesced interrupt */
> > > - }
> > > - trace_kvm_ioapic_set_irq(entry.bits, irq, ret == 0);
> > > + irq_level = __kvm_irq_line_state(>irq_states[irq],
> > > +  irq_source_id, level);
> > > + entry = ioapic->redirtbl[irq];
> > > + irq_level ^= entry.fields.polarity;
> > > + if (!irq_level) {
> > > + ioapic->irr &= ~mask;
> > > + ret = 1;
> > > + } else {
> > > + int edge = (entry.fields.trig_mode == IOAPIC_EDGE_TRIG);
> > > + ioapic->irr |= mask;
> > > + if ((edge && old_irr != ioapic->irr) ||
> > > + (!edge && !entry.fields.remote_irr))
> > > + ret = ioapic_service(ioapic, irq);
> > > + else
> > > + ret = 0; /* report coalesced interrupt */
> > >   }
> > > + trace_kvm_ioapic_set_irq(entry.bits, irq, ret == 0);
> > >   spin_unlock(>lock);
> > >  
> > >   return ret;
> > > -- 
> > > MST
> > 
> > --
> > Gleb.
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Gleb.
--
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: Tree for Aug 14

[Stephen Rothwell]

Hi all,

Changes since 20120813:

I have still reverted 3 commits from the signal tree at the request of the
arm maintainer.



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc,
sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 195 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (3bf671a Merge branch 'fixes-for-3.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds)
Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1)
Merging arm-current/fixes (730a812 ARM: 7489/1: errata: fix workaround for 
erratum #720789 on UP systems)
Merging m68k-current/for-linus (9e2760d m68k: Make sys_atomic_cmpxchg_32 work 
on classic m68k)
Merging powerpc-merge/merge (ad36cb0 powerpc/kvm/book3s_32: Fix MTMSR_EERI 
macro)
Merging sparc/master (a27032e sparc64: do not clobber personality flags in 
sys_sparc64_personality())
Merging net/master (f57b07c bnx2x: Fix compiler warnings)
Merging sound-current/for-linus (088c820 ALSA: hda - fix Copyright debug 
message)
Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging wireless/master (7dd6753 ath5k: fix spin_lock_irqsave/spin_lock_bh 
nesting in mesh)
Merging driver-core.current/driver-core-linus (0d7614f Linux 3.6-rc1)
Merging tty.current/tty-linus (7d9739c serial: ifx6x60: fix paging fault on 
spi_register_driver)
Merging usb.current/usb-linus (b1b552a usb: gadget: u_ether: fix kworker 100% 
CPU issue with still used interfaces in eth_stop)
Merging staging.current/staging-linus (a26f4dd staging: comedi: rtd520: 
ioremap'ed addresses are resource_size_t)
Merging char-misc.current/char-misc-linus (0d7614f Linux 3.6-rc1)
Merging input-current/for-linus (cf45b5a Merge branch 'next' into for-linus)
Merging md-current/for-linus (58e94ae md/raid1: close some possible races on 
write errors during resync)
Merging audit-current/for-linus (c158a35 audit: no leading space in 
audit_log_d_path prefix)
Merging crypto-current/master (76f16f8 crypto: hifn_795x - fix 64bit division 
and undefined __divdi3 on 32bit archs)
Merging ide/master (39a50b4 Merge branch 'hfsplus')
Merging dwmw2/master (244dc4e Merge 
git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to 
inline functions)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs 
formatting)
Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for 
of_parse_phandle_with_args)
Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using 
proper "spi:" modalias prefixes.)
Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, 
remove cast)
Merging arm/for-next (730a812 ARM: 7489/1: errata: fix workaround for erratum 
#720789 on UP systems)
Merging arm-perf/for-next/perf (dee8c1b ARM: perf: remove arm_perf_pmu_ids 
global enumeration)
Merging davinci/davinci-next (fe0d422 Linux 3.0-rc6)
Merging xilinx/arm-next (b85a3ef ARM: Xilinx: Adding Xilinx board suppo

Re: [PATCH] mmc: card: Skip secure option for MoviNAND.

[Namjae Jeon]

Hi. Ian.

Okay, I see. plz add this address in changelog.

I also agree about Linus's suggestion.
So Would you change flag name to be neutral ?
We can distinguish samsung movinand by CID_MANFID_SAMSUNG.
And will reuse quirk flag when same issue occurred from other vendor's
mmc deivce.

Thanks.

2012/8/14, IAN CHEN :
> Dear Mr. Jeon,
>
> This is workaround for some Samsung eMMC, MoviNAND.
> There are known issue about secure erase & secure trim with these eMMC
> device which I listed by product_name.
> Therefore, for these eMMC devices, we just skip
> mmc_blk_issue_secdiscard_rq() and use mmc_blk_issue_discard_rq() instead.
>
> You could refer this discussion in XDA developers.
> http://forum.xda-developers.com/showthread.php?t=1644364
>
> https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
>
> Regards,
> Ian
>
> -Original Message-
> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> Sent: Monday, August 13, 2012 10:03 PM
> To: IAN CHEN
> Cc: c...@laptop.org; adrian.hun...@intel.com; subha...@codeaurora.org;
> linus.wall...@linaro.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; d.j.s...@samsung.com;
> jongtae22@samsung.com; kyungmin.p...@samsung.com;
> jh80.ch...@samsung.com
> Subject: Re: [PATCH] mmc: card: Skip secure option for MoviNAND.
>
> Hi. Ian.
>
> known issue ? Would you explain more ?
>
> Thanks.
>
> 2012/8/13 IAN CHEN :
>> From 5c60eb8be04c7440d6e33b8f72ea2046a3657ac4 Mon Sep 17 00:00:00 2001
>> From: ian.cy.chen 
>> Date: Mon, 13 Aug 2012 10:53:55 +0900
>> Subject: [PATCH] mmc: card: Skip secure option for MoviNAND.
>>
>> For several MoviNAND, there are some known issue with secure option.
>> For these specific MoviNAND device, we skip secure option.
>>
>> Signed-off-by: Ian Chen 
>> ---
>>  drivers/mmc/card/block.c |   24 +++-
>>  include/linux/mmc/card.h |1 +
>>  2 files changed, 24 insertions(+), 1 deletions(-)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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: [PATCH v3 5/6] floppy: use disk_registered for checking if a drive is present

[Ben Hutchings]

On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> Simplify/cleanup code, replacing remaining checks for drives present
> using disk_registered array.
> 
> Acked-by: Vivek Goyal 
> Signed-off-by: Herton Ronaldo Krzesinski 
> ---
>  drivers/block/floppy.c |   10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index 3eafe93..381b9c1 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -4114,9 +4114,7 @@ static struct platform_device floppy_device[N_DRIVE];
>  static struct kobject *floppy_find(dev_t dev, int *part, void *data)
>  {
>   int drive = (*part & 3) | ((*part & 0x80) >> 5);
> - if (drive >= N_DRIVE ||
> - !(allowed_drive_mask & (1 << drive)) ||
> - fdc_state[FDC(drive)].version == FDC_NONE)
> + if (drive >= N_DRIVE || !disk_registered[drive])
>   return NULL;
>   if (((*part >> 2) & 0x1f) >= ARRAY_SIZE(floppy_type))
>   return NULL;
> @@ -4561,8 +4559,7 @@ static void __exit floppy_module_exit(void)
>   for (drive = 0; drive < N_DRIVE; drive++) {
>   del_timer_sync(_off_timer[drive]);
>  
> - if ((allowed_drive_mask & (1 << drive)) &&
> - fdc_state[FDC(drive)].version != FDC_NONE) {
> + if (disk_registered[drive]) {
>   del_gendisk(disks[drive]);
>   device_remove_file(_device[drive].dev, 
> _attr_cmos);
>   platform_device_unregister(_device[drive]);

The same function I suggested for 4/6 would also be used here.  A little
neater than yet another static array, I think.  But I have nothing to do
with this code so you could just ignore my preferences. :-)

Ben.

> @@ -4573,8 +4570,7 @@ static void __exit floppy_module_exit(void)
>* These disks have not called add_disk().  Don't put down
>* queue reference in put_disk().
>*/
> - if (!(allowed_drive_mask & (1 << drive)) ||
> - fdc_state[FDC(drive)].version == FDC_NONE)
> + if (!disk_registered[drive])
>   disks[drive]->queue = NULL;
>  
>   put_disk(disks[drive]);

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 4/6] floppy: properly handle failure on add_disk loop

[Ben Hutchings]

On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> On do_floppy_init, if something failed inside the loop we call add_disk,
> there was no cleanup of previous iterations in the error handling.
> 
> Cc: sta...@vger.kernel.org
> Acked-by: Vivek Goyal 
> Signed-off-by: Herton Ronaldo Krzesinski 

This depends on 3/6.  If that's replaced by my proposed fix, then:

> ---
>  drivers/block/floppy.c |   10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index 9272203..3eafe93 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -4294,7 +4294,7 @@ static int __init do_floppy_init(void)
>  
>   err = platform_device_register(_device[drive]);
>   if (err)
> - goto out_release_dma;
> + goto out_remove_drives;
>  
>   err = device_create_file(_device[drive].dev,
>_attr_cmos);
> @@ -4313,6 +4313,14 @@ static int __init do_floppy_init(void)
>  
>  out_unreg_platform_dev:
>   platform_device_unregister(_device[drive]);
> +out_remove_drives:
> + while (drive--) {
> + if (disk_registered[drive]) {

I think the test of allowed_drive_mask and FDC version before
registering each driver should be factored out into a function that you
can use here.  There would then no need for the disk_registered array.

Ben.

> + del_gendisk(disks[drive]);
> + device_remove_file(_device[drive].dev, 
> _attr_cmos);
> + platform_device_unregister(_device[drive]);
> + }
> + }
>  out_release_dma:
>   if (atomic_read(_count))
>   floppy_release_irq_and_dma();

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 3/6] floppy: avoid leaking extra reference to queue on do_floppy_init error handling

[Ben Hutchings]

On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> After commit 3f9a5aa ("floppy: Cleanup disk->queue before caling
> put_disk() if add_disk() was never called"), if something fails in the
> add_disk loop, we unconditionally set disks[dr]->queue to NULL. But
> that's wrong, since we may have succesfully done an add_disk on some of
> the drives previously in the loop, and in this case we would end up with
> an extra reference to the disks[dr]->queue.
> 
> Add a new global array to mark "registered" disks, and use that to check
> if we did an add_disk on one of the disks already. Using an array to
> track added disks also will help to simplify/cleanup code later, as
> suggested by Vivek Goyal.
[...]

It's totally ridiculous that a driver should have to do this.  Any
registered disk should have the GENHD_FL_UP flag set... so why can't
genhd check it?  It doesn't look like floppy is the only driver affected
by this problem, either.  So I suggest the following general fix
(untested):

---
Subject: genhd: Make put_disk() safe for disks that have not been registered

Since commit 9f53d2f ('block: fix __blkdev_get and add_disk race
condition'), add_disk() adds a reference to disk->queue, which is then
dropped by disk_release().  But if a disk is destroyed without being
registered through add_disk() (or if add_disk() fails at the first
hurdle) then we have a reference imbalance.

Use the GENHD_FL_UP flag to tell whether this extra reference has been
added.  Remove the incomplete workaround from the floppy driver.

Signed-off-by: Ben Hutchings 
Cc: sta...@vger.kernel.org
---
 block/genhd.c  |6 +++---
 drivers/block/floppy.c |   16 +---
 2 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index cac7366..6201212 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -587,8 +587,6 @@ void add_disk(struct gendisk *disk)
WARN_ON(disk->minors && !(disk->major || disk->first_minor));
WARN_ON(!disk->minors && !(disk->flags & GENHD_FL_EXT_DEVT));
 
-   disk->flags |= GENHD_FL_UP;
-
retval = blk_alloc_devt(>part0, );
if (retval) {
WARN_ON(1);
@@ -596,6 +594,8 @@ void add_disk(struct gendisk *disk)
}
disk_to_dev(disk)->devt = devt;
 
+   disk->flags |= GENHD_FL_UP;
+
/* ->major and ->first_minor aren't supposed to be
 * dereferenced from here on, but set them just in case.
 */
@@ -1105,7 +1105,7 @@ static void disk_release(struct device *dev)
disk_replace_part_tbl(disk, NULL);
free_part_stats(>part0);
free_part_info(>part0);
-   if (disk->queue)
+   if (disk->queue && disk->flags & GENHD_FL_UP)
blk_put_queue(disk->queue);
kfree(disk);
 }
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index a7d6347..cf27922 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4325,14 +4325,8 @@ out_unreg_blkdev:
 out_put_disk:
while (dr--) {
del_timer_sync(_off_timer[dr]);
-   if (disks[dr]->queue) {
+   if (disks[dr]->queue)
blk_cleanup_queue(disks[dr]->queue);
-   /*
-* put_disk() is not paired with add_disk() and
-* will put queue reference one extra time. fix it.
-*/
-   disks[dr]->queue = NULL;
-   }
put_disk(disks[dr]);
}
return err;
@@ -4560,14 +4554,6 @@ static void __exit floppy_module_exit(void)
}
blk_cleanup_queue(disks[drive]->queue);
 
-   /*
-* These disks have not called add_disk().  Don't put down
-* queue reference in put_disk().
-*/
-   if (!(allowed_drive_mask & (1 << drive)) ||
-   fdc_state[FDC(drive)].version == FDC_NONE)
-   disks[drive]->queue = NULL;
-
put_disk(disks[drive]);
}
 


-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

RE: [PATCH V2 18/18] Tools: hv: Properly manage open streams

[KY Srinivasan]

> -Original Message-
> From: Ben Hutchings [mailto:b...@decadent.org.uk]
> Sent: Monday, August 13, 2012 9:58 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com
> Subject: Re: [PATCH V2 18/18] Tools: hv: Properly manage open streams
> 
> On Mon, 2012-08-13 at 10:07 -0700, K. Y. Srinivasan wrote:
> > Close the open streams properly.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > Reviewed-by: Olaf Hering 
> > Reviewed-by: Ben Hutchings 
> 
> This isn't reviewed by me, I'm the author!

I am truly sorry for this confusion. I was cleaning up the code based on the
last set of comments I got from Olaf and I did not realize that you had authored
this very patch! Perhaps we can drop this patch from this set.

Regards,

K. Y


> 
> Ben.
> 
> > ---
> >  tools/hv/hv_kvp_daemon.c |4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> > index c8e1013..ca6424f 100644
> > --- a/tools/hv/hv_kvp_daemon.c
> > +++ b/tools/hv/hv_kvp_daemon.c
> > @@ -160,7 +160,7 @@ static void kvp_update_file(int pool)
> > sizeof(struct kvp_record),
> > kvp_file_info[pool].num_records, filep);
> >
> > -   fflush(filep);
> > +   fclose(filep);
> > kvp_release_lock(pool);
> >  }
> >
> > @@ -206,7 +206,7 @@ static void kvp_update_mem_state(int pool)
> > kvp_file_info[pool].num_blocks = num_blocks;
> > kvp_file_info[pool].records = record;
> > kvp_file_info[pool].num_records = records_read;
> > -
> > +   fclose(filep);
> > kvp_release_lock(pool);
> >  }
> >  static int kvp_file_init(void)
> 
> --
> Ben Hutchings
> I say we take off; nuke the site from orbit.  It's the only way to be sure.

Re: [GIT PULL] Update LZO compression

[Andi Kleen]

On Tue, Aug 14, 2012 at 01:44:02AM +0200, Markus F.X.J. Oberhumer wrote:
> Hi all,
> 
> as suggested on the mailing list I have converted the updated LZO
> code into git, so please pull my "lzo-update" branch from
> 
>   git://github.com/markus-oberhumer/linux.git lzo-update
> 
> You can browse the branch at
> 
>   https://github.com/markus-oberhumer/linux/compare/lzo-update

Looks ok to me from a quick look.

Since kernel lzo is security relevant, I assume the new version
has been fuzz tested?

I couldn't tell from the github view, but I assume you follow
standard coding style.

-Andi
--
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 02/18] Drivers: hv: Add KVP definitions for IP address injection

[KY Srinivasan]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Monday, August 13, 2012 9:38 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org;
> virtualizat...@lists.osdl.org; o...@aepfle.de; a...@canonical.com;
> b...@decadent.org.uk
> Subject: Re: [PATCH V2 02/18] Drivers: hv: Add KVP definitions for IP address
> injection
> 
> On Mon, Aug 13, 2012 at 10:06:51AM -0700, K. Y. Srinivasan wrote:
> > Add the necessary definitions for supporting the IP injection functionality.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > Reviewed-by: Olaf Hering 
> > Reviewed-by: Ben Hutchings 
> > ---
> >  drivers/hv/hv_util.c |4 +-
> >  include/linux/hyperv.h   |   76
> -
> >  tools/hv/hv_kvp_daemon.c |2 +-
> >  3 files changed, 77 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> > index d3ac6a4..a0667de 100644
> > --- a/drivers/hv/hv_util.c
> > +++ b/drivers/hv/hv_util.c
> > @@ -263,7 +263,7 @@ static int util_probe(struct hv_device *dev,
> > (struct hv_util_service *)dev_id->driver_data;
> > int ret;
> >
> > -   srv->recv_buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> > +   srv->recv_buffer = kmalloc(PAGE_SIZE * 2, GFP_KERNEL);
> > if (!srv->recv_buffer)
> > return -ENOMEM;
> > if (srv->util_init) {
> > @@ -274,7 +274,7 @@ static int util_probe(struct hv_device *dev,
> > }
> > }
> >
> > -   ret = vmbus_open(dev->channel, 2 * PAGE_SIZE, 2 * PAGE_SIZE, NULL,
> 0,
> > +   ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL,
> 0,
> > srv->util_cb, dev->channel);
> > if (ret)
> > goto error;
> > diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> > index 68ed7f7..11afc4e 100644
> > --- a/include/linux/hyperv.h
> > +++ b/include/linux/hyperv.h
> > @@ -122,12 +122,53 @@
> >  #define REG_U32 4
> >  #define REG_U64 8
> >
> > +/*
> > + * As we look at expanding the KVP functionality to include
> > + * IP injection functionality, we need to maintain binary
> > + * compatibility with older daemons.
> > + *
> > + * The KVP opcodes are defined by the host and it was unfortunate
> > + * that I chose to treat the registration operation as part of the
> > + * KVP operations defined by the host.
> > + * Here is the level of compatibility
> > + * (between the user level daemon and the kernel KVP driver) that we
> > + * will implement:
> > + *
> > + * An older daemon will always be supported on a newer driver.
> > + * A given user level daemon will require a minimal version of the
> > + * kernel driver.
> > + * If we cannot handle the version differences, we will fail gracefully
> > + * (this can happen when we have a user level daemon that is more
> > + * advanced than the KVP driver.
> > + *
> > + * We will use values used in this handshake for determining if we have
> > + * workable user level daemon and the kernel driver. We begin by taking the
> > + * registration opcode out of the KVP opcode namespace. We will however,
> > + * maintain compatibility with the existing user-level daemon code.
> > + */
> > +
> > +/*
> > + * Daemon code not supporting IP injection (legacy daemon).
> > + */
> > +
> > +#define KVP_OP_REGISTER4
> 
> Huh?
> 
> > +/*
> > + * Daemon code supporting IP injection.
> > + * The KVP opcode field is used to communicate the
> > + * registration information; so define a namespace that
> > + * will be distinct from the host defined KVP opcode.
> > + */
> > +
> > +#define KVP_OP_REGISTER1 100
> > +
> >  enum hv_kvp_exchg_op {
> > KVP_OP_GET = 0,
> > KVP_OP_SET,
> > KVP_OP_DELETE,
> > KVP_OP_ENUMERATE,
> > -   KVP_OP_REGISTER,
> > +   KVP_OP_GET_IP_INFO,
> > +   KVP_OP_SET_IP_INFO,
> 
> So you overloaded the command and somehow think that is ok?  How is that
> supposed to work?  Why not just always keep it there, but fail if it is
> called as you know you have a mismatch?
> 
> Otherwise, again, you just broke older tools on a newer kernel.
> 
> Or am I missing something here?

Greg,

The registration operation occurs when the daemon first starts up. I should 
have established
a distinct namespace for the daemon versions that would not overlap with the 
host
defined KVP operations initially. Unfortunately when I first implemented KVP, I 
did not know
about the new KVP verbs and so selected a value that ended up colliding with 
the new KVP 
operations. To maintain compatibility with older daemons, I have to support 
this old registration 
value, which is what you are seeing here. Since the initial driver/daemon 
handshake phase does
not overlap with the normal functioning of the KVP stack, we can use the old 
daemon 
registration value to distinguish that the daemon does not support IP 
injection. The current
implementation does support a compatible environment for older daemons.

Regards,

K. Y 

Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs

[Alex Williamson]

On Tue, 2012-08-14 at 02:00 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 04:41:05PM -0600, Alex Williamson wrote:
> > On Tue, 2012-08-14 at 01:06 +0300, Michael S. Tsirkin wrote:
> > > On Mon, Aug 13, 2012 at 03:34:01PM -0600, Alex Williamson wrote:
> > > > On Sun, 2012-08-12 at 11:36 +0300, Avi Kivity wrote:
> > > > > On 08/09/2012 10:26 PM, Alex Williamson wrote:
> > > > > > On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
> > > > > >> On 08/06/2012 01:38 PM, Avi Kivity wrote:
> > > > > >> 
> > > > > >> > Regarding the implementation, instead of a linked list, would an 
> > > > > >> > array
> > > > > >> > of counters parallel to the bitmap make it simpler?
> > > > > >> 
> > > > > >> Or even, replace the bitmap with an array of counters.
> > > > > > 
> > > > > > I'm not sure a counter array is what we're really after.  That 
> > > > > > gives us
> > > > > > reference counting for the irq source IDs, but not the key->gsi 
> > > > > > lookup.
> > > > > 
> > > > > You can look up the gsi while registering the eoifd, so it's 
> > > > > accessible
> > > > > as eoifd->gsi instead of eoifd->source->gsi.  The irqfd can go away
> > > > > while the eoifd is still active, but is this a problem?
> > > > 
> > > > In my opinion, no, but Michael disagrees.
> > > > 
> > > > > > It also highlights another issue, that we have a limited set of 
> > > > > > source
> > > > > > IDs.  Looks like we have BITS_PER_LONG IDs, with two already used, 
> > > > > > one
> > > > > > for the shared userspace ID and another for the PIT.  How happy are 
> > > > > > we
> > > > > > going to be with a limit of 62 level interrupts in use at one time?
> > > > > 
> > > > > When we start being unhappy we can increase that number.  On the other
> > > > > hand more locks and lists makes me unhappy now.
> > > > 
> > > > Yep, good point.  My latest version removes the source ID object lock
> > > > and list (and objects).  I still have a lock and list for the ack
> > > > notification, but it's hard not to unless we combine them into one
> > > > mega-irqfd ioctl as Michael suggests.
> > > >
> > > > > > It's arguably a reasonable number since the most virtualization 
> > > > > > friendly
> > > > > > devices (sr-iov VFs) don't even support this kind of interrupt.  
> > > > > > It's
> > > > > > also very wasteful allocating an entire source ID for a single GSI
> > > > > > within that source ID.  PCI supports interrupts A, B, C, and D, 
> > > > > > which,
> > > > > > in the most optimal config, each go to different GSIs.  So we could
> > > > > > theoretically be more efficient in our use and allocation of irq 
> > > > > > source
> > > > > > IDs if we tracked use by the source ID, gsi pair.
> > > > > 
> > > > > There are, in one userspace, just three gsis available for PCI links, 
> > > > > so
> > > > > you're compressing the source id space by 3.
> > > > 
> > > > I imagine there's a way to put each PCI interrupt pin on a GSI, but
> > > > still only 4, not a great expansion of source ID space.  I like
> > > > Michael's idea of re-using source IDs if we run out better.
> > > > 
> > > > > > That probably makes it less practical to replace anything at the top
> > > > > > level with a counter array.  The key that we pass back is currently 
> > > > > > the
> > > > > > actual source ID, but we don't specify what it is, so we could 
> > > > > > split it
> > > > > > and have it encode a 16bit source ID plus 16 bit GSI.  It could 
> > > > > > also be
> > > > > > an idr entry.
> > > > > 
> > > > > We can fix those kinds of problems by adding another layer of
> > > > > indirection.  But I doubt they will be needed.  I don't see people
> > > > > assigning 60 legacy devices to one guest.
> > > > 
> > > > Yep, we can ignore it for now and put it in the hands of userspace to
> > > > re-use IDs if needed.
> > > > 
> > > > > > Michael, would the interface be more acceptable to you if we added
> > > > > > separate ioctls to allocate and free some representation of an irq
> > > > > > source ID, gsi pair?  For instance, an ioctl might return an idr 
> > > > > > entry
> > > > > > for an irq source ID/gsi object which would then be passed as a
> > > > > > parameter in struct kvm_irqfd and struct kvm_eoifd so that the 
> > > > > > object
> > > > > > representing the source id/gsi isn't magically freed on it's own.  
> > > > > > This
> > > > > > would also allow us to deassign/close one end and reconfigure it 
> > > > > > later.
> > > > > > Thanks,
> > > > > 
> > > > > Another option is to push the responsibility for allocating IDs for 
> > > > > the
> > > > > association to userspace.  Let userspace both create the irqfd and the
> > > > > eoifd with the same ID, the kernel matches them at registration time 
> > > > > and
> > > > > copies the gsi/sourceid from the first to the second eventfd.
> > > > 
> > > > Aside from the copying gsi/sourceid bit, you've just described my latest
> > > > attempt at this series.  Specifying both a sourceid and gsi also allows
> > 

RE: [PATCH V2 06/18] Tools: hv: Further refactor kvp_get_ip_address()

[KY Srinivasan]

> -Original Message-
> From: Ben Hutchings [mailto:b...@decadent.org.uk]
> Sent: Monday, August 13, 2012 9:46 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; virtualizat...@lists.osdl.org; o...@aepfle.de;
> a...@canonical.com
> Subject: Re: [PATCH V2 06/18] Tools: hv: Further refactor kvp_get_ip_address()
> 
> On Mon, 2012-08-13 at 10:06 -0700, K. Y. Srinivasan wrote:
> > In preparation for making kvp_get_ip_address() more generic, factor out
> > the code for handling IP addresses.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-by: Haiyang Zhang 
> > Reviewed-by: Olaf Hering 
> > Reviewed-by: Ben Hutchings 
> 
> I looked at your last patch set, so in a sense these have been reviewed
> by me.  But the 'Reviewed-by' line in a commit message means the
> reviewer thinks it's OK; the reviewer must say that, and I didn't.

My mistake, sorry about that.

Regards,

K. Y

Re: [net PATCH v1 2/2] net: netprio: fd passed in SCM_RIGHTS datagram not set correctly

[John Fastabend]

On 8/13/2012 7:31 PM, Al Viro wrote:

On Mon, Aug 13, 2012 at 06:39:45PM -0700, John Fastabend wrote:

/* Bump the usage count and install the file. */
get_file(fp[i]);
fd_install(new_fd, fp[i]);
+   sock = sock_from_file(fp[i], );
+   if (sock)
+   sock->sk->sk_cgrp_prioidx = prioidx;


Better to do that before fd_install() exposes the sucker; it's not
a serious issue, but it's more obviously correct that way.



Right. Moved it in v2.
--
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: [net PATCH v1 1/2] net: netprio: fix files lock and remove useless d_path bits

[John Fastabend]

On 8/13/2012 7:29 PM, Al Viro wrote:

On Mon, Aug 13, 2012 at 06:39:39PM -0700, John Fastabend wrote:

-   path = d_path(>f_path, tmp, PAGE_SIZE);


What's using tmp after that patch and do you still need to bother
allocating it?



nothing removed it in v2.
--
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/

[net PATCH v2 2/2] net: netprio: fd passed in SCM_RIGHTS datagram not set correctly

[John Fastabend]

A socket fd passed in a SCM_RIGHTS datagram was not getting
updated with the new tasks cgrp prioidx. This leaves IO on
the socket tagged with the old tasks priority.

To fix this add a check in the scm recvmsg path to update the
sock cgrp prioidx with the new tasks value.

Thanks to Al Viro for catching this.

CC: Neil Horman 
Reported-by: Al Viro 
Signed-off-by: John Fastabend 
---

 net/core/scm.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/net/core/scm.c b/net/core/scm.c
index 8f6ccfd..a14d9e2 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -249,6 +249,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie 
*scm)
struct file **fp = scm->fp->fp;
int __user *cmfptr;
int err = 0, i;
+   __u32 prioidx = task_netprioidx(current);
 
if (MSG_CMSG_COMPAT & msg->msg_flags) {
scm_detach_fds_compat(msg, scm);
@@ -265,6 +266,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie 
*scm)
for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); isk->sk_cgrp_prioidx = prioidx;
fd_install(new_fd, fp[i]);
}
 

--
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/

[net PATCH v2 1/2] net: netprio: fix files lock and remove useless d_path bits

[John Fastabend]

Add lock to prevent a race with a file closing and also remove
useless and ugly sscanf code. The extra code was never needed
and the case it supposedly protected against is in fact handled
correctly by sock_from_file as pointed out by Al Viro.

CC: Neil Horman 
Reported-by: Al Viro 
Signed-off-by: John Fastabend 
---

 net/core/netprio_cgroup.c |   22 --
 1 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index ed0c043..f65dba3 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -277,12 +277,6 @@ out_free_devname:
 void net_prio_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
 {
struct task_struct *p;
-   char *tmp = kzalloc(sizeof(char) * PATH_MAX, GFP_KERNEL);
-
-   if (!tmp) {
-   pr_warn("Unable to attach cgrp due to alloc failure!\n");
-   return;
-   }
 
cgroup_taskset_for_each(p, cgrp, tset) {
unsigned int fd;
@@ -296,32 +290,24 @@ void net_prio_attach(struct cgroup *cgrp, struct 
cgroup_taskset *tset)
continue;
}
 
-   rcu_read_lock();
+   spin_lock(>file_lock);
fdt = files_fdtable(files);
for (fd = 0; fd < fdt->max_fds; fd++) {
-   char *path;
struct file *file;
struct socket *sock;
-   unsigned long s;
-   int rv, err = 0;
+   int err;
 
file = fcheck_files(files, fd);
if (!file)
continue;
 
-   path = d_path(>f_path, tmp, PAGE_SIZE);
-   rv = sscanf(path, "socket:[%lu]", );
-   if (rv <= 0)
-   continue;
-
sock = sock_from_file(file, );
-   if (!err)
+   if (sock)
sock_update_netprioidx(sock->sk, p);
}
-   rcu_read_unlock();
+   spin_unlock(>file_lock);
task_unlock(p);
}
-   kfree(tmp);
 }
 
 static struct cftype ss_files[] = {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/12] KVM: introduce readonly memslot

[Xiao Guangrong]

On 08/14/2012 01:39 AM, Marcelo Tosatti wrote:
> On Sat, Aug 11, 2012 at 11:36:20AM +0800, Xiao Guangrong wrote:
>> On 08/11/2012 02:14 AM, Marcelo Tosatti wrote:
>>> On Tue, Aug 07, 2012 at 05:47:15PM +0800, Xiao Guangrong wrote:
 Changelog:
 - introduce KVM_PFN_ERR_RO_FAULT instead of dummy page
 - introduce KVM_HVA_ERR_BAD and optimize error hva indicators

 The test case can be found at:
 http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/00819/migrate-perf.tar.bz2

 In current code, if we map a readonly memory space from host to guest
 and the page is not currently mapped in the host, we will get a fault-pfn
 and async is not allowed, then the vm will crash.

 As Avi's suggestion, We introduce readonly memory region to map ROM/ROMD
 to the guest, read access is happy for readonly memslot, write access on
 readonly memslot will cause KVM_EXIT_MMIO exit.
>>>
>>> Memory slots whose QEMU mapping is write protected is supported
>>> today, as long as there are no write faults.
>>>
>>> What prevents the use of mmap(!MAP_WRITE) to handle read-only memslots
>>> again?
>>>
>>
>> It is happy to map !write host memory space to the readonly memslot,
>> and they can coexist as well.
>>
>> readonly memslot checks the write-permission by seeing slot->flags and
>> !write memory checks the write-permission in hva_to_pfn() function
>> which checks vma->flags. It is no conflict.
> 
> Yes, there is no conflict. The point is, if you can use the
> mmap(PROT_READ) interface (supporting read faults on read-only slots)
> for this behavior, what is the advantage of a new memslot flag?
> 

You can get the discussion at:
https://lkml.org/lkml/2012/5/22/228

> I'm not saying mmap(PROT_READ) is the best interface, i am just asking
> why it is not.

My fault. :(

> 
>>> The initial objective was to fix a vm crash, can you explain that
>>> initial problem?
>>>
>>
>> The issue was trigged by this code:
>>
>> } else {
>> if (async && (vma->vm_flags & VM_WRITE))
>> *async = true;
>> pfn = KVM_PFN_ERR_FAULT;
>> }
>>
>> If the host memory region is readonly (!vma->vm_flags & VM_WRITE) and
>> its physical page is swapped out (or the file data does not be read in),
>> get_user_page_nowait will fail, above code reject to set async,
>> then we will get a fault pfn and async=false.
>>
>> I guess this issue also exists in "QEMU write protected mapping" as
>> you mentioned above.
> 
> Yes, it does. As far as i understand, what that check does from a high
> level pov is:
> 
> - Did get_user_pages_nowait() fail due to a swapped out page (in which 
> case we should try to swappin the page asynchronously), or due to 
> another reason (for which case an error should be returned).
> 
> Using vma->vm_flags VM_WRITE for that is trying to guess why
> get_user_pages_nowait() failed, because it (gup_nowait return values) 
> does not provide sufficient information by itself.
> 

That is exactly what i did in the first version. :)

You can see it and the reason why it switched to the new way (readonly memslot)
in the above website (the first message in thread).

> Can't that be fixed separately? 
> 
> Another issue which is also present with the mmap(PROT_READ) scheme is
> interaction with reexecute_instruction. That is, unless i am mistaken,
> reexecute_instruction can succeed (return true) on a region that is
> write protected. This breaks the "write faults on read-only slots exit
> to userspace via EXIT_MMIO" behaviour.

Sorry, Why? After re-entry to the guest, it can not generate a correct MMIO?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] zram/zsmalloc promotion

[Greg Kroah-Hartman]

On Wed, Aug 08, 2012 at 03:12:13PM +0900, Minchan Kim wrote:
> This patchset promotes zram/zsmalloc from staging.
> Both are very clean and zram is used by many embedded product
> for a long time.
> 
> [1-3] are patches not merged into linux-next yet but needed
> it as base for [4-5] which promotes zsmalloc.
> Greg, if you merged [1-3] already, skip them.

I've applied 1-3 and now 4, but that's it, I can't apply the rest
without getting acks from the -mm maintainers, sorry.  Please work with
them to get those acks, and then I will be glad to apply the rest (after
you resend them of course...)

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 v2 3/3] rtc: add new lp8788 rtc driver

[Kim, Milo]

Patch v2.

(a) use irq domain for handling alarm IRQ
(b) replace module_init() and module_exit() with module_platform_driver()
(c) clean up code for _probe() and _remove()

Signed-off-by: Milo(Woogyom) Kim 
---
 drivers/rtc/Kconfig  |6 +
 drivers/rtc/Makefile |1 +
 drivers/rtc/rtc-lp8788.c |  339 ++
 3 files changed, 346 insertions(+), 0 deletions(-)
 create mode 100644 drivers/rtc/rtc-lp8788.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index fabc99a..c2b26f7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -194,6 +194,12 @@ config RTC_DRV_DS3232
  This driver can also be built as a module.  If so, the module
  will be called rtc-ds3232.
 
+config RTC_DRV_LP8788
+   tristate "TI LP8788 RTC driver"
+   depends on MFD_LP8788
+   help
+ Say Y to enable support for the LP8788 RTC/ALARM driver.
+
 config RTC_DRV_MAX6900
tristate "Maxim MAX6900"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 0d5b2b6..eba0393 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_RTC_DRV_IMXDI)   += rtc-imxdi.o
 obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
 obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
 obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
+obj-$(CONFIG_RTC_DRV_LP8788)   += rtc-lp8788.o
 obj-$(CONFIG_RTC_DRV_LPC32XX)  += rtc-lpc32xx.o
 obj-$(CONFIG_RTC_DRV_LOONGSON1)+= rtc-ls1x.o
 obj-$(CONFIG_RTC_DRV_M41T80)   += rtc-m41t80.o
diff --git a/drivers/rtc/rtc-lp8788.c b/drivers/rtc/rtc-lp8788.c
new file mode 100644
index 000..7f22e73
--- /dev/null
+++ b/drivers/rtc/rtc-lp8788.c
@@ -0,0 +1,339 @@
+/*
+ * TI LP8788 MFD - rtc driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register address */
+#define LP8788_INTEN_3 0x05
+#define LP8788_RTC_UNLOCK  0x64
+#define LP8788_RTC_SEC 0x70
+#define LP8788_ALM1_SEC0x77
+#define LP8788_ALM1_EN 0x7D
+#define LP8788_ALM2_SEC0x7E
+#define LP8788_ALM2_EN 0x84
+
+/* mask/shift bits */
+#define LP8788_INT_RTC_ALM1_M  BIT(1)  /* Addr 05h */
+#define LP8788_INT_RTC_ALM1_S  1
+#define LP8788_INT_RTC_ALM2_M  BIT(2)  /* Addr 05h */
+#define LP8788_INT_RTC_ALM2_S  2
+#define LP8788_ALM_EN_MBIT(7)  /* Addr 7Dh or 84h */
+#define LP8788_ALM_EN_S7
+
+#define DEFAULT_ALARM_SEL  LP8788_ALARM_1
+#define LP8788_MONTH_OFFSET1
+#define LP8788_BASE_YEAR   2000
+#define MAX_WDAY_BITS  7
+#define RTC_UNLOCK 0x1
+#define RTC_LATCH  0x2
+#define ALARM_IRQ_FLAG (RTC_IRQF | RTC_AF)
+
+enum lp8788_time {
+   LPTIME_SEC,
+   LPTIME_MIN,
+   LPTIME_HOUR,
+   LPTIME_MDAY,
+   LPTIME_MON,
+   LPTIME_YEAR,
+   LPTIME_WDAY,
+   LPTIME_MAX,
+};
+
+struct lp8788_rtc {
+   struct lp8788 *lp;
+   struct rtc_device *rdev;
+   enum lp8788_alarm_sel alarm;
+   int irq;
+};
+
+static const u8 addr_alarm_sec[LP8788_ALARM_MAX] = {
+   LP8788_ALM1_SEC,
+   LP8788_ALM2_SEC,
+};
+
+static const u8 addr_alarm_en[LP8788_ALARM_MAX] = {
+   LP8788_ALM1_EN,
+   LP8788_ALM2_EN,
+};
+
+static const u8 mask_alarm_en[LP8788_ALARM_MAX] = {
+   LP8788_INT_RTC_ALM1_M,
+   LP8788_INT_RTC_ALM2_M,
+};
+
+static const u8 shift_alarm_en[LP8788_ALARM_MAX] = {
+   LP8788_INT_RTC_ALM1_S,
+   LP8788_INT_RTC_ALM2_S,
+};
+
+static int _to_tm_wday(u8 lp8788_wday)
+{
+   int i;
+
+   if (lp8788_wday == 0)
+   return 0;
+
+   for (i = 0 ; i < MAX_WDAY_BITS ; i++) {
+   if ((lp8788_wday >> i) == 0x01)
+   break;
+   }
+
+   return i + 1;
+}
+
+static inline int _to_lp8788_wday(int tm_wday)
+{
+   return 1 << (tm_wday - 1);
+}
+
+static void lp8788_rtc_unlock(struct lp8788 *lp)
+{
+   lp8788_write_byte(lp, LP8788_RTC_UNLOCK, RTC_UNLOCK);
+   lp8788_write_byte(lp, LP8788_RTC_UNLOCK, RTC_LATCH);
+}
+
+static int lp8788_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+   struct lp8788_rtc *rtc = dev_get_drvdata(dev);
+   struct lp8788 *lp = rtc->lp;
+   u8 data[LPTIME_MAX];
+   int ret;
+
+   lp8788_rtc_unlock(lp);
+
+   ret = lp8788_read_multi_bytes(lp, LP8788_RTC_SEC, data, LPTIME_MAX);
+   if (ret)
+   return ret;
+
+   tm->tm_sec  = data[LPTIME_SEC];
+   tm->tm_min  = data[LPTIME_MIN];
+   tm->tm_hour = 

[PATCH v3 2/3] power_supply: add new lp8788 charger driver

[Kim, Milo]

Patch v3.

(a) use irq domain for handling charger interrupts
(b) use scaled adc value rather than raw value
: replace iio_read_channel_raw() with iio_read_channel_scale()
(c) clean up charger-platform-data code
(d) remove goto statement in _probe()
(e) name change : from lp8788_unregister_psy() to lp8788_psy_unregister()

Signed-off-by: Milo(Woogyom) Kim 
---
 drivers/power/Kconfig  |7 +
 drivers/power/Makefile |1 +
 drivers/power/lp8788-charger.c |  785 
 3 files changed, 793 insertions(+), 0 deletions(-)
 create mode 100644 drivers/power/lp8788-charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index c1892f3..ff86469 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -255,6 +255,13 @@ config CHARGER_LP8727
help
  Say Y here to enable support for LP8727 Charger Driver.
 
+config CHARGER_LP8788
+   tristate "TI LP8788 charger driver"
+   depends on MFD_LP8788
+   depends on LP8788_ADC
+   help
+ Say Y to enable support for the LP8788 linear charger.
+
 config CHARGER_GPIO
tristate "GPIO charger"
depends on GPIOLIB
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ee58afb..587c5f1 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_CHARGER_ISP1704) += isp1704_charger.o
 obj-$(CONFIG_CHARGER_MAX8903)  += max8903_charger.o
 obj-$(CONFIG_CHARGER_TWL4030)  += twl4030_charger.o
 obj-$(CONFIG_CHARGER_LP8727)   += lp8727_charger.o
+obj-$(CONFIG_CHARGER_LP8788)   += lp8788-charger.o
 obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
 obj-$(CONFIG_CHARGER_MANAGER)  += charger-manager.o
 obj-$(CONFIG_CHARGER_MAX8997)  += max8997_charger.o
diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
new file mode 100644
index 000..a874eff
--- /dev/null
+++ b/drivers/power/lp8788-charger.c
@@ -0,0 +1,785 @@
+/*
+ * TI LP8788 MFD - battery charger driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register address */
+#define LP8788_CHG_STATUS  0x07
+#define LP8788_CHG_IDCIN   0x13
+#define LP8788_CHG_IBATT   0x14
+#define LP8788_CHG_VTERM   0x15
+#define LP8788_CHG_EOC 0x16
+
+/* mask/shift bits */
+#define LP8788_CHG_INPUT_STATE_M   0x03/* Addr 07h */
+#define LP8788_CHG_STATE_M 0x3C
+#define LP8788_CHG_STATE_S 2
+#define LP8788_NO_BATT_M   BIT(6)
+#define LP8788_BAD_BATT_M  BIT(7)
+#define LP8788_CHG_IBATT_M 0x1F/* Addr 14h */
+#define LP8788_CHG_VTERM_M 0x0F/* Addr 15h */
+#define LP8788_CHG_EOC_LEVEL_M 0x30/* Addr 16h */
+#define LP8788_CHG_EOC_LEVEL_S 4
+#define LP8788_CHG_EOC_TIME_M  0x0E
+#define LP8788_CHG_EOC_TIME_S  1
+#define LP8788_CHG_EOC_MODE_M  BIT(0)
+
+#define CHARGER_NAME   "charger"
+#define BATTERY_NAME   "main_batt"
+
+#define LP8788_CHG_START   0x11
+#define LP8788_CHG_END 0x1C
+
+#define BUF_SIZE   40
+#define LP8788_ISEL_MAX23
+#define LP8788_ISEL_STEP   50
+#define LP8788_VTERM_MIN   4100
+#define LP8788_VTERM_STEP  25
+#define MAX_BATT_CAPACITY  100
+#define MAX_CHG_IRQS   11
+
+enum lp8788_charging_state {
+   OFF,
+   WARM_UP,
+   LOW_INPUT = 0x3,
+   PRECHARGE,
+   CC,
+   CV,
+   MAINTENANCE,
+   BATTERY_FAULT,
+   SYSTEM_SUPPORT = 0xC,
+   HIGH_CURRENT = 0xF,
+   MAX_CHG_STATE,
+};
+
+enum lp8788_charger_adc_sel {
+   VBATT,
+   BATT_TEMP,
+   NUM_CHG_ADC,
+};
+
+enum lp8788_charger_input_state {
+   SYSTEM_SUPPLY = 1,
+   FULL_FUNCTION,
+};
+
+/*
+ * struct lp8788_chg_irq
+ * @which: lp8788 interrupt id
+ * @virq : Linux IRQ number from irq_domain
+ */
+struct lp8788_chg_irq {
+   enum lp8788_int_id which;
+   int virq;
+};
+
+/*
+ * struct lp8788_charger
+ * @lp   : used for accessing the registers of mfd lp8788 device
+ * @charger  : power supply driver for the battery charger
+ * @battery  : power supply driver for the battery
+ * @charger_work : work queue for charger input interrupts
+ * @chan : iio channels for getting adc values
+ * eg) battery voltage, capacity and temperature
+ * @irqs : charger dedicated interrupts
+ * @num_irqs : total numbers of charger interrupts
+ * @pdata: charger platform 

[PATCH v3 1/3] mfd: add lp8788 mfd driver

[Kim, Milo]

Patch v3.
replace generic irq code with irq domain

(a) use linear irq domain
(b) remove irq_base from lp8788 platform data
(c) changes on lp8788-charger and rtc-lp8788 drivers
: mapping hwirq to linux IRQ number
(seperate patches will be sent)

Signed-off-by: Milo(Woogyom) Kim 
---
 drivers/mfd/Kconfig  |   10 +
 drivers/mfd/Makefile |2 +
 drivers/mfd/lp8788-irq.c |  197 
 drivers/mfd/lp8788.c |  245 +
 include/linux/mfd/lp8788-isink.h |   52 ++
 include/linux/mfd/lp8788.h   |  364 ++
 6 files changed, 870 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/lp8788-irq.c
 create mode 100644 drivers/mfd/lp8788.c
 create mode 100644 include/linux/mfd/lp8788-isink.h
 create mode 100644 include/linux/mfd/lp8788.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d1facef..a888ccc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -450,6 +450,16 @@ config PMIC_ADP5520
  individual components like LCD backlight, LEDs, GPIOs and Kepad
  under the corresponding menus.
 
+config MFD_LP8788
+   bool "Texas Instruments LP8788 Power Management Unit Driver"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select IRQ_DOMAIN
+   help
+ TI LP8788 PMU supports regulators, battery charger, RTC,
+ ADC, backlight driver and current sinks.
+
 config MFD_MAX77686
bool "Maxim Semiconductor MAX77686 PMIC Support"
depends on I2C=y && GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..489cab9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -90,6 +90,8 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
 obj-$(CONFIG_MFD_DA9052_SPI)   += da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 
+obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
+
 obj-$(CONFIG_MFD_MAX77686) += max77686.o max77686-irq.o
 obj-$(CONFIG_MFD_MAX77693) += max77693.o max77693-irq.o
 max8925-objs   := max8925-core.o max8925-i2c.o
diff --git a/drivers/mfd/lp8788-irq.c b/drivers/mfd/lp8788-irq.c
new file mode 100644
index 000..4b8014a
--- /dev/null
+++ b/drivers/mfd/lp8788-irq.c
@@ -0,0 +1,197 @@
+/*
+ * TI LP8788 MFD - interrupt handler
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register address */
+#define LP8788_INT_1   0x00
+#define LP8788_INTEN_1 0x03
+
+#define BASE_INTEN_ADDRLP8788_INTEN_1
+#define SIZE_REG   8
+#define NUM_REGS   3
+
+/*
+ * struct lp8788_irq_data
+ * @lp   : used for accessing to lp8788 registers
+ * @irq_lock : mutex for enabling/disabling the interrupt
+ * @domain   : IRQ domain for handling nested interrupt
+ * @enabled  : status of enabled interrupt
+ */
+struct lp8788_irq_data {
+   struct lp8788 *lp;
+   struct mutex irq_lock;
+   struct irq_domain *domain;
+   int enabled[LP8788_INT_MAX];
+};
+
+static inline u8 _irq_to_addr(enum lp8788_int_id id)
+{
+   return id / SIZE_REG;
+}
+
+static inline u8 _irq_to_enable_addr(enum lp8788_int_id id)
+{
+   return _irq_to_addr(id) + BASE_INTEN_ADDR;
+}
+
+static inline u8 _irq_to_mask(enum lp8788_int_id id)
+{
+   return 1 << (id % SIZE_REG);
+}
+
+static inline u8 _irq_to_val(enum lp8788_int_id id, int enable)
+{
+   return enable << (id % SIZE_REG);
+}
+
+static void lp8788_irq_enable(struct irq_data *data)
+{
+   struct lp8788_irq_data *irqd = irq_data_get_irq_chip_data(data);
+   irqd->enabled[data->hwirq] = 1;
+}
+
+static void lp8788_irq_disable(struct irq_data *data)
+{
+   struct lp8788_irq_data *irqd = irq_data_get_irq_chip_data(data);
+   irqd->enabled[data->hwirq] = 0;
+}
+
+static void lp8788_irq_bus_lock(struct irq_data *data)
+{
+   struct lp8788_irq_data *irqd = irq_data_get_irq_chip_data(data);
+
+   mutex_lock(>irq_lock);
+}
+
+static void lp8788_irq_bus_sync_unlock(struct irq_data *data)
+{
+   struct lp8788_irq_data *irqd = irq_data_get_irq_chip_data(data);
+   enum lp8788_int_id irq = data->hwirq;
+   u8 addr, mask, val;
+
+   addr = _irq_to_enable_addr(irq);
+   mask = _irq_to_mask(irq);
+   val = _irq_to_val(irq, irqd->enabled[irq]);
+
+   lp8788_update_bits(irqd->lp, addr, mask, val);
+
+   mutex_unlock(>irq_lock);
+}
+
+static struct irq_chip lp8788_irq_chip = {
+   .name   = "lp8788",
+   .irq_enable = lp8788_irq_enable,
+   

Re: [net PATCH v1 2/2] net: netprio: fd passed in SCM_RIGHTS datagram not set correctly

[Al Viro]

On Mon, Aug 13, 2012 at 06:39:45PM -0700, John Fastabend wrote:
>   /* Bump the usage count and install the file. */
>   get_file(fp[i]);
>   fd_install(new_fd, fp[i]);
> + sock = sock_from_file(fp[i], );
> + if (sock)
> + sock->sk->sk_cgrp_prioidx = prioidx;

Better to do that before fd_install() exposes the sucker; it's not
a serious issue, but it's more obviously correct that way.
--
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: [net PATCH v1 1/2] net: netprio: fix files lock and remove useless d_path bits

[Al Viro]

On Mon, Aug 13, 2012 at 06:39:39PM -0700, John Fastabend wrote:
> - path = d_path(>f_path, tmp, PAGE_SIZE);

What's using tmp after that patch and do you still need to bother
allocating 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: [PATCH V2] staging: sm7xxfb: copy name of the device before calling smtc_alloc_fb_info

[Greg Kroah-Hartman]

On Sat, Aug 04, 2012 at 11:10:20PM +0545, Devendra Naga wrote:
> as we do a strcpy(smdrv_ptr->fb_struct->fix->id, name), and the name here in
> sm7xxx_probe is not having any assignment, and which leads to copying of the 
> garbage value
> into the id field of the fix struct of fb interface struct. fix it by copying 
> the name before
> calling alloc_fbinfo.
> 
> Signed-off-by: Devendra Naga 
> ---
> 
> Changes since V1:
>  Fix a null deref when smtc_alloc_fbinfo fails, this was added by me in V1.

Huh?  Please resend the correct patch you want me to apply, I'm confused
here.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 09/18] MIPS: Loongson: Add swiotlb to support big memory (>4GB).

[Huacai Chen]

Most of the code are copied from arch/mips/cavium-octeon/dma-octeon.c
and they work well.
Anyway, I'll try your suggestions, thank you.

On Tue, Aug 14, 2012 at 1:54 AM, Konrad Rzeszutek Wilk
 wrote:
>> +static void *loongson_dma_alloc_coherent(struct device *dev, size_t size,
>> + dma_addr_t *dma_handle, gfp_t gfp, struct 
>> dma_attrs *attrs)
>> +{
>> + void *ret;
>> +
>> + if (dma_alloc_from_coherent(dev, size, dma_handle, ))
>> + return ret;
>> +
>> + /* ignore region specifiers */
>> + gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
>> +
>> +#ifdef CONFIG_ZONE_DMA
>> + if (dev == NULL)
>> + gfp |= __GFP_DMA;
>
> When would this happen? dev == NULL?
>
>> + else if (dev->coherent_dma_mask <= DMA_BIT_MASK(24))
>> + gfp |= __GFP_DMA;
>> + else
>> +#endif
>> +#ifdef CONFIG_ZONE_DMA32
>> + if (dev->coherent_dma_mask <= DMA_BIT_MASK(32))
>> + gfp |= __GFP_DMA32;
>> + else
>
> Why the 'else'
>> +#endif
>> + ;
>
> why?
>> + gfp |= __GFP_NORETRY;
>> +
>> + ret = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
>> + mb();
>
> Why the 'mb()' ? Can you just do
> return swiotlb_alloc_coherent(...)
>
>> + return ret;
>> +}
>> +
>> +static void loongson_dma_free_coherent(struct device *dev, size_t size,
>> + void *vaddr, dma_addr_t dma_handle, struct 
>> dma_attrs *attrs)
>> +{
>> + int order = get_order(size);
>> +
>> + if (dma_release_from_coherent(dev, order, vaddr))
>> + return;
>> +
>> + swiotlb_free_coherent(dev, size, vaddr, dma_handle);
>> +}
>> +
>> +static dma_addr_t loongson_dma_map_page(struct device *dev, struct page 
>> *page,
>> + unsigned long offset, size_t size,
>> + enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + dma_addr_t daddr = swiotlb_map_page(dev, page, offset, size,
>> + dir, attrs);
>> + mb();
>
> Please do 'return swiotlb_map_page(..)'..
>
> But if you are doing that why don't you just set the dma_ops.map_page = 
> swiotlb_map_page
> ?
>
>
>> + return daddr;
>> +}
>> +
>> +static int loongson_dma_map_sg(struct device *dev, struct scatterlist *sg,
>> + int nents, enum dma_data_direction dir,
>> + struct dma_attrs *attrs)
>> +{
>> + int r = swiotlb_map_sg_attrs(dev, sg, nents, dir, NULL);
>> + mb();
>> +
>> + return r;
>> +}
>> +
>> +static void loongson_dma_sync_single_for_device(struct device *dev,
>> + dma_addr_t dma_handle, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> + swiotlb_sync_single_for_device(dev, dma_handle, size, dir);
>> + mb();
>> +}
>> +
>> +static void loongson_dma_sync_sg_for_device(struct device *dev,
>> + struct scatterlist *sg, int nents,
>> + enum dma_data_direction dir)
>> +{
>> + swiotlb_sync_sg_for_device(dev, sg, nents, dir);
>> + mb();
>> +}
>> +
>
> I am not really sure why you have these extra functions, when you could
> just modify the dma_ops to point to the swiotlb ones
>
>> +static dma_addr_t loongson_unity_phys_to_dma(struct device *dev, 
>> phys_addr_t paddr)
>> +{
>> + return (paddr < 0x1000) ?
>> + (paddr | 0x8000) : paddr;
>> +}
>> +
>> +static phys_addr_t loongson_unity_dma_to_phys(struct device *dev, 
>> dma_addr_t daddr)
>> +{
>> + return (daddr < 0x9000 && daddr >= 0x8000) ?
>> + (daddr & 0x0fff) : daddr;
>> +}
>> +
>> +struct loongson_dma_map_ops {
>> + struct dma_map_ops dma_map_ops;
>> + dma_addr_t (*phys_to_dma)(struct device *dev, phys_addr_t paddr);
>> + phys_addr_t (*dma_to_phys)(struct device *dev, dma_addr_t daddr);
>> +};
>> +
>> +dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>> +{
>> + struct loongson_dma_map_ops *ops = container_of(get_dma_ops(dev),
>> + struct loongson_dma_map_ops, 
>> dma_map_ops);
>> +
>> + return ops->phys_to_dma(dev, paddr);
>> +}
>> +
>> +phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
>> +{
>> + struct loongson_dma_map_ops *ops = container_of(get_dma_ops(dev),
>> + struct loongson_dma_map_ops, 
>> dma_map_ops);
>> +
>> + return ops->dma_to_phys(dev, daddr);
>> +}
>> +
>> +static int loongson_dma_set_mask(struct device *dev, u64 mask)
>> +{
>> + /* Loongson doesn't support DMA above 32-bit */
>> + if (mask > DMA_BIT_MASK(32))
>> + return -EIO;
>> +
>> + *dev->dma_mask = mask;
>> +
>> + return 0;
>> +}
>> +
>> +static struct loongson_dma_map_ops loongson_linear_dma_map_ops = {
>> + .dma_map_ops = {
>> + .alloc = 

Re: [PATCH] staging/olpc_dcon: fix checkpatch warnings

[Greg Kroah-Hartman]

On Fri, Jul 27, 2012 at 08:45:52PM +0900, Toshiaki Yamane wrote:
> fixed some checkpatch warnings.
> (Excluding -WARNING: msleep < 20ms can sleep for up to 20ms-)

Then fix your changelog entry:

> 
> $ find drivers/staging/olpc_dcon/ -name "*.[ch]"|xargs 
> ./scripts/checkpatch.pl \
> -f --terse --nosummary|cut -f3- -d":"|sort |uniq -c|sort -n
>   2  WARNING: msleep < 20ms can sleep for up to 20ms; see 
> Documentation/timers/timers-howto.txt

That shouldn't be there.

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] mmap: feed back correct prev vma when finding vma

[Hugh Dickins]

On Fri, 10 Aug 2012, Hillf Danton wrote:
> On Fri, Aug 10, 2012 at 9:26 AM, Hugh Dickins  wrote:
> > On Thu, 9 Aug 2012, Hillf Danton wrote:
> >> After walking rb tree, if vma is determined, prev vma has to be determined
> >> based on vma; and rb_prev should be considered only if no vma determined.
> >
> > Why?  Because you think more code is better code?  I disagree.
> 
> s/more/correct/
> 
> Because feedback is incorrect if we return vma corresponding to
> the root node.

"feedback"?  "root node"?

I took another look, and a WARN_ON soon told me that you do have a point.
It stirred memories, and I found an earlier thread from 2008, responsible
for replacing the original "return vma" by a "break" in 2.6.27.

I agree that find_vma_prepare() is confusing, but your vm_prev patch is not
the right fix: let's un-confuse it this way, which barely needs comment.

Hugh

[PATCH] mm: replace find_vma_prepare by clearer find_vma_links

People get confused by find_vma_prepare(), because it doesn't care about
what it returns in its output args, when its callers won't be interested.

Clarify by passing in end-of-range address too, and returning failure if
any existing vma overlaps the new range: instead of returning an ambiguous
vma which most callers then must check.  find_vma_links() is a clearer name.

This does revert 2.6.27's dfe195fb79e88 ("mm: fix uninitialized variables
for find_vma_prepare callers"), but it looks like gcc 4.3.0 was one of
those releases too eager to shout about uninitialized variables: only
copy_vma() warns with 4.5.1 and 4.7.1, which a BUG on error silences.

Signed-off-by: Hugh Dickins 
Cc: Benny Halevy 
Cc: Hillf Danton 
---

 mm/mmap.c |   45 +
 1 file changed, 21 insertions(+), 24 deletions(-)

--- 3.6-rc1/mm/mmap.c   2012-08-03 08:31:27.064842271 -0700
+++ linux/mm/mmap.c 2012-08-13 12:23:35.862895633 -0700
@@ -356,17 +356,14 @@ void validate_mm(struct mm_struct *mm)
 #define validate_mm(mm) do { } while (0)
 #endif
 
-static struct vm_area_struct *
-find_vma_prepare(struct mm_struct *mm, unsigned long addr,
-   struct vm_area_struct **pprev, struct rb_node ***rb_link,
-   struct rb_node ** rb_parent)
+static int find_vma_links(struct mm_struct *mm, unsigned long addr,
+   unsigned long end, struct vm_area_struct **pprev,
+   struct rb_node ***rb_link, struct rb_node **rb_parent)
 {
-   struct vm_area_struct * vma;
-   struct rb_node ** __rb_link, * __rb_parent, * rb_prev;
+   struct rb_node **__rb_link, *__rb_parent, *rb_prev;
 
__rb_link = >mm_rb.rb_node;
rb_prev = __rb_parent = NULL;
-   vma = NULL;
 
while (*__rb_link) {
struct vm_area_struct *vma_tmp;
@@ -375,9 +372,9 @@ find_vma_prepare(struct mm_struct *mm, u
vma_tmp = rb_entry(__rb_parent, struct vm_area_struct, vm_rb);
 
if (vma_tmp->vm_end > addr) {
-   vma = vma_tmp;
-   if (vma_tmp->vm_start <= addr)
-   break;
+   /* Fail if an existing vma overlaps the area */
+   if (vma_tmp->vm_start < end)
+   return -ENOMEM;
__rb_link = &__rb_parent->rb_left;
} else {
rb_prev = __rb_parent;
@@ -390,7 +387,7 @@ find_vma_prepare(struct mm_struct *mm, u
*pprev = rb_entry(rb_prev, struct vm_area_struct, vm_rb);
*rb_link = __rb_link;
*rb_parent = __rb_parent;
-   return vma;
+   return 0;
 }
 
 void __vma_link_rb(struct mm_struct *mm, struct vm_area_struct *vma,
@@ -459,11 +456,12 @@ static void vma_link(struct mm_struct *m
  */
 static void __insert_vm_struct(struct mm_struct *mm, struct vm_area_struct 
*vma)
 {
-   struct vm_area_struct *__vma, *prev;
+   struct vm_area_struct *prev;
struct rb_node **rb_link, *rb_parent;
 
-   __vma = find_vma_prepare(mm, vma->vm_start,, _link, _parent);
-   BUG_ON(__vma && __vma->vm_start < vma->vm_end);
+   if (find_vma_links(mm, vma->vm_start, vma->vm_end,
+  , _link, _parent))
+   BUG();
__vma_link(mm, vma, prev, rb_link, rb_parent);
mm->map_count++;
 }
@@ -1229,8 +1227,7 @@ unsigned long mmap_region(struct file *f
/* Clear old maps */
error = -ENOMEM;
 munmap_back:
-   vma = find_vma_prepare(mm, addr, , _link, _parent);
-   if (vma && vma->vm_start < addr + len) {
+   if (find_vma_links(mm, addr, addr + len, , _link, _parent)) {
if (do_munmap(mm, addr, len))
return -ENOMEM;
goto munmap_back;
@@ -2201,8 +2198,7 @@ static unsigned long do_brk(unsigned lon
 * Clear old maps.  this also does some error checking for us
 */
  munmap_back:
-   vma = find_vma_prepare(mm, addr, , _link, _parent);
-   if (vma 

Re: [PATCH v6 3/3] KVM: perf kvm events analysis tool

[Xiao Guangrong]

On 08/11/2012 04:37 AM, David Ahern wrote:
> Thanks for resubmitting this; it was on my to-do list as well.

Thanks for you liking it and your precious comments, David! :)

> 
> On 8/9/12 9:19 PM, Dong Hao wrote:
>> +static bool kvm_events_exist(const char *event)
>> +{
>> +char evt_path[MAXPATHLEN];
>> +int fd;
>> +
>> +snprintf(evt_path, MAXPATHLEN, "%s/kvm/%s/id", tracing_events_path,
>> + event);
>> +
>> +fd = open(evt_path, O_RDONLY);
> 
> Use is_valid_tracepoint().

Fine to us, will do it in the next version.

--
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] mmc: card: Skip secure option for MoviNAND.

[IAN CHEN]

Dear Mr. Jeon,

This is workaround for some Samsung eMMC, MoviNAND.
There are known issue about secure erase & secure trim with these eMMC device 
which I listed by product_name.
Therefore, for these eMMC devices, we just skip mmc_blk_issue_secdiscard_rq() 
and use mmc_blk_issue_discard_rq() instead.

You could refer this discussion in XDA developers.
http://forum.xda-developers.com/showthread.php?t=1644364

https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Regards,
Ian

-Original Message-
From: Namjae Jeon [mailto:linkinj...@gmail.com] 
Sent: Monday, August 13, 2012 10:03 PM
To: IAN CHEN
Cc: c...@laptop.org; adrian.hun...@intel.com; subha...@codeaurora.org; 
linus.wall...@linaro.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; d.j.s...@samsung.com; jongtae22@samsung.com; 
kyungmin.p...@samsung.com; jh80.ch...@samsung.com
Subject: Re: [PATCH] mmc: card: Skip secure option for MoviNAND.

Hi. Ian.

known issue ? Would you explain more ?

Thanks.

2012/8/13 IAN CHEN :
> From 5c60eb8be04c7440d6e33b8f72ea2046a3657ac4 Mon Sep 17 00:00:00 2001
> From: ian.cy.chen 
> Date: Mon, 13 Aug 2012 10:53:55 +0900
> Subject: [PATCH] mmc: card: Skip secure option for MoviNAND.
>
> For several MoviNAND, there are some known issue with secure option.
> For these specific MoviNAND device, we skip secure option.
>
> Signed-off-by: Ian Chen 
> ---
>  drivers/mmc/card/block.c |   24 +++-
>  include/linux/mmc/card.h |1 +
>  2 files changed, 24 insertions(+), 1 deletions(-)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] mmc: card: Skip secure option for MoviNAND.

[IAN CHEN]

Dear Mr. Jeon,

This is workaround for some Samsung eMMC, MoviNAND.
There are known issue about secure erase & secure trim with these eMMC device 
which I listed by product_name.
Therefore, for these eMMC devices, we just skip mmc_blk_issue_secdiscard_rq() 
and use mmc_blk_issue_discard_rq() instead.

You could refer this discussion in XDA developers.
http://forum.xda-developers.com/showthread.php?t=1644364

https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB

Regards,
Ian
 
-Original Message-
From: Namjae Jeon [mailto:linkinj...@gmail.com] 
Sent: Monday, August 13, 2012 10:03 PM
To: IAN CHEN
Cc: c...@laptop.org; adrian.hun...@intel.com; subha...@codeaurora.org; 
linus.wall...@linaro.org; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; d.j.s...@samsung.com; jongtae22@samsung.com; 
kyungmin.p...@samsung.com; jh80.ch...@samsung.com
Subject: Re: [PATCH] mmc: card: Skip secure option for MoviNAND.

Hi. Ian.

known issue ? Would you explain more ?

Thanks.

2012/8/13 IAN CHEN :
> From 5c60eb8be04c7440d6e33b8f72ea2046a3657ac4 Mon Sep 17 00:00:00 2001
> From: ian.cy.chen 
> Date: Mon, 13 Aug 2012 10:53:55 +0900
> Subject: [PATCH] mmc: card: Skip secure option for MoviNAND.
>
> For several MoviNAND, there are some known issue with secure option.
> For these specific MoviNAND device, we skip secure option.
>
> Signed-off-by: Ian Chen 
> ---
>  drivers/mmc/card/block.c |   24 +++-
>  include/linux/mmc/card.h |1 +
>  2 files changed, 24 insertions(+), 1 deletions(-)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 3/3] KVM: perf kvm events analysis tool

[Xiao Guangrong]

On 08/10/2012 10:14 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 10, 2012 at 11:19:10AM +0800, Dong Hao escreveu:
>> From: Xiao Guangrong 
>>
>> Add 'perf kvm stat' support to analyze kvm vmexit/mmio/ioport smartly.
> 
> Some comments below about recent changes in my perf/core branch.

Arnaldo,

Thank you very much for your review! All of your comments are fine to us,
we will correct them in the next version.

--
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] floppy: do put_disk on current dr if blk_init_queue fails

[Ben Hutchings]

On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> If blk_init_queue fails, we do not call put_disk on the current dr
> (dr is decremented first in the error handling loop).
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Herton Ronaldo Krzesinski 

Reviewed-by: Ben Hutchings 

> ---
>  drivers/block/floppy.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index c8d9e68..1e09e99 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -4151,6 +4151,7 @@ static int __init do_floppy_init(void)
>  
>   disks[dr]->queue = blk_init_queue(do_fd_request, _lock);
>   if (!disks[dr]->queue) {
> + put_disk(disks[dr]);
>   err = -ENOMEM;
>   goto out_put_disk;
>   }

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

[PATCH] perf script: Fix a NULL pointer dereference

[Namhyung Kim]

From: Namhyung Kim 

If 'perf script --gen-script' was called with a perf.data which
contains no tracepoint event, it'd segfault due to NULL pevent
pointer. Fix it.

Cc: Feng Tang 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/trace-event-parse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/trace-event-parse.c 
b/tools/perf/util/trace-event-parse.c
index 4cb7f3831f78..a5a554efeb50 100644
--- a/tools/perf/util/trace-event-parse.c
+++ b/tools/perf/util/trace-event-parse.c
@@ -293,7 +293,7 @@ struct event_format *trace_find_next_event(struct pevent 
*pevent,
 {
static int idx;
 
-   if (!pevent->events)
+   if (!pevent || !pevent->events)
return NULL;
 
if (!event) {
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] Android: Small documentation changes and a bug fix

[Greg KH]

On Wed, Aug 01, 2012 at 02:54:15PM +1000, Cruz Julian Bishop wrote:
> Hi,
> 
> This set of patches completes more documentation in android/logger.c, as well 
> as fixing a bug there and a comment formatting issue in android/ashmem.c.
> 
> Sorry if kernel-doc was not supposed to be applied to driver files - If it 
> isn't, I'll be sure to remember that for next time. :)
> 
> Cruz Julian Bishop (5):
>   Fix comment/license formatting in android/ashmem.c
>   Complete documentation of logger_entry in android/logger.h
>   Finish documentation of two structs in android/logger.c
>   Redocument some functions in android/logger.c
>   Fixes a potential bug in android/logger.c

In the future, please use a better subject line.  Something like:
staging: android: logger: fix finish documentation of structure foo

As it is, I had to go and edit your subjects, and wrap your changelog
comments (72 columns please).  In the future, I might not.

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 1/6] floppy: don't call alloc_ordered_workqueue inside the alloc_disk loop

[Ben Hutchings]

On Mon, 2012-08-13 at 15:16 -0300, Herton Ronaldo Krzesinski wrote:
> Since commit 070ad7e ("floppy: convert to delayed work and single-thread
> wq"), we end up calling alloc_ordered_workqueue multiple times inside
> the loop, which shouldn't be intended. Besides the leak, other side
> effect in the current code is if blk_init_queue fails, we would end up
> calling unregister_blkdev even if we didn't call yet register_blkdev.
> 
> Just moved the allocation of floppy_wq before the loop, and adjusted the
> code accordingly.
> 
> Cc: sta...@vger.kernel.org # 3.5+
> Acked-by: Vivek Goyal 
> Signed-off-by: Herton Ronaldo Krzesinski 

Reviewed-by: Ben Hutchings 

> ---
>  drivers/block/floppy.c |   15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index a7d6347..c8d9e68 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -4138,6 +4138,10 @@ static int __init do_floppy_init(void)
>  
>   raw_cmd = NULL;
>  
> + floppy_wq = alloc_ordered_workqueue("floppy", 0);
> + if (!floppy_wq)
> + return -ENOMEM;
> +
>   for (dr = 0; dr < N_DRIVE; dr++) {
>   disks[dr] = alloc_disk(1);
>   if (!disks[dr]) {
> @@ -4145,16 +4149,10 @@ static int __init do_floppy_init(void)
>   goto out_put_disk;
>   }
>  
> - floppy_wq = alloc_ordered_workqueue("floppy", 0);
> - if (!floppy_wq) {
> - err = -ENOMEM;
> - goto out_put_disk;
> - }
> -
>   disks[dr]->queue = blk_init_queue(do_fd_request, _lock);
>   if (!disks[dr]->queue) {
>   err = -ENOMEM;
> - goto out_destroy_workq;
> + goto out_put_disk;
>   }
>  
>   blk_queue_max_hw_sectors(disks[dr]->queue, 64);
> @@ -4318,8 +4316,6 @@ out_release_dma:
>  out_unreg_region:
>   blk_unregister_region(MKDEV(FLOPPY_MAJOR, 0), 256);
>   platform_driver_unregister(_driver);
> -out_destroy_workq:
> - destroy_workqueue(floppy_wq);
>  out_unreg_blkdev:
>   unregister_blkdev(FLOPPY_MAJOR, "fd");
>  out_put_disk:
> @@ -4335,6 +4331,7 @@ out_put_disk:
>   }
>   put_disk(disks[dr]);
>   }
> + destroy_workqueue(floppy_wq);
>   return err;
>  }
>  

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 5/5] Fixes a potential bug in android/logger.c

[Greg KH]

On Thu, Aug 02, 2012 at 09:50:44AM +1000, Ryan Mallon wrote:
> On 01/08/12 14:54, Cruz Julian Bishop wrote:
> > Previously, when calling is_between(a, b, c), the calculation was wrong.
> > It counted C as between A and B if C was equal to B, but not A.
> > 
> > Example of this are:
> > 
> > is_between(1, 10, 10) = 1 (Expected: 0)
> > is_between(1, 10, 1) = 0 (Expected: 0)
> > is_between(20, 10, 10) = 1 (Expected: 0)
> > 
> > And so on and so forth.
> > 
> > Obviously, ten is not a number between one and ten - only two to eight are, 
> > so I made this patch :)
> 
> Is nine not a number between one and ten? :-p.
> 
> The question with a patch like this is whether the function's
> documentation, which says it returns 1 if a < c < b is wrong, or whether
> the implementation, which does a < c <= b is wrong. If the documentation
> is wrong, and something is relying on the current implementation, then
> this patch might actually break things.

I agree, which is correct?  I'd stick with the code for now, care to fix
the comment instead?

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 4/5] Redocument some functions in android/logger.c

[Greg KH]

On Wed, Aug 01, 2012 at 02:54:19PM +1000, Cruz Julian Bishop wrote:
> I will document the rest later if they remain unchanged
> Normally, I would do them all at once, but I don't have the chance to do them 
> all at the moment
> 
> Signed-off-by: Cruz Julian Bishop 
> ---
>  drivers/staging/android/logger.c |   90 
> +-
>  1 file changed, 60 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/staging/android/logger.c 
> b/drivers/staging/android/logger.c
> index 1d5ed47..226d8b5 100644
> --- a/drivers/staging/android/logger.c
> +++ b/drivers/staging/android/logger.c
> @@ -78,15 +78,20 @@ struct logger_reader {
>   size_t  r_off;
>  };
>  
> -/* logger_offset - returns index 'n' into the log via (optimized) modulus */
> +/**
> + * logger_offset() - returns index 'n' into the log via (optimized) modulus
> + * @log: The log being referenced
> + * @n:   The index number being referenced
> + */
>  static size_t logger_offset(struct logger_log *log, size_t n)

There is no need to document static functions in this style, unless you
really feel it is needed.

For simple things like this, it isn't needed at all, so I'm not going to
apply this patch, sorry.

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 0/5] staging/csr: cleanup patches

[Greg Kroah-Hartman]

On Sat, Aug 04, 2012 at 01:00:08PM +0545, Devendra Naga wrote:
> Actually i have a question about the dbg macros, unifi_warning,
> unifi_error, and unifi_trace,
> 
> I think these can be implemented using dev_warn, dev_dbg, functions,
> i mean we can remove these unifi_warning and unifi_error and unifi_trace
> and use the dev_warn and dev_dbg.

Yes, we should use those instead.

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 V2 18/18] Tools: hv: Properly manage open streams

[Ben Hutchings]

On Mon, 2012-08-13 at 10:07 -0700, K. Y. Srinivasan wrote:
> Close the open streams properly.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> Reviewed-by: Olaf Hering 
> Reviewed-by: Ben Hutchings 

This isn't reviewed by me, I'm the author!

Ben.

> ---
>  tools/hv/hv_kvp_daemon.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index c8e1013..ca6424f 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -160,7 +160,7 @@ static void kvp_update_file(int pool)
>   sizeof(struct kvp_record),
>   kvp_file_info[pool].num_records, filep);
>  
> - fflush(filep);
> + fclose(filep);
>   kvp_release_lock(pool);
>  }
>  
> @@ -206,7 +206,7 @@ static void kvp_update_mem_state(int pool)
>   kvp_file_info[pool].num_blocks = num_blocks;
>   kvp_file_info[pool].records = record;
>   kvp_file_info[pool].num_records = records_read;
> -
> + fclose(filep);
>   kvp_release_lock(pool);
>  }
>  static int kvp_file_init(void)

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH V2 02/18] Drivers: hv: Add KVP definitions for IP address injection

[Ben Hutchings]

On Mon, 2012-08-13 at 18:38 -0700, Greg KH wrote:
> On Mon, Aug 13, 2012 at 10:06:51AM -0700, K. Y. Srinivasan wrote:
> > Add the necessary definitions for supporting the IP injection functionality.
[...]
> > --- a/include/linux/hyperv.h
> > +++ b/include/linux/hyperv.h
> > @@ -122,12 +122,53 @@
> >  #define REG_U32 4
> >  #define REG_U64 8
> >  
> > +/*
> > + * As we look at expanding the KVP functionality to include
> > + * IP injection functionality, we need to maintain binary
> > + * compatibility with older daemons.
> > + *
> > + * The KVP opcodes are defined by the host and it was unfortunate
> > + * that I chose to treat the registration operation as part of the
> > + * KVP operations defined by the host.
> > + * Here is the level of compatibility
> > + * (between the user level daemon and the kernel KVP driver) that we
> > + * will implement:
> > + *
> > + * An older daemon will always be supported on a newer driver.
> > + * A given user level daemon will require a minimal version of the
> > + * kernel driver.
> > + * If we cannot handle the version differences, we will fail gracefully
> > + * (this can happen when we have a user level daemon that is more
> > + * advanced than the KVP driver.
> > + *
> > + * We will use values used in this handshake for determining if we have
> > + * workable user level daemon and the kernel driver. We begin by taking the
> > + * registration opcode out of the KVP opcode namespace. We will however,
> > + * maintain compatibility with the existing user-level daemon code.
> > + */
> > +
> > +/*
> > + * Daemon code not supporting IP injection (legacy daemon).
> > + */
> > +
> > +#define KVP_OP_REGISTER4
> 
> Huh?
> 
> > +/*
> > + * Daemon code supporting IP injection.
> > + * The KVP opcode field is used to communicate the
> > + * registration information; so define a namespace that
> > + * will be distinct from the host defined KVP opcode.
> > + */
> > +
> > +#define KVP_OP_REGISTER1 100
> > +
> >  enum hv_kvp_exchg_op {
> > KVP_OP_GET = 0,
> > KVP_OP_SET,
> > KVP_OP_DELETE,
> > KVP_OP_ENUMERATE,
> > -   KVP_OP_REGISTER,
> > +   KVP_OP_GET_IP_INFO,
> > +   KVP_OP_SET_IP_INFO,
> 
> So you overloaded the command and somehow think that is ok?  How is that
> supposed to work?  Why not just always keep it there, but fail if it is
> called as you know you have a mismatch?
> 
> Otherwise, again, you just broke older tools on a newer kernel.
> 
> Or am I missing something here?

You are.  The above enumeration is for the hypervisor-to-guest protocol,
whereas KVP_OP_REGISTER and KVP_OP_REGISTER1 are only used between
daemon and driver.  The registration operation code should have been
defined as a sufficiently high value to avoid collision.

However, since the daemon will always send one of the registration
operations at start of day (and then never again), it seems that the
driver can avoid confusing registration with a reply to
KVP_OP_GET_IP_INFO.  Instead, the two registration operation codes
distinguish the capabilities of the daemon and actually aid backward
compatibility.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

[net PATCH v1 2/2] net: netprio: fd passed in SCM_RIGHTS datagram not set correctly

[John Fastabend]

A socket fd passed in a SCM_RIGHTS datagram was not getting
updated with the new tasks cgrp prioidx. This leaves IO on
the socket tagged with the old tasks priority.

To fix this add a check in the scm recvmsg path to update the
sock cgrp prioidx with the new tasks value.

Thanks to Al Viro for catching this.

CC: Neil Horman 
Reported-by: Al Viro 
Signed-off-by: John Fastabend 
---

 net/core/scm.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/net/core/scm.c b/net/core/scm.c
index 8f6ccfd..053bd43 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -249,6 +249,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie 
*scm)
struct file **fp = scm->fp->fp;
int __user *cmfptr;
int err = 0, i;
+   __u32 prioidx = task_netprioidx(current);
 
if (MSG_CMSG_COMPAT & msg->msg_flags) {
scm_detach_fds_compat(msg, scm);
@@ -265,6 +266,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie 
*scm)
for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); isk->sk_cgrp_prioidx = prioidx;
}
 
if (i > 0)

--
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/

[net PATCH v1 1/2] net: netprio: fix files lock and remove useless d_path bits

[John Fastabend]

Add lock to prevent a race with a file closing and also remove
useless and ugly sscanf code. The extra code was never needed
and the case it supposedly protected against is in fact handled
correctly by sock_from_file as pointed out by Al Viro.

CC: Neil Horman 
Reported-by: Al Viro 
Signed-off-by: John Fastabend 
---

 net/core/netprio_cgroup.c |   15 ---
 1 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index ed0c043..0323ec3 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -296,29 +296,22 @@ void net_prio_attach(struct cgroup *cgrp, struct 
cgroup_taskset *tset)
continue;
}
 
-   rcu_read_lock();
+   spin_lock(>file_lock);
fdt = files_fdtable(files);
for (fd = 0; fd < fdt->max_fds; fd++) {
-   char *path;
struct file *file;
struct socket *sock;
-   unsigned long s;
-   int rv, err = 0;
+   int err;
 
file = fcheck_files(files, fd);
if (!file)
continue;
 
-   path = d_path(>f_path, tmp, PAGE_SIZE);
-   rv = sscanf(path, "socket:[%lu]", );
-   if (rv <= 0)
-   continue;
-
sock = sock_from_file(file, );
-   if (!err)
+   if (sock)
sock_update_netprioidx(sock->sk, p);
}
-   rcu_read_unlock();
+   spin_unlock(>file_lock);
task_unlock(p);
}
kfree(tmp);

--
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/6] workqueue: make all workqueues non-reentrant

[Tejun Heo]

By default, each per-cpu part of a bound workqueue operates separately
and a work item may be executing concurrently on different CPUs.  The
behavior avoids some cross-cpu traffic but leads to subtle weirdities
and not-so-subtle contortions in the API.

* There's no sane usefulness in allowing a single work item to be
  executed concurrently on multiple CPUs.  People just get the
  behavior unintentionally and get surprised after learning about it.
  Most either explicitly synchronize or use non-reentrant/ordered
  workqueue but this is error-prone.

* flush_work() can't wait for multiple instances of the same work item
  on different CPUs.  If a work item is executing on cpu0 and then
  queued on cpu1, flush_work() can only wait for the one on cpu1.

  Unfortunately, work items can easily cross CPU boundaries
  unintentionally when the queueing thread gets migrated.  This means
  that if multiple queuers compete, flush_work() can't even guarantee
  that the instance queued right before it is finished before
  returning.

* flush_work_sync() was added to work around some of the deficiencies
  of flush_work().  In addition to the usual flushing, it ensures that
  all currently executing instances are finished before returning.
  This operation is expensive as it has to walk all CPUs and at the
  same time fails to address competing queuer case.

  Incorrectly using flush_work() when flush_work_sync() is necessary
  is an easy error to make and can lead to bugs which are difficult to
  reproduce.

* Similar problems exist for flush_delayed_work[_sync]().

Other than the cross-cpu access concern, there's no benefit in
allowing parallel execution and it's plain silly to have this level of
contortion for workqueue which is widely used from core code to
extremely obscure drivers.

This patch makes all workqueues non-reentrant.  If a work item is
executing on a different CPU when queueing is requested, it is always
queued to that CPU.  This guarantees that any given work item can be
executing on one CPU at maximum and if a work item is queued and
executing, both are on the same CPU.

The only behavior change which may affect workqueue users negatively
is that non-reentrancy overrides the affinity specified by
queue_work_on().  On a reentrant workqueue, the affinity specified by
queue_work_on() is always followed.  Now, if the work item is
executing on one of the CPUs, the work item will be queued there
regardless of the requested affinity.  I've reviewed all workqueue
users which request explicit affinity, and, fortunately, none seems to
be crazy enough to exploit parallel execution of the same work item.

This adds an additional busy_hash lookup if the work item was
previously queued on a different CPU.  This shouldn't be noticeable
under any sane workload.  Work item queueing isn't a very
high-frequency operation and they don't jump across CPUs all the time.
In a micro benchmark to exaggerate this difference - measuring the
time it takes for two work items to repeatedly jump between two CPUs a
number (10M) of times with busy_hash table densely populated, the
difference was around 3%.

While the overhead is measureable, it is only visible in pathological
cases and the difference isn't huge.  This change brings much needed
sanity to workqueue and makes its behavior consistent with timer.  I
think this is the right tradeoff to make.

This enables significant simplification of workqueue API.
Simplification patches will follow.

Signed-off-by: Tejun Heo 
---
 kernel/workqueue.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7413242..26f048b 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1216,14 +1216,15 @@ static void __queue_work(unsigned int cpu, struct 
workqueue_struct *wq,
cpu = raw_smp_processor_id();
 
/*
-* It's multi cpu.  If @wq is non-reentrant and @work
-* was previously on a different cpu, it might still
-* be running there, in which case the work needs to
-* be queued on that cpu to guarantee non-reentrance.
+* It's multi cpu.  If @work was previously on a different
+* cpu, it might still be running there, in which case the
+* work needs to be queued on that cpu to guarantee
+* non-reentrancy.
 */
gcwq = get_gcwq(cpu);
-   if (wq->flags & WQ_NON_REENTRANT &&
-   (last_gcwq = get_work_gcwq(work)) && last_gcwq != gcwq) {
+   last_gcwq = get_work_gcwq(work);
+
+   if (last_gcwq && last_gcwq != gcwq) {
struct worker *worker;
 
spin_lock(_gcwq->lock);
-- 
1.7.7.3

--
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  

[PATCH 3/6] workqueue: gut system_nrt[_freezable]_wq()

[Tejun Heo]

Now that all workqueues are non-reentrant, system[_freezable]_wq() are
equivalent to system_nrt[_freezable]_wq().  Replace the latter with
wrappers around system[_freezable]_wq().  The wrapping goes through
inline functions so that __deprecated can be added easily.

Signed-off-by: Tejun Heo 
---
 include/linux/workqueue.h |   23 ++-
 kernel/workqueue.c|   12 ++--
 2 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index b2716b6..b0a678b 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -297,10 +297,6 @@ enum {
  * system_long_wq is similar to system_wq but may host long running
  * works.  Queue flushing might take relatively long.
  *
- * system_nrt_wq is non-reentrant and guarantees that any given work
- * item is never executed in parallel by multiple CPUs.  Queue
- * flushing might take relatively long.
- *
  * system_unbound_wq is unbound workqueue.  Workers are not bound to
  * any specific CPU, not concurrency managed, and all queued works are
  * executed immediately as long as max_active limit is not reached and
@@ -308,16 +304,25 @@ enum {
  *
  * system_freezable_wq is equivalent to system_wq except that it's
  * freezable.
- *
- * system_nrt_freezable_wq is equivalent to system_nrt_wq except that
- * it's freezable.
  */
 extern struct workqueue_struct *system_wq;
 extern struct workqueue_struct *system_long_wq;
-extern struct workqueue_struct *system_nrt_wq;
 extern struct workqueue_struct *system_unbound_wq;
 extern struct workqueue_struct *system_freezable_wq;
-extern struct workqueue_struct *system_nrt_freezable_wq;
+
+static inline struct workqueue_struct *__system_nrt_wq(void)
+{
+   return system_wq;
+}
+
+static inline struct workqueue_struct *__system_nrt_freezable_wq(void)
+{
+   return system_freezable_wq;
+}
+
+/* equivlalent to system_wq and system_freezable_wq, deprecated */
+#define system_nrt_wq  __system_nrt_wq()
+#define system_nrt_freezable_wq__system_nrt_freezable_wq()
 
 extern struct workqueue_struct *
 __alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active,
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 938adc0..ce39467 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -269,16 +269,12 @@ struct workqueue_struct {
 
 struct workqueue_struct *system_wq __read_mostly;
 struct workqueue_struct *system_long_wq __read_mostly;
-struct workqueue_struct *system_nrt_wq __read_mostly;
 struct workqueue_struct *system_unbound_wq __read_mostly;
 struct workqueue_struct *system_freezable_wq __read_mostly;
-struct workqueue_struct *system_nrt_freezable_wq __read_mostly;
 EXPORT_SYMBOL_GPL(system_wq);
 EXPORT_SYMBOL_GPL(system_long_wq);
-EXPORT_SYMBOL_GPL(system_nrt_wq);
 EXPORT_SYMBOL_GPL(system_unbound_wq);
 EXPORT_SYMBOL_GPL(system_freezable_wq);
-EXPORT_SYMBOL_GPL(system_nrt_freezable_wq);
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -3847,16 +3843,12 @@ static int __init init_workqueues(void)
 
system_wq = alloc_workqueue("events", 0, 0);
system_long_wq = alloc_workqueue("events_long", 0, 0);
-   system_nrt_wq = alloc_workqueue("events_nrt", WQ_NON_REENTRANT, 0);
system_unbound_wq = alloc_workqueue("events_unbound", WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
system_freezable_wq = alloc_workqueue("events_freezable",
  WQ_FREEZABLE, 0);
-   system_nrt_freezable_wq = alloc_workqueue("events_nrt_freezable",
-   WQ_NON_REENTRANT | WQ_FREEZABLE, 0);
-   BUG_ON(!system_wq || !system_long_wq || !system_nrt_wq ||
-  !system_unbound_wq || !system_freezable_wq ||
-   !system_nrt_freezable_wq);
+   BUG_ON(!system_wq || !system_long_wq || !system_unbound_wq ||
+  !system_freezable_wq);
return 0;
 }
 early_initcall(init_workqueues);
-- 
1.7.7.3

--
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 6/6] workqueue: deprecate WQ_NON_REENTRANT

[Tejun Heo]

WQ_NON_REENTRANT is now spurious.  Make alloc_workqueue() trigger
WARN_ON() if the flag is specified and drop it from all in-kernel
users.

If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant, so there's no reason to use WQ_NON_REENTRANT.

Some of the conversions in this patch aren't trivial.

* WQ_UNBOUND | WQ_NON_REENTRANT workqueues w/ max_active == 1 are
  converted to alloc_ordered_workqueue().

* NFC was using a lot of WQ_UNBOUND | WQ_NON_REENTRANT |
  WQ_MEM_RECLAIM workqueues w/ max_active == 1.  I converted them to
  alloc_ordered_workqueue() but can't understand why NFC would need
  the reclaim flag at all.  I added comments above all such
  occurrences.  If I'm missing something, please let me know;
  otherwise, please drop the flag.  Better, please try to use
  system_wq instead.

* drivers/staging/nvec doesn't seem to need its own workqueue.
  Converted to use system_wq and cancel work items on unload.  Plesae
  scream if it's wrong.

Signed-off-by: Tejun Heo 
Cc: Stefan Richter 
Cc: Daniel Vetter 
Cc: Alasdair Kergon 
Cc: Lauro Ramos Venancio 
Cc: Aloisio Almeida Jr 
Cc: Samuel Ortiz 
Cc: Julian Andres Klode 
Cc: Marc Dietrich 
Cc: Rob Clark 
Cc: Christine Caulfield 
Cc: Steven Whitehouse 
Cc: Christoph Hellwig 
Cc: Sage Weil 
---
 Documentation/workqueue.txt |   14 ++
 drivers/firewire/core-transaction.c |3 +--
 drivers/gpu/drm/i915/i915_dma.c |6 ++
 drivers/md/dm-crypt.c   |   10 ++
 drivers/md/dm-kcopyd.c  |3 +--
 drivers/md/dm-raid1.c   |3 +--
 drivers/md/dm.c |3 +--
 drivers/mmc/host/dw_mmc.c   |3 +--
 drivers/nfc/pn533.c |5 ++---
 drivers/staging/nvec/nvec.c |   10 --
 drivers/staging/nvec/nvec.h |2 --
 drivers/staging/omapdrm/omap_drv.c  |3 +--
 fs/dlm/ast.c|5 +
 fs/gfs2/main.c  |2 +-
 fs/xfs/xfs_super.c  |2 +-
 kernel/workqueue.c  |3 +++
 net/ceph/messenger.c|2 +-
 net/nfc/core.c  |6 +++---
 net/nfc/hci/core.c  |8 
 net/nfc/hci/shdlc.c |4 ++--
 net/nfc/llcp/llcp.c |   18 ++
 21 files changed, 40 insertions(+), 75 deletions(-)

diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt
index a6ab4b6..1fb8813 100644
--- a/Documentation/workqueue.txt
+++ b/Documentation/workqueue.txt
@@ -100,8 +100,8 @@ Subsystems and drivers can create and queue work items 
through special
 workqueue API functions as they see fit. They can influence some
 aspects of the way the work items are executed by setting flags on the
 workqueue they are putting the work item on. These flags include
-things like CPU locality, reentrancy, concurrency limits, priority and
-more.  To get a detailed overview refer to the API description of
+things like CPU locality, concurrency limits, priority and more.  To
+get a detailed overview refer to the API description of
 alloc_workqueue() below.
 
 When a work item is queued to a workqueue, the target gcwq and
@@ -166,16 +166,6 @@ resources, scheduled and executed.
 
 @flags:
 
-  WQ_NON_REENTRANT
-
-   By default, a wq guarantees non-reentrance only on the same
-   CPU.  A work item may not be executed concurrently on the same
-   CPU by multiple workers but is allowed to be executed
-   concurrently on multiple CPUs.  This flag makes sure
-   non-reentrance is enforced across all CPUs.  Work items queued
-   to a non-reentrant wq are guaranteed to be executed by at most
-   one worker system-wide at any given time.
-
   WQ_UNBOUND
 
Work items queued to an unbound wq are served by a special
diff --git a/drivers/firewire/core-transaction.c 
b/drivers/firewire/core-transaction.c
index 87d6f2d..45acc0f 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -1257,8 +1257,7 @@ static int __init fw_core_init(void)
 {
int ret;
 
-   fw_workqueue = alloc_workqueue("firewire",
-  WQ_NON_REENTRANT | WQ_MEM_RECLAIM, 0);
+   fw_workqueue = alloc_workqueue("firewire", WQ_MEM_RECLAIM, 0);
if (!fw_workqueue)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9cf7dfe..a55ca7a 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1536,11 +1536,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 *
 * All tasks on the workqueue are expected to acquire the dev mutex
 * so there is no point in running more than one instance of the
-* workqueue at any time: max_active = 1 and NON_REENTRANT.
+* workqueue at any time.  Use an ordered one.
 */
-   dev_priv->wq 

[PATCH 5/6] workqueue: deprecate system_nrt[_freezable]_wq

[Tejun Heo]

system_nrt[_freezable]_wq are now spurious.  Mark them deprecated and
convert all users to system[_freezable]_wq.

If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant, so there's no reason to use system_nrt[_freezable]_wq.
Please use system[_freezable]_wq instead.

This patch doesn't make any functional difference.

Signed-off-by: Tejun Heo 
Cc: Jens Axboe 
Cc: David Airlie 
Cc: Jiri Kosina 
Cc: "David S. Miller" 
Cc: Rusty Russell 
Cc: "Paul E. McKenney" 
Cc: David Howells 
---
 block/blk-throttle.c  |7 +++
 block/genhd.c |   10 +-
 drivers/gpu/drm/drm_crtc_helper.c |6 +++---
 drivers/hid/hid-wiimote-ext.c |2 +-
 drivers/mmc/core/host.c   |4 ++--
 drivers/net/virtio_net.c  |   12 ++--
 include/linux/workqueue.h |4 ++--
 kernel/srcu.c |4 ++--
 security/keys/gc.c|8 
 security/keys/key.c   |2 +-
 10 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 3d3dcae..a9664fa 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -180,7 +180,7 @@ static inline unsigned int total_nr_queued(struct 
throtl_data *td)
 
 /*
  * Worker for allocating per cpu stat for tgs. This is scheduled on the
- * system_nrt_wq once there are some groups on the alloc_list waiting for
+ * system_wq once there are some groups on the alloc_list waiting for
  * allocation.
  */
 static void tg_stats_alloc_fn(struct work_struct *work)
@@ -194,8 +194,7 @@ alloc_stats:
stats_cpu = alloc_percpu(struct tg_stats_cpu);
if (!stats_cpu) {
/* allocation failed, try again after some time */
-   queue_delayed_work(system_nrt_wq, dwork,
-  msecs_to_jiffies(10));
+   schedule_delayed_work(dwork, msecs_to_jiffies(10));
return;
}
}
@@ -238,7 +237,7 @@ static void throtl_pd_init(struct blkcg_gq *blkg)
 */
spin_lock_irqsave(_stats_alloc_lock, flags);
list_add(>stats_alloc_node, _stats_alloc_list);
-   queue_delayed_work(system_nrt_wq, _stats_alloc_work, 0);
+   schedule_delayed_work(_stats_alloc_work, 0);
spin_unlock_irqrestore(_stats_alloc_lock, flags);
 }
 
diff --git a/block/genhd.c b/block/genhd.c
index 5d8b44a..a2f3d6a 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -1490,9 +1490,9 @@ static void __disk_unblock_events(struct gendisk *disk, 
bool check_now)
intv = disk_events_poll_jiffies(disk);
set_timer_slack(>dwork.timer, intv / 4);
if (check_now)
-   queue_delayed_work(system_nrt_freezable_wq, >dwork, 0);
+   queue_delayed_work(system_freezable_wq, >dwork, 0);
else if (intv)
-   queue_delayed_work(system_nrt_freezable_wq, >dwork, intv);
+   queue_delayed_work(system_freezable_wq, >dwork, intv);
 out_unlock:
spin_unlock_irqrestore(>lock, flags);
 }
@@ -1535,7 +1535,7 @@ void disk_flush_events(struct gendisk *disk, unsigned int 
mask)
spin_lock_irq(>lock);
ev->clearing |= mask;
if (!ev->block)
-   mod_delayed_work(system_nrt_freezable_wq, >dwork, 0);
+   mod_delayed_work(system_freezable_wq, >dwork, 0);
spin_unlock_irq(>lock);
 }
 
@@ -1571,7 +1571,7 @@ unsigned int disk_clear_events(struct gendisk *disk, 
unsigned int mask)
 
/* uncondtionally schedule event check and wait for it to finish */
disk_block_events(disk);
-   queue_delayed_work(system_nrt_freezable_wq, >dwork, 0);
+   queue_delayed_work(system_freezable_wq, >dwork, 0);
flush_delayed_work(>dwork);
__disk_unblock_events(disk, false);
 
@@ -1608,7 +1608,7 @@ static void disk_events_workfn(struct work_struct *work)
 
intv = disk_events_poll_jiffies(disk);
if (!ev->block && intv)
-   queue_delayed_work(system_nrt_freezable_wq, >dwork, intv);
+   queue_delayed_work(system_freezable_wq, >dwork, intv);
 
spin_unlock_irq(>lock);
 
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..8fa9d52 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -968,7 +968,7 @@ static void output_poll_execute(struct work_struct *work)
}
 
if (repoll)
-   queue_delayed_work(system_nrt_wq, delayed_work, 
DRM_OUTPUT_POLL_PERIOD);
+   schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
 void drm_kms_helper_poll_disable(struct drm_device *dev)
@@ -993,7 +993,7 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
}
 
if (poll)
-   queue_delayed_work(system_nrt_wq, 
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
+   

[PATCH 2/6] workqueue: gut flush[_delayed]_work_sync()

[Tejun Heo]

Now that all workqueues are non-reentrant, flush[_delayed]_work_sync()
are equivalent to flush[_delayed]_work().  Drop the separate
implementation and make them thin wrappers around
flush[_delayed]_work().

* start_flush_work() no longer takes @wait_executing as the only left
  user - flush_work() - always sets it to %true.

* __cancel_work_timer() uses flush_work() instead of wait_on_work().

Signed-off-by: Tejun Heo 
---
 include/linux/workqueue.h |   14 +-
 kernel/workqueue.c|  122 -
 2 files changed, 22 insertions(+), 114 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 6cd8f91..b2716b6 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -412,11 +412,9 @@ extern int keventd_up(void);
 int execute_in_process_context(work_func_t fn, struct execute_work *);
 
 extern bool flush_work(struct work_struct *work);
-extern bool flush_work_sync(struct work_struct *work);
 extern bool cancel_work_sync(struct work_struct *work);
 
 extern bool flush_delayed_work(struct delayed_work *dwork);
-extern bool flush_delayed_work_sync(struct delayed_work *work);
 extern bool cancel_delayed_work(struct delayed_work *dwork);
 extern bool cancel_delayed_work_sync(struct delayed_work *dwork);
 
@@ -441,6 +439,18 @@ static inline bool __deprecated 
__cancel_delayed_work(struct delayed_work *work)
return ret;
 }
 
+/* used to be different but now identical to flush_work(), deprecated */
+static inline bool flush_work_sync(struct work_struct *work)
+{
+   return flush_work(work);
+}
+
+/* used to be different but now identical to flush_delayed_work(), deprecated 
*/
+static inline bool flush_delayed_work_sync(struct delayed_work *dwork)
+{
+   return flush_delayed_work(dwork);
+}
+
 #ifndef CONFIG_SMP
 static inline long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
 {
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 26f048b..938adc0 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2780,8 +2780,7 @@ reflush:
 }
 EXPORT_SYMBOL_GPL(drain_workqueue);
 
-static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
-bool wait_executing)
+static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr)
 {
struct worker *worker = NULL;
struct global_cwq *gcwq;
@@ -2803,13 +2802,12 @@ static bool start_flush_work(struct work_struct *work, 
struct wq_barrier *barr,
cwq = get_work_cwq(work);
if (unlikely(!cwq || gcwq != cwq->pool->gcwq))
goto already_gone;
-   } else if (wait_executing) {
+   } else {
worker = find_worker_executing_work(gcwq, work);
if (!worker)
goto already_gone;
cwq = worker->current_cwq;
-   } else
-   goto already_gone;
+   }
 
insert_wq_barrier(cwq, barr, work, worker);
spin_unlock_irq(>lock);
@@ -2836,15 +2834,8 @@ already_gone:
  * flush_work - wait for a work to finish executing the last queueing instance
  * @work: the work to flush
  *
- * Wait until @work has finished execution.  This function considers
- * only the last queueing instance of @work.  If @work has been
- * enqueued across different CPUs on a non-reentrant workqueue or on
- * multiple workqueues, @work might still be executing on return on
- * some of the CPUs from earlier queueing.
- *
- * If @work was queued only on a non-reentrant, ordered or unbound
- * workqueue, @work is guaranteed to be idle on return if it hasn't
- * been requeued since flush started.
+ * Wait until @work has finished execution.  @work is guaranteed to be idle
+ * on return if it hasn't been requeued since flush started.
  *
  * RETURNS:
  * %true if flush_work() waited for the work to finish execution,
@@ -2857,85 +2848,15 @@ bool flush_work(struct work_struct *work)
lock_map_acquire(>lockdep_map);
lock_map_release(>lockdep_map);
 
-   if (start_flush_work(work, , true)) {
+   if (start_flush_work(work, )) {
wait_for_completion();
destroy_work_on_stack();
return true;
-   } else
-   return false;
-}
-EXPORT_SYMBOL_GPL(flush_work);
-
-static bool wait_on_cpu_work(struct global_cwq *gcwq, struct work_struct *work)
-{
-   struct wq_barrier barr;
-   struct worker *worker;
-
-   spin_lock_irq(>lock);
-
-   worker = find_worker_executing_work(gcwq, work);
-   if (unlikely(worker))
-   insert_wq_barrier(worker->current_cwq, , work, worker);
-
-   spin_unlock_irq(>lock);
-
-   if (unlikely(worker)) {
-   wait_for_completion();
-   destroy_work_on_stack();
-   return true;
-   } else
+   } else {
return false;
-}
-
-static bool wait_on_work(struct work_struct *work)
-{
-   bool 

[PATCHSET] workqueue: make all workqueues non-reentrant

[Tejun Heo]

Hello,

Unless explicitly specified, a workqueued is reentrant, which might
not even be the correct term.  If a work item is executing on a CPU
but not pending anywhere, the work item can be queued on a different
CPU, and that CPU might start executing the work item whether the
previous execution on the first CPU is finished or not.  In short,
while a work item can be queued on only one CPU, it may be executing
concurrently on any subset of the CPUs in the system.

This behavior in itself is already confusing and error-prone; however,
this causes much worse complication in flush operations.  Because a
given work item could be executing on any number of CPUs, even if no
further queueing happens after invocation, flush_work() can't
guarantee that the work item is idle on return without checking all
CPUs.  Being a relatively common operation, checking all CPUs on each
invocation was deemed too costly.  It only verifies the instance
queued last and there's a separate version which checks all CPUs -
flush_work_sync().

Also, due to the way last CPU is tracked, if there are parallel
queueing operations, the following sequence

schedule_work(A);
flush_work(A);

can't guarantee that the instance queued right above is finished.  If
someone else queues A on another CPU inbetween, flush_work() either
becomes noop or flushes that instance which may finish earlier than
the one from the above.

In the end, workqueue is a pain in the ass to get completely correct
and the breakages are very subtle.  Depending on queueing pattern,
assuming non-reentrancy might work fine most of the time.  The effect
of using flush_work() where flush_work_sync() should be used could be
a lot more subtle.  flush_work() becoming noop would happen extremely
rarely for most users but it definitely is there.

A tool which is used as widely as workqueue shouldn't be this
difficult and error-prone.  This is just silly.

Timer does the right thing.  It *always* checks whether a timer is
still executing on the previous CPU and queues it there if so much
like how WQ_NON_REENTRANT makes workqueue behave.  WQ_NON_REENTRANT
guarantees that any given work item is executing on only one CPU at
maximum and if both pending and executing, both are on the same CPU.
This makes the behaviors of work item execution and flush_work() much
more sane and flush_work_sync() unnecessary.

This patchset enforces WQ_NON_REENTRANT behavior on all workqueues and
simplifies workqueue API accordingly.

This adds an additional busy_hash lookup if the work item was
previously queued on a different CPU.  This shouldn't be noticeable
under any sane workload.  Work item queueing isn't a very
high-frequency operation and they don't jump across CPUs all the time.
In a micro benchmark to exaggerate this difference - measuring the
time it takes for two work items to repeatedly jump between two CPUs a
number (10M) of times with busy_hash table densely populated, the
difference was around 3%.

While the overhead is measureable, it is only visible in pathological
cases and the difference isn't huge.  This change brings much needed
sanity to workqueue and makes its behavior consistent with timer.  I
think this is the right tradeoff to make.

This patchset contains the following six patches.

 0001-workqueue-make-all-workqueues-non-reentrant.patch
 0002-workqueue-gut-flush-_delayed-_work_sync.patch
 0003-workqueue-gut-system_nrt-_freezable-_wq.patch
 0004-workqueue-deprecate-flush-_delayed-_work_sync.patch
 0005-workqueue-deprecate-system_nrt-_freezable-_wq.patch
 0006-workqueue-deprecate-WQ_NON_REENTRANT.patch

0001 makes all workqueues non-reentrant.

0002-0003 simplify workqueue API accordingly.

0004-0006 deprecate now unnecessary parts of workqueue API and convert
their users.  Most conversions are straight-forward but 0006 contains
some non-trivial ones.  If you work on NFC and drivers/staging/nvec,
please review them.

This patchset is on top of

  wq/for-3.7 1265057fa02c7bed3b6d9ddc8a2048065a370364
+ [1] "timer: clean up initializers and implement irqsafe" patchset
+ [2] "workqueue: use irqsafe timer in delayed_work" patchset

and available in the following git branch.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git review-wq-always-nrt

Thanks.  diffstat follows.

 Documentation/workqueue.txt |   14 --
 arch/arm/mach-pxa/sharpsl_pm.c  |4 
 arch/arm/plat-omap/mailbox.c|2 
 arch/sh/drivers/push-switch.c   |2 
 block/blk-throttle.c|7 -
 block/genhd.c   |   10 -
 drivers/block/xen-blkfront.c|4 
 drivers/cdrom/gdrom.c   |2 
 drivers/char/sonypi.c   |2 
 drivers/char/tpm/tpm.c  |4 
 drivers/firewire/core-transaction.c |3 
 drivers/gpu/drm/drm_crtc_helper.c   |6 
 

Re: [PATCH V2 06/18] Tools: hv: Further refactor kvp_get_ip_address()

[Ben Hutchings]

On Mon, 2012-08-13 at 10:06 -0700, K. Y. Srinivasan wrote:
> In preparation for making kvp_get_ip_address() more generic, factor out
> the code for handling IP addresses.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> Reviewed-by: Olaf Hering 
> Reviewed-by: Ben Hutchings 

I looked at your last patch set, so in a sense these have been reviewed
by me.  But the 'Reviewed-by' line in a commit message means the
reviewer thinks it's OK; the reviewer must say that, and I didn't.

Ben.

> ---
>  tools/hv/hv_kvp_daemon.c |   94 -
>  1 files changed, 42 insertions(+), 52 deletions(-)
> 
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index 3af37f0..3dc989f 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -491,17 +491,50 @@ done:
>   return;
>  }
>  
> +static int kvp_process_ip_address(void *addrp,
> + int family, char *buffer,
> + int length,  int *offset)
> +{
> + struct sockaddr_in *addr;
> + struct sockaddr_in6 *addr6;
> + int addr_length;
> + char tmp[50];
> + const char *str;
> +
> + if (family == AF_INET) {
> + addr = (struct sockaddr_in *)addrp;
> + str = inet_ntop(family, >sin_addr, tmp, 50);
> + addr_length = INET_ADDRSTRLEN;
> + } else {
> + addr6 = (struct sockaddr_in6 *)addrp;
> + str = inet_ntop(family, >sin6_addr.s6_addr, tmp, 50);
> + addr_length = INET6_ADDRSTRLEN;
> + }
> +
> + if ((length - *offset) < addr_length + 1)
> + return 1;
> + if (str == NULL) {
> + strcpy(buffer, "inet_ntop failed\n");
> + return 1;
> + }
> + if (*offset == 0)
> + strcpy(buffer, tmp);
> + else
> + strcat(buffer, tmp);
> + strcat(buffer, ";");
> +
> + *offset += strlen(str) + 1;
> + return 0;
> +}
> +
>  static int
>  kvp_get_ip_address(int family, char *if_name, int op,
>void  *out_buffer, int length)
>  {
>   struct ifaddrs *ifap;
>   struct ifaddrs *curp;
> - int ipv4_len = strlen("255.255.255.255") + 1;
> - int ipv6_len = strlen(":::::::")+1;
>   int offset = 0;
>   const char *str;
> - char tmp[50];
>   int error = 0;
>   char *buffer;
>   struct hv_kvp_ipaddr_value *ip_buffer;
> @@ -556,55 +589,12 @@ kvp_get_ip_address(int family, char *if_name, int op,
>   continue;
>   }
>  
> - if ((curp->ifa_addr->sa_family == AF_INET) &&
> - ((family == AF_INET) || (family == 0))) {
> - struct sockaddr_in *addr =
> - (struct sockaddr_in *) curp->ifa_addr;
> -
> - str = inet_ntop(AF_INET, >sin_addr, tmp, 50);
> - if (str == NULL) {
> - strcpy(buffer, "inet_ntop failed\n");
> - error = 1;
> - goto getaddr_done;
> - }
> - if (offset == 0)
> - strcpy(buffer, tmp);
> - else
> - strcat(buffer, tmp);
> - strcat(buffer, ";");
> -
> - offset += strlen(str) + 1;
> - if ((length - offset) < (ipv4_len + 1))
> - goto getaddr_done;
> -
> - } else if ((family == AF_INET6) || (family == 0)) {
> -
> - /*
> -  * We only support AF_INET and AF_INET6
> -  * and the list of addresses is separated by a ";".
> -  */
> - struct sockaddr_in6 *addr =
> - (struct sockaddr_in6 *) curp->ifa_addr;
> -
> - str = inet_ntop(AF_INET6,
> - >sin6_addr.s6_addr,
> - tmp, 50);
> - if (str == NULL) {
> - strcpy(buffer, "inet_ntop failed\n");
> - error = 1;
> - goto getaddr_done;
> - }
> - if (offset == 0)
> - strcpy(buffer, tmp);
> - else
> - strcat(buffer, tmp);
> - strcat(buffer, ";");
> - offset += strlen(str) + 1;
> - if ((length - offset) < (ipv6_len + 1))
> - goto getaddr_done;
> -
> - }
> -
> + error = kvp_process_ip_address(curp->ifa_addr,
> + curp->ifa_addr->sa_family,
> + buffer,
> + length, );
> 

[PATCH v3 1/1] HID:hid-multitouch: Add ELAN production request when resume.

[Scott Liu]

Add ELAN production request when resume

Signed-off-by: Scott Liu 
Suggested-off-by: Benjamin Tissoires 
---
 drivers/hid/hid-multitouch.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 59c8b5c..e824c37 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -767,6 +767,32 @@ static int mt_reset_resume(struct hid_device *hdev)
mt_set_input_mode(hdev);
return 0;
 }
+
+static int mt_resume(struct hid_device *hdev)
+{
+   struct usb_interface *intf;
+   struct usb_host_interface *interface;
+   struct usb_device *dev;
+
+   if (hdev->bus != BUS_USB)
+   return 0;
+
+   intf = to_usb_interface(hdev->dev.parent);
+   interface = intf->cur_altsetting;
+   dev = hid_to_usb_dev(hdev);
+
+   /* Some Elan legacy devices require SET_IDLE to be set on resume.
+* It should be safe to send it to other devices too.
+* Tested on 3M, Stantum, Cypress, Zytronic, eGalax, and Elan panels. */
+
+   usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+   HID_REQ_SET_IDLE,
+   USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+   0, interface->desc.bInterfaceNumber,
+   NULL, 0, USB_CTRL_SET_TIMEOUT);
+
+   return 0;
+}
 #endif
 
 static void mt_remove(struct hid_device *hdev)
@@ -1092,6 +1118,7 @@ static struct hid_driver mt_driver = {
.event = mt_event,
 #ifdef CONFIG_PM
.reset_resume = mt_reset_resume,
+   .resume = mt_resume,
 #endif
 };
 
-- 
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] drivers/media/video/mx2_emmaprp.c: use devm_kzalloc and devm_clk_get

[Mauro Carvalho Chehab]

Em 13-08-2012 17:20, Julia Lawall escreveu:
> From: Julia Lawall 
> 
> Using devm_kzalloc simplifies the code and ensures that the use of
> devm_request_irq is safe.  When kzalloc and kfree were used, the interrupt
> could be triggered after the handler's data argument had been freed.
> 
> This also introduces some missing initializations of the return variable
> ret, and uses devm_request_and_ioremap instead of the combination of
> devm_request_mem_region and devm_ioremap.
> 
> The problem of a free after a devm_request_irq was found using the
> following semantic match (http://coccinelle.lip6.fr/)
> 
> // 
> @r exists@
> expression e1,e2,x,a,b,c,d;
> identifier free;
> position p1,p2;
> @@
> 
>   devm_request_irq@p1(e1,e2,...,x)
>   ... when any
>   when != e2 = a
>   when != x = b
>   if (...) {
> ... when != e2 = c
> when != x = d
> free@p2(...,x,...);
> ...
> return ...;
>   }
> // 
> 
> Signed-off-by: Julia Lawall 
> 
> ---
> v3: due to a conflict with another patch

Not sure what tree you used for it, but the result was
worse ;)

patching file drivers/media/video/mx2_emmaprp.c
Hunk #1 FAILED at 896.
Hunk #2 FAILED at 904.
Hunk #3 FAILED at 946.
Hunk #4 FAILED at 993.
Hunk #5 FAILED at 1009.
5 out of 5 hunks FAILED -- rejects in file drivers/media/video/mx2_emmaprp.c

Well, I've massively applied hundreds of patches today, but not much
on this driver. Maybe it is better for you to wait for a couple of
days for these to be at -next, or use, instead, our tree as the basis for
it:
git://linuxtv.org/media_tree.git staging/for_v3.7

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 02/18] Drivers: hv: Add KVP definitions for IP address injection

[Greg KH]

On Mon, Aug 13, 2012 at 10:06:51AM -0700, K. Y. Srinivasan wrote:
> Add the necessary definitions for supporting the IP injection functionality.
> 
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-by: Haiyang Zhang 
> Reviewed-by: Olaf Hering 
> Reviewed-by: Ben Hutchings 
> ---
>  drivers/hv/hv_util.c |4 +-
>  include/linux/hyperv.h   |   76 -
>  tools/hv/hv_kvp_daemon.c |2 +-
>  3 files changed, 77 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index d3ac6a4..a0667de 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -263,7 +263,7 @@ static int util_probe(struct hv_device *dev,
>   (struct hv_util_service *)dev_id->driver_data;
>   int ret;
>  
> - srv->recv_buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + srv->recv_buffer = kmalloc(PAGE_SIZE * 2, GFP_KERNEL);
>   if (!srv->recv_buffer)
>   return -ENOMEM;
>   if (srv->util_init) {
> @@ -274,7 +274,7 @@ static int util_probe(struct hv_device *dev,
>   }
>   }
>  
> - ret = vmbus_open(dev->channel, 2 * PAGE_SIZE, 2 * PAGE_SIZE, NULL, 0,
> + ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
>   srv->util_cb, dev->channel);
>   if (ret)
>   goto error;
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 68ed7f7..11afc4e 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -122,12 +122,53 @@
>  #define REG_U32 4
>  #define REG_U64 8
>  
> +/*
> + * As we look at expanding the KVP functionality to include
> + * IP injection functionality, we need to maintain binary
> + * compatibility with older daemons.
> + *
> + * The KVP opcodes are defined by the host and it was unfortunate
> + * that I chose to treat the registration operation as part of the
> + * KVP operations defined by the host.
> + * Here is the level of compatibility
> + * (between the user level daemon and the kernel KVP driver) that we
> + * will implement:
> + *
> + * An older daemon will always be supported on a newer driver.
> + * A given user level daemon will require a minimal version of the
> + * kernel driver.
> + * If we cannot handle the version differences, we will fail gracefully
> + * (this can happen when we have a user level daemon that is more
> + * advanced than the KVP driver.
> + *
> + * We will use values used in this handshake for determining if we have
> + * workable user level daemon and the kernel driver. We begin by taking the
> + * registration opcode out of the KVP opcode namespace. We will however,
> + * maintain compatibility with the existing user-level daemon code.
> + */
> +
> +/*
> + * Daemon code not supporting IP injection (legacy daemon).
> + */
> +
> +#define KVP_OP_REGISTER  4

Huh?

> +/*
> + * Daemon code supporting IP injection.
> + * The KVP opcode field is used to communicate the
> + * registration information; so define a namespace that
> + * will be distinct from the host defined KVP opcode.
> + */
> +
> +#define KVP_OP_REGISTER1 100
> +
>  enum hv_kvp_exchg_op {
>   KVP_OP_GET = 0,
>   KVP_OP_SET,
>   KVP_OP_DELETE,
>   KVP_OP_ENUMERATE,
> - KVP_OP_REGISTER,
> + KVP_OP_GET_IP_INFO,
> + KVP_OP_SET_IP_INFO,

So you overloaded the command and somehow think that is ok?  How is that
supposed to work?  Why not just always keep it there, but fail if it is
called as you know you have a mismatch?

Otherwise, again, you just broke older tools on a newer kernel.

Or am I missing something here?

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 1/2 v2] staging: comedi: new adl_pci7x3x driver

[H Hartley Sweeten]

On Monday, August 13, 2012 6:30 PM, Greg KH wrote:
> On Fri, Aug 03, 2012 at 10:28:18AM -0700, H Hartley Sweeten wrote:
>> Currently the ADLink PCI-7230 and PCI-7432 Isolated Digital
>> I/O Boards are supported using two drivers (adl_pci7230 and
>> adl_pci7432). These drivers are very similar and only differ
>> in the total number of di/do channels provided.
>> 
>> This driver combines the support for both boards into one
>> common driver. In addition, it adds PCI PnP support for the
>> other boards in the ADLink PCI-723x and PCI-743x series.
>> 
>> This driver only supports the comedi PCI auto config attach
>> mechanism. The legacy attach using the comedi_config utility
>> is not supported or required by this driver.
>
> I now get the following build warnings on my box with this patch
> applied:
>
> drivers/staging/comedi/drivers/adl_pci7x3x.c: In function 
> ‘adl_pci7x3x_do_insn_bits’:
> drivers/staging/comedi/drivers/adl_pci7x3x.c:124:21: warning: cast from 
> pointer to integer of different size [-Wpointer-to-int-cast]
> drivers/staging/comedi/drivers/adl_pci7x3x.c: In function 
> ‘adl_pci7x3x_di_insn_bits’:
> drivers/staging/comedi/drivers/adl_pci7x3x.c:150:21: warning: cast from 
> pointer to integer of different size [-Wpointer-to-int-cast]

Hmm.. My build does not have the [-Wpointer-to-int-cast] for some reason
so I didn't see this. I was trying to save having to allocate any private data 
but
I guess it's cleaner if I do.  BTW, there is another comedi driver that does 
this
but I can't recall which one of the top of my head...

> Care to send a follow-on patch to fix this up?

Not a problem.

Thanks,
Hartley
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH RFT 1/2] gpio: gpio-ml-ioh: Use spinlock for register access protection

[Feng Tang]

On Mon, 13 Aug 2012 14:01:31 +0200
Linus Walleij  wrote:

> On Sun, Jul 29, 2012 at 4:54 AM, Axel Lin  wrote:
> 
> > gpio_chip.can_sleep is 0, but current code uses mutex in ioh_gpio_set,
> > ioh_gpio_get and ioh_gpio_direction_input functions.
> > Thus those functions are not callable from interrupt context.
> > This patch converts mutex into spinlock.
> >
> > Signed-off-by: Axel Lin 
> 
> So IOH guys what are you saying about this?

I'm not the IOH guy, but just happened to work on it for some time :) Anyway,
the 2 patches both look good to me.

Thanks,
Feng

--
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 v2] staging: comedi: new adl_pci7x3x driver

[Greg KH]

On Fri, Aug 03, 2012 at 10:28:18AM -0700, H Hartley Sweeten wrote:
> Currently the ADLink PCI-7230 and PCI-7432 Isolated Digital
> I/O Boards are supported using two drivers (adl_pci7230 and
> adl_pci7432). These drivers are very similar and only differ
> in the total number of di/do channels provided.
> 
> This driver combines the support for both boards into one
> common driver. In addition, it adds PCI PnP support for the
> other boards in the ADLink PCI-723x and PCI-743x series.
> 
> This driver only supports the comedi PCI auto config attach
> mechanism. The legacy attach using the comedi_config utility
> is not supported or required by this driver.

I now get the following build warnings on my box with this patch
applied:

drivers/staging/comedi/drivers/adl_pci7x3x.c: In function 
‘adl_pci7x3x_do_insn_bits’:
drivers/staging/comedi/drivers/adl_pci7x3x.c:124:21: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]
drivers/staging/comedi/drivers/adl_pci7x3x.c: In function 
‘adl_pci7x3x_di_insn_bits’:
drivers/staging/comedi/drivers/adl_pci7x3x.c:150:21: warning: cast from pointer 
to integer of different size [-Wpointer-to-int-cast]

Care to send a follow-on patch to fix this 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 1/1] boot: Put initcall_debug into its own Kconfig option DEBUG_INITCALL

[Josh Triplett]

On Mon, Aug 13, 2012 at 03:39:54PM -0700, Randy Dunlap wrote:
> On 08/13/2012 03:08 PM, Thai Bui wrote:
> >Hi all,
> >
> >I am as part of a capstone group at Portland State University is working
> >to tinify the kernel as small as possible. The ultimate goal is to make
> >the kernel small enough to use on micro-controller (or under < 200k).
> >This patch is one of them, it saves 176 bytes on a minimal configuration
> >of the kernel (the bzImage file was reduced from 363264 bytes to 363264
> >bytes applying this patch).
> >
> >Aside from the purpose of reducing the size of the kernel. We are also
> >trying to clean up the kernel by making Kconfig options to compile out
> >the stuffs that aren't used often.
> 
> IMO the kernel already has too many kconfig options.
> 
> Also, personally I would not merge a patch that saves so little memory,
> especially on what I consider a very useful option.

I think Thai undersold his patch significantly; the *compressed* size
went down by 176 bytes, and the uncompressed size went down more than
that.  And that's the savings starting from a very minimal kernel, not
starting from a defconfig kernel.

In any case, do you object to the introduction of a Kconfig option at
all, or to that option defaulting to off?  In particular, would you
object if the option only showed up if EMBEDDED, and defaulted to y?  At
that point, you could reasonably expect that most users and distros will
have it enabled, so you'll be able to count on asking people to enable
it and send you the output.  Would that suffice?

The patch itself seems incredibly straightforward and non-invasive to
me; it just stubs out the global variable and lets GCC fold away all the
code.

At this point, the kernel is running out of major things to cut out to
save space; getting from ~200k (the current smallest kernel possible) to
much less than that will require a pile of patches that save anywhere
from a few hundred bytes to a few kilobytes.  I certainly agree that
those patches need to avoid introducing too much complexity.  However, I
don't think it makes sense to object to a patch that saves space solely
on the grounds that it doesn't save *more* space.  That would make it
impossible to cut out small things, and small things add up.

- Josh Triplett
--
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 2/2] apple_gmux: Add support for newer hardware

[Seth Forshee]

On Mon, Aug 13, 2012 at 06:52:49PM -0400, Matthew Garrett wrote:
> New gmux devices have a different method for accessing the registers.
> Update the driver to cope. Incorporates feedback from Bernhard Froemel.
> 
> Signed-off-by: Matthew Garrett 
> Cc: Bernhard Froemel 
> Cc: Seth Forshee 

Acked-by: Seth Forshee 

--
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 1/2] gmux: Add generic write32 function

[Seth Forshee]

On Mon, Aug 13, 2012 at 06:52:48PM -0400, Matthew Garrett wrote:
> Move the special-cased backlight update function to a generic gmux_write32
> function.
> 
> Signed-off-by: Matthew Garrett 
> Cc: Seth Forshee 

Acked-by: Seth Forshee 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for July 26 (uml)

[Rusty Russell]

On Mon, 13 Aug 2012 10:00:16 -0700, Randy Dunlap  wrote:
> On 07/26/2012 08:18 AM, Randy Dunlap wrote:
> 
> > On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
> > 
> >> Hi all,
> >>
> >> Please do not add anything to linux-next included branches/series that is
> >> destined for v3.7 until after v3.6-rc1 is released.
> >>
> >> Reminder: do not rebase your branches before asking Linus to pull them ...
> >>
> >> Changes since 20120725:
> >>
> > 
> > 
> > 
> > uml on x86_64 (defconfig) build fails with:
> > 
> >   CC  arch/x86/um/../kernel/module.o
> > arch/x86/um/../kernel/module.c:96:5: error: redefinition of 
> > 'apply_relocate_add'
> > include/linux/moduleloader.h:64:19: note: previous definition of 
> > 'apply_relocate_add' was here
> > make[2]: *** [arch/x86/um/../kernel/module.o] Error 1
> > 
> > 
> > 
> 
> 
> 
> Adding Rusty.
> 
> 
> This build error is still happening for uml on x86_64
> in linux-next 20120813.

No huge surprise, I'll punt this to David Howells :)

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 2/4] virtio_balloon: introduce migration primitives to balloon pages

[Rusty Russell]

On Mon, 13 Aug 2012 11:41:23 +0300, "Michael S. Tsirkin"  
wrote:
> On Fri, Aug 10, 2012 at 02:55:15PM -0300, Rafael Aquini wrote:
> > +/*
> > + * Populate balloon_mapping->a_ops->freepage method to help compaction on
> > + * re-inserting an isolated page into the balloon page list.
> > + */
> > +void virtballoon_putbackpage(struct page *page)
> > +{
> > +   spin_lock(_lock);
> > +   list_add(>lru, _ptr->pages);
> > +   spin_unlock(_lock);
> 
> Could the following race trigger:
> migration happens while module unloading is in progress,
> module goes away between here and when the function
> returns, then code for this function gets overwritten?
> If yes we need locking external to module to prevent this.
> Maybe add a spinlock to struct address_space?

The balloon module cannot be unloaded until it has leaked all its pages,
so I think this is safe:

static void remove_common(struct virtio_balloon *vb)
{
/* There might be pages left in the balloon: free them. */
while (vb->num_pages)
leak_balloon(vb, vb->num_pages);

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: fix module.c build for 32 bit

[Rusty Russell]

On Mon, 13 Aug 2012 16:39:42 +0100, David Howells  wrote:
> 
> Hi Rusty,
> 
> I've fixed up my patch for ARM and pulled Jonas's patch on top of that.  Do
> you want me to merge them together?

Yep, thanks.  And might as well sent them straight to Linus; since
linux-next didn't catch this, there's little point baking them there if
we have some acks.

If he misses it, I'll grab them.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH wq/for-3.7] workqueue: add missing wmb() in clear_work_data()

[Tejun Heo]

>From 23657bb192f14b789e4c478def8f11ecc95b4f6c Mon Sep 17 00:00:00 2001
From: Tejun Heo 
Date: Mon, 13 Aug 2012 17:08:19 -0700

Any operation which clears PENDING should be preceded by a wmb to
guarantee that the next PENDING owner sees all the changes made before
PENDING release.

There are only two places where PENDING is cleared -
set_work_cpu_and_clear_pending() and clear_work_data().  The caller of
the former already does smp_wmb() but the latter doesn't have any.

Move the wmb above set_work_cpu_and_clear_pending() into it and add
one to clear_work_data().

There hasn't been any report related to this issue, and, given how
clear_work_data() is used, it is extremely unlikely to have caused any
actual problems on any architecture.

Signed-off-by: Tejun Heo 
Cc: Oleg Nesterov 
---
Fix for another theoretical wmb problem.  Will push through
wq/for-3.7.

Thanks.

 kernel/workqueue.c |   19 ---
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 11723c5..4fef952 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -570,11 +570,19 @@ static void set_work_cwq(struct work_struct *work,
 static void set_work_cpu_and_clear_pending(struct work_struct *work,
   unsigned int cpu)
 {
+   /*
+* The following wmb is paired with the implied mb in
+* test_and_set_bit(PENDING) and ensures all updates to @work made
+* here are visible to and precede any updates by the next PENDING
+* owner.
+*/
+   smp_wmb();
set_work_data(work, (unsigned long)cpu << WORK_OFFQ_CPU_SHIFT, 0);
 }
 
 static void clear_work_data(struct work_struct *work)
 {
+   smp_wmb();  /* see set_work_cpu_and_clear_pending() */
set_work_data(work, WORK_STRUCT_NO_CPU, 0);
 }
 
@@ -2182,14 +2190,11 @@ __acquires(>lock)
wake_up_worker(pool);
 
/*
-* Record the last CPU and clear PENDING.  The following wmb is
-* paired with the implied mb in test_and_set_bit(PENDING) and
-* ensures all updates to @work made here are visible to and
-* precede any updates by the next PENDING owner.  Also, clear
-* PENDING inside @gcwq->lock so that PENDING and queued state
-* changes happen together while IRQ is disabled.
+* Record the last CPU and clear PENDING which should be the last
+* update to @work.  Also, do this inside @gcwq->lock so that
+* PENDING and queued state changes happen together while IRQ is
+* disabled.
 */
-   smp_wmb();
set_work_cpu_and_clear_pending(work, gcwq->cpu);
 
spin_unlock_irq(>lock);
-- 
1.7.7.3

--
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/

mmotm 2012-08-13-16-55 uploaded

[akpm]

The mm-of-the-moment snapshot 2012-08-13-16-55 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at https://github.com/mstsxfx/memcg-devel.git by Michal Hocko. 
It contains the patches which are between the "#NEXT_PATCHES_START mm" and
"#NEXT_PATCHES_END" markers, from the series file,
http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm git://git.cmpxchg.org/linux-mmotm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.6-rc1:
(patches marked "*" will be included in linux-next)

  origin.patch
  linux-next.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
* cs5535-clockevt-typo-its-mfgpt-not-mfpgt.patch
* mm-change-nr_ptes-bug_on-to-warn_on.patch
* documentation-update-mount-option-in-filesystem-vfattxt.patch
* cciss-fix-incorrect-scsi-status-reporting.patch
* 
acpi_memhotplugc-fix-memory-leak-when-memory-device-is-unbound-from-the-module-acpi_memhotplug.patch
* acpi_memhotplugc-free-memory-device-if-acpi_memory_enable_device-failed.patch
* acpi_memhotplugc-remove-memory-info-from-list-before-freeing-it.patch
* 
acpi_memhotplugc-dont-allow-to-eject-the-memory-device-if-it-is-being-used.patch
* acpi_memhotplugc-bind-the-memory-device-when-the-driver-is-being-loaded.patch
* 
acpi_memhotplugc-auto-bind-the-memory-device-which-is-hotplugged-before-the-driver-is-loaded.patch
* 
arch-x86-platform-iris-irisc-register-a-platform-device-and-a-platform-driver.patch
* arch-x86-include-asm-spinlockh-fix-comment.patch
* mn10300-only-add-mmem-funcs-to-kbuild_cflags-if-gcc-supports-it.patch
* dma-dmaengine-lower-the-priority-of-failed-to-get-dma-channel-message.patch
* pcmcia-move-unbind-rebind-into-dev_pm_opscomplete.patch
* ppc-e500_tlb-memset-clears-nothing.patch
  cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch
* timeconstpl-remove-deprecated-defined-array.patch
* time-dont-inline-export_symbol-functions.patch
* thermal-add-generic-cpufreq-cooling-implementation.patch
* hwmon-exynos4-move-thermal-sensor-driver-to-driver-thermal-directory.patch
* thermal-exynos5-add-exynos5-thermal-sensor-driver-support.patch
* thermal-exynos-register-the-tmu-sensor-with-the-kernel-thermal-layer.patch
* arm-exynos-add-thermal-sensor-driver-platform-data-support.patch
* ocfs2-use-find_last_bit.patch
* ocfs2-use-bitmap_weight.patch
* drivers-scsi-atp870uc-fix-bad-use-of-udelay.patch
* vfs-increment-iversion-when-a-file-is-truncated.patch
* fs-push-rcu_barrier-from-deactivate_locked_super-to-filesystems.patch
* mm-slab-remove-duplicate-check.patch
* slab-do-not-call-compound_head-in-page_get_cache.patch
* mm-slab_commonc-fix-warning.patch
  mm.patch
* mm-remove-__gfp_no_kswapd.patch
* remove-__gfp_no_kswapd-fixes.patch
* remove-__gfp_no_kswapd-fixes-fix.patch
* 
x86-pat-remove-the-dependency-on-vm_pgoff-in-track-untrack-pfn-vma-routines.patch
* 
x86-pat-separate-the-pfn-attribute-tracking-for-remap_pfn_range-and-vm_insert_pfn.patch
* 
x86-pat-separate-the-pfn-attribute-tracking-for-remap_pfn_range-and-vm_insert_pfn-fix.patch
* mm-x86-pat-rework-linear-pfn-mmap-tracking.patch
* 

Re: [PATCH] md/linear: rcu_dereference outside read-lock section

[NeilBrown]

On Tue, 14 Aug 2012 01:08:12 +0400 Denis Efremov 
wrote:

> According to the comment in linear_stop function
> rcu_dereference in linear_start and linear_stop functions
> occurs under reconfig_mutex. The patch represents this
> agreement in code and prevents lockdep complaint.
> 
> Found by Linux Driver Verification project (linuxtesting.org)
> 
> Signed-off-by: Denis Efremov 
> ---
>  drivers/md/linear.c |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/md/linear.c b/drivers/md/linear.c
> index fa211d8..093f3e4 100644
> --- a/drivers/md/linear.c
> +++ b/drivers/md/linear.c
> @@ -244,7 +244,8 @@ static int linear_add(struct mddev *mddev, struct md_rdev 
> *rdev)
>   if (!newconf)
>   return -ENOMEM;
>  
> - oldconf = rcu_dereference(mddev->private);
> + oldconf = rcu_dereference_protected(mddev->private,
> + 
> lockdep_is_held(>reconfig_mutex));
>   mddev->raid_disks++;
>   rcu_assign_pointer(mddev->private, newconf);
>   md_set_array_sectors(mddev, linear_size(mddev, 0, 0));
> @@ -256,7 +257,9 @@ static int linear_add(struct mddev *mddev, struct md_rdev 
> *rdev)
>  
>  static int linear_stop (struct mddev *mddev)
>  {
> - struct linear_conf *conf = mddev->private;
> + struct linear_conf *conf =
> + rcu_dereference_protected(mddev->private,
> +   
> lockdep_is_held(>reconfig_mutex));
>  
>   /*
>* We do not require rcu protection here since


Applied, thanks.

NeilBrown


signature.asc
Description: PGP signature

[GIT PULL] Update LZO compression

[Markus F.X.J. Oberhumer]

Hi all,

as suggested on the mailing list I have converted the updated LZO
code into git, so please pull my "lzo-update" branch from

  git://github.com/markus-oberhumer/linux.git lzo-update

You can browse the branch at

  https://github.com/markus-oberhumer/linux/compare/lzo-update

I'd ask some official kernel maintainer for review and to push this into
linux-next so that it will hopefully land in the 3.7 release.

Share and enjoy,
Markus

Signed-off-by: Markus F.X.J. Oberhumer 

On 2012-07-16 20:30, Markus F.X.J. Oberhumer wrote:
> Hi all,
>
> I finally have prepared a small package that updates the LZO version
> in the Linux kernel. Please get it from:
>
> http://www.oberhumer.com/opensource/lzo/download/Testing/linux-kernel-lzo-20120716.tar.gz
>
> As stated in the README this version is significantly faster (typically more
> than 2 times faster!) than the current version, has been thoroughly tested on
> x86_64/i386/powerpc platforms and is intended to get included into the
> official Linux 3.6 or 3.7 release.
>
> I encourage all compression users to test and benchmark this new version,
> and I also would ask some official LZO maintainer to convert the updated
> source files into a GIT commit and possibly push it to Linus or linux-next.
>
> Share and enjoy,
> Markus
>
> Signed-off-by: Markus F.X.J. Oberhumer" 

-- 
Markus Oberhumer, , http://www.oberhumer.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHSET] workqueue: use irqsafe timer in delayed_work

[Tejun Heo]

Hello,

On Wed, Aug 08, 2012 at 02:37:55PM -0700, Tejun Heo wrote:
> This patchset makes delayed_work use the irqsafe timer added by the
> pending "timer: clean up initializers and implement irqsafe timers"
> patchset[1].  This enables try_to_grab_pending() to be used from any
> context which in turn makes mod_delayed_work() usable from IRQ
> handlers.  cancel_delayed_work() is reimplemented using
> try_to_grab_pending() so that it also can be used from IRQ handlers
> and its behavior is consitent with other canceling operations.
> __cancel_delayed_work() is no longer necessary and deprecated.

I'll soon push this to linux-next through wq/for-3.7 together with
irqsafe timer patchset.  Plese scream if you don't like that.

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/

Re: [PATCH] [NETFILTER] bridge: rcu_deref outside read-lock section

[Stephen Hemminger]

On Tue, 14 Aug 2012 02:47:42 +0400
Denis Efremov  wrote:

> As it noted in the comment before the br_handle_frame_finish
> function, this function should be called under rcu_read_lock.
> 
> The problem callgraph:
> br_dev_xmit -> br_nf_pre_routing_finish_bridge_slow ->
> -> br_handle_frame_finish -> br_port_get_rcu -> rcu_dereference
> 
> And in this case there is no read-lock section.
> I have put lock/unlock in br_nf_pre_routing_finish_bridge_slow,
> as the only function that calls it(for now) - is br_dev_xmit.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Denis Efremov 
> ---
>  include/linux/netfilter_bridge.h |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/netfilter_bridge.h 
> b/include/linux/netfilter_bridge.h
> index 31d2844..ceb048e 100644
> --- a/include/linux/netfilter_bridge.h
> +++ b/include/linux/netfilter_bridge.h
> @@ -79,6 +79,7 @@ extern int br_handle_frame_finish(struct sk_buff *skb);
>  /* Only used in br_device.c */
>  static inline int br_nf_pre_routing_finish_bridge_slow(struct sk_buff *skb)
>  {
> + int res;
>   struct nf_bridge_info *nf_bridge = skb->nf_bridge;
>  
>   skb_pull(skb, ETH_HLEN);
> @@ -86,7 +87,10 @@ static inline int 
> br_nf_pre_routing_finish_bridge_slow(struct sk_buff *skb)
>   skb_copy_to_linear_data_offset(skb, -(ETH_HLEN-ETH_ALEN),
>  skb->nf_bridge->data, ETH_HLEN-ETH_ALEN);
>   skb->dev = nf_bridge->physindev;
> - return br_handle_frame_finish(skb);
> + rcu_read_lock();
> + res = br_handle_frame_finish(skb);
> + rcu_read_unlock();
> + return res;
>  }
>  
>  /* This is called by the IP fragmenting code and it ensures there is

Why not just move the rcu_read_lock() in br_dev_xmit earlier?
--
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: [PATCHSET] timer: clean up initializers and implement irqsafe timers

[Tejun Heo]

Hello,

On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
> Timer internals are protected by irqsafe lock but the lock is
> naturally dropped and irq enabled while a timer is executed.  This
> makes dequeueing timer for execution and the actual execution
> non-atomic against IRQs.  No matter what the timer function does, IRQs
> can occur between timer dispatch and execution.  This means that an
> IRQ handler could interrupt any timer in progress and it's impossible
> for an IRQ handler to cancel and drain a timer.

If nobody objects, I'll route this through wq/for-3.7 together with
"workqueue: use irqsafe timer in delayed_work" patchset.  If you
object, please scream.

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/

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

radeon and intel fixes mostly, one fix to the mgag200 driver to not hang 
on certain server variants.

Dave.

The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:

  Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

for you to fetch changes up to 7bac6b46607f2f44075cb45dd5b0b4d2e7c80695:

  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2012-08-14 09:25:01 +1000)



Alan Cox (3):
  vlv: it might be wise if we initialised the flag value...
  i915: fix error path leak in intel_sdvo_write_cmd
  i915: Remove silly test

Alex Deucher (9):
  drm/radeon: fix handling for ddc type 5 on combios
  drm/radeon/dce4+: set a more reasonable cursor watermark
  drm/radeon: properly handle SS overrides on TN (v2)
  drm/radeon: properly handle crtc powergating
  drm/radeon: fix bank tiling parameters on evergreen
  drm/radeon: fix bank tiling parameters on cayman
  drm/radeon: fix ordering in pll picking on dce4+
  drm/radeon: add some new SI pci ids
  drm/radeon: fix some missing parens in asic macros

Alexey Khoroshilov (1):
  drm/edid: Fix potential memory leak in edid_load()

Chris Wilson (1):
  drm/i915: Workaround hang with BSD and forcewake on SandyBridge

Christian König (1):
  drm/radeon: fix bank tiling parameters on SI

Daniel Vetter (2):
  drm/i915: fix forcewake related hangs on snb
  drm/i915: correctly order the ring init sequence

Dave Airlie (4):
  i915: don't map imported dma-bufs for dmar.
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  drm/mgag200: fix G200ER pll picking algorithm
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Devendra Naga (1):
  drm/i915: remove unused variable

Dmitrii Cherkasov (1):
  drm/radeon: fix typo in function header comment

Eric Anholt (1):
  drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.

Hunt Xu (1):
  drm/i915: make rc6 in sysfs functions conditional

Jerome Glisse (2):
  drm/radeon: do not reenable crtc after moving vram start address
  drm/radeon: fence virtual address and free it once idle v4

Marek Olšák (4):
  drm/radeon/kms: allow "invalid" DB formats as a means to disable DB
  drm/radeon/kms: reorder code in r600_check_texture_resource
  drm/radeon/kms: add MSAA texture support for r600-evergreen
  drm/radeon/kms: implement timestamp userspace query (v2)

Paulo Zanoni (1):
  drm/i915: add more Haswell PCI IDs

Stéphane Marchesin (1):
  drm/i915: Make intel_panel_get_backlight static.

Thomas Meyer (1):
  drm/udl: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1]

 drivers/char/agp/intel-agp.h|   39 +--
 drivers/char/agp/intel-gtt.c|   60 +-
 drivers/gpu/drm/drm_edid_load.c |8 +--
 drivers/gpu/drm/i915/i915_drv.c |   31 +++-
 drivers/gpu/drm/i915/i915_gem_context.c |1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c  |   20 
 drivers/gpu/drm/i915/i915_gem_gtt.c |3 +-
 drivers/gpu/drm/i915/i915_sysfs.c   |   12 +
 drivers/gpu/drm/i915/intel_display.c|1 +
 drivers/gpu/drm/i915/intel_drv.h|   20 
 drivers/gpu/drm/i915/intel_i2c.c|3 --
 drivers/gpu/drm/i915/intel_panel.c  |2 +-
 drivers/gpu/drm/i915/intel_pm.c |6 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |7 ++-
 drivers/gpu/drm/i915/intel_sdvo.c   |5 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c  |   12 +++--
 drivers/gpu/drm/radeon/atombios_crtc.c  |   22 ++---
 drivers/gpu/drm/radeon/evergreen.c  |   71 +--
 drivers/gpu/drm/radeon/evergreen_cs.c   |   13 -
 drivers/gpu/drm/radeon/evergreend.h |2 +
 drivers/gpu/drm/radeon/ni.c |   14 --
 drivers/gpu/drm/radeon/r600.c   |   20 
 drivers/gpu/drm/radeon/r600_cs.c|   65 +---
 drivers/gpu/drm/radeon/r600d.h  |3 ++
 drivers/gpu/drm/radeon/radeon.h |   12 +++--
 drivers/gpu/drm/radeon/radeon_asic.h|   10 ++--
 drivers/gpu/drm/radeon/radeon_atombios.c|   49 +-
 drivers/gpu/drm/radeon/radeon_combios.c |   57 +
 drivers/gpu/drm/radeon/radeon_cs.c  |   32 ++--
 drivers/gpu/drm/radeon/radeon_cursor.c  |6 ++-
 drivers/gpu/drm/radeon/radeon_device.c  |1 +
 drivers/gpu/drm/radeon/radeon_drv.c |5 +-
 drivers/gpu/drm/radeon/radeon_gart.c|   26 --
 drivers/gpu/drm/radeon/radeon_gem.c 

Re: [PATCH 0/7] HID: picoLCD updates

[Tejun Heo]

Hello,

On Thu, Aug 09, 2012 at 08:09:47PM +0200, Bruno Prémont wrote:
> As you are working on workqueues and related code, could you have a look
> at my usage of them in combination with db_defio?
> 
> The delayed memory corruptions or system reboots after unbinding/unplugging
> the PicoLCD seem very much related to workqueue used to handle the deferred
> IO to framebuffer.
> 
> I think things don't get cleaned-up as they should though I'm not sure
> where the trouble lies.
> 
> For ease of reading, I'm inlineing below the framebuffer related code of
> PicoLCD (for complete driver after this patch series apply the whole series
> on top of 3.5 https://lkml.org/lkml/2012/7/30/375 )
...
> void picolcd_exit_framebuffer(struct picolcd_data *data)
> {
>   struct fb_info *info = data->fb_info;
>   u8 *fb_vbitmap = data->fb_vbitmap;
> 
>   if (!info)
>   return;
> 
>   device_remove_file(>hdev->dev, _attr_fb_update_rate);
>   info->par = NULL;
>   unregister_framebuffer(info);
>   data->fb_vbitmap = NULL;
>   data->fb_bitmap  = NULL;
>   data->fb_bpp = 0;
>   data->fb_info= NULL;
>   kfree(fb_vbitmap);
> }

I'm kinda shooting in the dark but who flushes / cancels
fb_info->deferred_work?

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/

Re: [PATCH 5/5] x86: Move enabling of PSE and PGE out of init_memory_mapping

[Tejun Heo]

Hello,

On Mon, Aug 13, 2012 at 09:34:40AM +0200, Borislav Petkov wrote:
> On Sat, Aug 11, 2012 at 01:01:33PM -0700, Tejun Heo wrote:
> > Shouldn't this happen before init_memory_mapping() is called multiple
> > times?
> 
> It does.
> 
> Those CR4 flags are set before the loop which calls init_memory_mapping().

I meant the patch should come before the patch making multiple calls
to init_memory_mapping().

> > Also, there seem to be other stuff which need to be moved out.
> 
> Which are those pls?

Rebuilding pgtable on each invocation?

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/

Re: [PATCH 5/5] x86: Move enabling of PSE and PGE out of init_memory_mapping

[Tejun Heo]

On Mon, Aug 13, 2012 at 04:47:04PM -0500, Jacob Shin wrote:
> Since we now call init_memory_mapping for each E820_RAM region in a
> loop, move cr4 writes out to setup_arch.

Wouldn't it be better if this happens *before* init_memory_mapping()
is called multiple times?

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/

Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs

[Michael S. Tsirkin]

On Mon, Aug 13, 2012 at 04:41:05PM -0600, Alex Williamson wrote:
> On Tue, 2012-08-14 at 01:06 +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 13, 2012 at 03:34:01PM -0600, Alex Williamson wrote:
> > > On Sun, 2012-08-12 at 11:36 +0300, Avi Kivity wrote:
> > > > On 08/09/2012 10:26 PM, Alex Williamson wrote:
> > > > > On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
> > > > >> On 08/06/2012 01:38 PM, Avi Kivity wrote:
> > > > >> 
> > > > >> > Regarding the implementation, instead of a linked list, would an 
> > > > >> > array
> > > > >> > of counters parallel to the bitmap make it simpler?
> > > > >> 
> > > > >> Or even, replace the bitmap with an array of counters.
> > > > > 
> > > > > I'm not sure a counter array is what we're really after.  That gives 
> > > > > us
> > > > > reference counting for the irq source IDs, but not the key->gsi 
> > > > > lookup.
> > > > 
> > > > You can look up the gsi while registering the eoifd, so it's accessible
> > > > as eoifd->gsi instead of eoifd->source->gsi.  The irqfd can go away
> > > > while the eoifd is still active, but is this a problem?
> > > 
> > > In my opinion, no, but Michael disagrees.
> > > 
> > > > > It also highlights another issue, that we have a limited set of source
> > > > > IDs.  Looks like we have BITS_PER_LONG IDs, with two already used, one
> > > > > for the shared userspace ID and another for the PIT.  How happy are we
> > > > > going to be with a limit of 62 level interrupts in use at one time?
> > > > 
> > > > When we start being unhappy we can increase that number.  On the other
> > > > hand more locks and lists makes me unhappy now.
> > > 
> > > Yep, good point.  My latest version removes the source ID object lock
> > > and list (and objects).  I still have a lock and list for the ack
> > > notification, but it's hard not to unless we combine them into one
> > > mega-irqfd ioctl as Michael suggests.
> > >
> > > > > It's arguably a reasonable number since the most virtualization 
> > > > > friendly
> > > > > devices (sr-iov VFs) don't even support this kind of interrupt.  It's
> > > > > also very wasteful allocating an entire source ID for a single GSI
> > > > > within that source ID.  PCI supports interrupts A, B, C, and D, which,
> > > > > in the most optimal config, each go to different GSIs.  So we could
> > > > > theoretically be more efficient in our use and allocation of irq 
> > > > > source
> > > > > IDs if we tracked use by the source ID, gsi pair.
> > > > 
> > > > There are, in one userspace, just three gsis available for PCI links, so
> > > > you're compressing the source id space by 3.
> > > 
> > > I imagine there's a way to put each PCI interrupt pin on a GSI, but
> > > still only 4, not a great expansion of source ID space.  I like
> > > Michael's idea of re-using source IDs if we run out better.
> > > 
> > > > > That probably makes it less practical to replace anything at the top
> > > > > level with a counter array.  The key that we pass back is currently 
> > > > > the
> > > > > actual source ID, but we don't specify what it is, so we could split 
> > > > > it
> > > > > and have it encode a 16bit source ID plus 16 bit GSI.  It could also 
> > > > > be
> > > > > an idr entry.
> > > > 
> > > > We can fix those kinds of problems by adding another layer of
> > > > indirection.  But I doubt they will be needed.  I don't see people
> > > > assigning 60 legacy devices to one guest.
> > > 
> > > Yep, we can ignore it for now and put it in the hands of userspace to
> > > re-use IDs if needed.
> > > 
> > > > > Michael, would the interface be more acceptable to you if we added
> > > > > separate ioctls to allocate and free some representation of an irq
> > > > > source ID, gsi pair?  For instance, an ioctl might return an idr entry
> > > > > for an irq source ID/gsi object which would then be passed as a
> > > > > parameter in struct kvm_irqfd and struct kvm_eoifd so that the object
> > > > > representing the source id/gsi isn't magically freed on it's own.  
> > > > > This
> > > > > would also allow us to deassign/close one end and reconfigure it 
> > > > > later.
> > > > > Thanks,
> > > > 
> > > > Another option is to push the responsibility for allocating IDs for the
> > > > association to userspace.  Let userspace both create the irqfd and the
> > > > eoifd with the same ID, the kernel matches them at registration time and
> > > > copies the gsi/sourceid from the first to the second eventfd.
> > > 
> > > Aside from the copying gsi/sourceid bit, you've just described my latest
> > > attempt at this series.  Specifying both a sourceid and gsi also allows
> > > userspace to make better use of the sourceid address space (use more
> > > than one gsi if userspace wants the complexity of managing them).
> > > Thanks,
> > > 
> > > Alex
> > 
> > Turns out per device source ID is a bug copied from existing
> > device assignment. I am amazed we did not notice before.
> > There we have small # of devices so it's not a problem but 

[PATCH V2 2/2] apple_gmux: Add support for newer hardware

[Matthew Garrett]

New gmux devices have a different method for accessing the registers.
Update the driver to cope. Incorporates feedback from Bernhard Froemel.

Signed-off-by: Matthew Garrett 
Cc: Bernhard Froemel 
Cc: Seth Forshee 
---
 drivers/platform/x86/apple-gmux.c | 179 +++---
 1 file changed, 165 insertions(+), 14 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index c9db5072..612b6f6 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -18,12 +18,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 struct apple_gmux_data {
unsigned long iostart;
unsigned long iolen;
+   bool indexed;
+   struct mutex index_lock;
 
struct backlight_device *bdev;
 };
@@ -45,6 +48,9 @@ struct apple_gmux_data {
 #define GMUX_PORT_DISCRETE_POWER   0x50
 #define GMUX_PORT_MAX_BRIGHTNESS   0x70
 #define GMUX_PORT_BRIGHTNESS   0x74
+#define GMUX_PORT_VALUE0xc2
+#define GMUX_PORT_READ 0xd0
+#define GMUX_PORT_WRITE0xd4
 
 #define GMUX_MIN_IO_LEN(GMUX_PORT_BRIGHTNESS + 4)
 
@@ -59,24 +65,24 @@ struct apple_gmux_data {
 #define GMUX_BRIGHTNESS_MASK   0x00ff
 #define GMUX_MAX_BRIGHTNESSGMUX_BRIGHTNESS_MASK
 
-static inline u8 gmux_read8(struct apple_gmux_data *gmux_data, int port)
+static u8 gmux_pio_read8(struct apple_gmux_data *gmux_data, int port)
 {
return inb(gmux_data->iostart + port);
 }
 
-static inline void gmux_write8(struct apple_gmux_data *gmux_data, int port,
+static void gmux_pio_write8(struct apple_gmux_data *gmux_data, int port,
   u8 val)
 {
outb(val, gmux_data->iostart + port);
 }
 
-static inline u32 gmux_read32(struct apple_gmux_data *gmux_data, int port)
+static u32 gmux_pio_read32(struct apple_gmux_data *gmux_data, int port)
 {
return inl(gmux_data->iostart + port);
 }
 
-static inline u32 gmux_write32(struct apple_gmux_data *gmux_data, int port,
-  u32 val)
+static void gmux_pio_write32(struct apple_gmux_data *gmux_data, int port,
+u32 val)
 {
int i;
u8 tmpval;
@@ -87,6 +93,144 @@ static inline u32 gmux_write32(struct apple_gmux_data 
*gmux_data, int port,
}
 }
 
+static int gmux_index_wait_ready(struct apple_gmux_data *gmux_data)
+{
+   int i = 200;
+   u8 gwr = inb(gmux_data->iostart + GMUX_PORT_WRITE);
+
+   while (i && (gwr & 0x01)) {
+   inb(gmux_data->iostart + GMUX_PORT_READ);
+   gwr = inb(gmux_data->iostart + GMUX_PORT_WRITE);
+   msleep(100);
+   i--;
+   }
+
+   return !!i;
+}
+
+static int gmux_index_wait_complete(struct apple_gmux_data *gmux_data)
+{
+   int i = 200;
+   u8 gwr = inb(gmux_data->iostart + GMUX_PORT_WRITE);
+
+   while (i && (gwr & 0x01)) {
+   gwr = inb(gmux_data->iostart + GMUX_PORT_WRITE);
+   msleep(100);
+   i--;
+   }
+
+   if (gwr & 0x01)
+   inb(gmux_data->iostart + GMUX_PORT_READ);
+
+   return !!i;
+}
+
+static u8 gmux_index_read8(struct apple_gmux_data *gmux_data, int port)
+{
+   u8 val;
+
+   mutex_lock(_data->index_lock);
+   outb((port & 0xff), gmux_data->iostart + GMUX_PORT_READ);
+   gmux_index_wait_ready(gmux_data);
+   val = inb(gmux_data->iostart + GMUX_PORT_VALUE);
+   mutex_unlock(_data->index_lock);
+
+   return val;
+}
+
+static void gmux_index_write8(struct apple_gmux_data *gmux_data, int port,
+ u8 val)
+{
+   mutex_lock(_data->index_lock);
+   outb(val, gmux_data->iostart + GMUX_PORT_VALUE);
+   gmux_index_wait_ready(gmux_data);
+   outb(port & 0xff, gmux_data->iostart + GMUX_PORT_WRITE);
+   gmux_index_wait_complete(gmux_data);
+   mutex_unlock(_data->index_lock);
+}
+
+static u32 gmux_index_read32(struct apple_gmux_data *gmux_data, int port)
+{
+   u32 val;
+
+   mutex_lock(_data->index_lock);
+   outb((port & 0xff), gmux_data->iostart + GMUX_PORT_READ);
+   gmux_index_wait_ready(gmux_data);
+   val = inl(gmux_data->iostart + GMUX_PORT_VALUE);
+   mutex_unlock(_data->index_lock);
+
+   return val;
+}
+
+static void gmux_index_write32(struct apple_gmux_data *gmux_data, int port,
+  u32 val)
+{
+   int i;
+   u8 tmpval;
+
+   mutex_lock(_data->index_lock);
+
+   for (i = 0; i < 4; i++) {
+   tmpval = (val >> (i * 8)) & 0xff;
+   outb(tmpval, gmux_data->iostart + GMUX_PORT_VALUE + i);
+   }
+
+   gmux_index_wait_ready(gmux_data);
+   outb(port & 0xff, gmux_data->iostart + GMUX_PORT_WRITE);
+   gmux_index_wait_complete(gmux_data);
+   mutex_unlock(_data->index_lock);
+}
+
+static u8 gmux_read8(struct 

[PATCH V2 1/2] gmux: Add generic write32 function

[Matthew Garrett]

Move the special-cased backlight update function to a generic gmux_write32
function.

Signed-off-by: Matthew Garrett 
Cc: Seth Forshee 
---

Fixed the typo and irrelevant hunk

 drivers/platform/x86/apple-gmux.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index 905fa01..c9db5072 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -75,6 +75,18 @@ static inline u32 gmux_read32(struct apple_gmux_data 
*gmux_data, int port)
return inl(gmux_data->iostart + port);
 }
 
+static inline u32 gmux_write32(struct apple_gmux_data *gmux_data, int port,
+  u32 val)
+{
+   int i;
+   u8 tmpval;
+
+   for (i = 0; i < 4; i++) {
+   tmpval = (val >> (i * 8)) & 0xff;
+   outb(tmpval, port + i);
+   }
+}
+
 static int gmux_get_brightness(struct backlight_device *bd)
 {
struct apple_gmux_data *gmux_data = bl_get_data(bd);
@@ -90,16 +102,7 @@ static int gmux_update_status(struct backlight_device *bd)
if (bd->props.state & BL_CORE_SUSPENDED)
return 0;
 
-   /*
-* Older gmux versions require writing out lower bytes first then
-* setting the upper byte to 0 to flush the values. Newer versions
-* accept a single u32 write, but the old method also works, so we
-* just use the old method for all gmux versions.
-*/
-   gmux_write8(gmux_data, GMUX_PORT_BRIGHTNESS, brightness);
-   gmux_write8(gmux_data, GMUX_PORT_BRIGHTNESS + 1, brightness >> 8);
-   gmux_write8(gmux_data, GMUX_PORT_BRIGHTNESS + 2, brightness >> 16);
-   gmux_write8(gmux_data, GMUX_PORT_BRIGHTNESS + 3, 0);
+   gmux_write32(gmux_data, GMUX_PORT_BRIGHTNESS, brightness);
 
return 0;
 }
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] 3.2.27-rt40

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.27-rt40 stable release.


This release is just an update to the new stable 3.2.27 version
and no RT specific changes have been made.


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: 276c90df1ccfdd7ed0fbdaa03a7a3ba4c5404875


Or to build 3.2.27-rt40 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.27.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.27-rt40.patch.xz



Enjoy,

-- Steve



--
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 v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs

[Michael S. Tsirkin]

On Mon, Aug 13, 2012 at 04:22:12PM -0600, Alex Williamson wrote:
> On Tue, 2012-08-14 at 00:50 +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 13, 2012 at 02:48:25PM -0600, Alex Williamson wrote:
> > > On Mon, 2012-08-13 at 22:50 +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 13, 2012 at 12:17:25PM -0600, Alex Williamson wrote:
> > > > > On Mon, 2012-08-13 at 19:59 +0300, Michael S. Tsirkin wrote:
> > > > > > On Mon, Aug 13, 2012 at 10:48:15AM -0600, Alex Williamson wrote:
> > > > > > > On Sun, 2012-08-12 at 10:49 +0300, Michael S. Tsirkin wrote:
> > > > > > > > On Wed, Aug 01, 2012 at 01:06:42PM -0600, Alex Williamson wrote:
> > > > > > > > > On Mon, 2012-07-30 at 19:12 -0600, Alex Williamson wrote:
> > > > > > > > > > On Tue, 2012-07-31 at 03:36 +0300, Michael S. Tsirkin wrote:
> > > > > > > > > > > On Mon, Jul 30, 2012 at 06:26:31PM -0600, Alex Williamson 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Tue, 2012-07-31 at 03:01 +0300, Michael S. Tsirkin 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > You keep saying this but it is still true: once irqfd
> > > > > > > > > > > > > is closed eoifd does not get any more interrupts.
> > > > > > > > > > > > 
> > > > > > > > > > > > How does that matter?
> > > > > > > > > > > 
> > > > > > > > > > > Well if it does not get events it is disabled.
> > > > > > > > > > > so you have one ifc disabling another, anyway.
> > > > > > > > > > 
> > > > > > > > > > And a level irqfd without an eoifd can never be 
> > > > > > > > > > de-asserted.  Either we
> > > > > > > > > > make modular components, assemble them to do useful work, 
> > > > > > > > > > and
> > > > > > > > > > disassemble them independently so they can be used by 
> > > > > > > > > > future interfaces
> > > > > > > > > > or we bundle eoifd as just an option of irqfd.  Which is it 
> > > > > > > > > > gonna be?
> > > > > > > > > 
> > > > > > > > > I don't think I've been successful at explaining my reasoning 
> > > > > > > > > for making
> > > > > > > > > EOI notification a separate interface, so let me try again...
> > > > > > > > > 
> > > > > > > > > When kvm is not enabled, the qemu vfio driver still needs to 
> > > > > > > > > know about
> > > > > > > > > EOIs to re-enable the physical interrupt.  Since the ioapic 
> > > > > > > > > is emulated
> > > > > > > > > in qemu, we can setup a notifier for this and create 
> > > > > > > > > abstraction to make
> > > > > > > > > it non-x86 specific, etc.  We just need to come up with a 
> > > > > > > > > design and
> > > > > > > > > implement it.  But what happens when kvm is then enabled?  
> > > > > > > > > ioapic
> > > > > > > > > emulation moves to the kernel (assume kvm includes irqchip 
> > > > > > > > > for this
> > > > > > > > > argument even though it doesn't for POWER), qemu no longer 
> > > > > > > > > knows about
> > > > > > > > > EOIs, and the interface we just created to handle the non-kvm 
> > > > > > > > > case stops
> > > > > > > > > working.  Is anyone going to accept adding a qemu EOI 
> > > > > > > > > notification
> > > > > > > > > interface that only works when kvm is not enabled?
> > > > > > > > 
> > > > > > > > Yes, it's only a question of abstracting it at the right level.
> > > > > > > > 
> > > > > > > > For example, if as you suggest below kvm gives you an eventfd 
> > > > > > > > that
> > > > > > > > asserts an irq, laters automatically deasserts it and notifies 
> > > > > > > > another
> > > > > > > > eventfd, we can do exactly this in both tcg and kvm:
> > > > > > > > 
> > > > > > > > setup_level_irq(int gsi, int assert_eventfd, int 
> > > > > > > > deassert_eventfd)
> > > > > > > > 
> > > > > > > > Not advocating this interface but pointing out that to make
> > > > > > > > same abstraction to work in tcg and kvm, see what it does in
> > > > > > > > each of them first.
> > > > > > > 
> > > > > > > The tcg model I was thinking of is that we continue to use 
> > > > > > > qemu_set_irq
> > > > > > > to assert and de-assert the interrupt and add an eoi/ack 
> > > > > > > notification
> > > > > > > mechanism, much like the ack notifier that already exists in kvm. 
> > > > > > >  There
> > > > > > > doesn't seem to be much advantage to creating a new interrupt
> > > > > > > infrastructure in tcg that can trigger interrupts by eventfds, so 
> > > > > > > I
> > > > > > > assume VFIO is always going to be responsible for the translation 
> > > > > > > of an
> > > > > > > eventfd to an irq assertion, get some kind of notification 
> > > > > > > through qemu,
> > > > > > > de-assert the interrupt and unmask the device.  With that model 
> > > > > > > in mind,
> > > > > > > perhaps it makes more sense why I've been keeping the eoi/ack 
> > > > > > > separate
> > > > > > > from irqfd.
> > > > > > > 
> > > > > > > > > I suspect we therefore need a notification mechanism between 
> > > > > > > > > kvm and
> > > > > > > > > qemu to make it possible for that interface to continue 
> > > > > > > > > working.
> > > > > > > > 

[PATCH] [NETFILTER] bridge: rcu_deref outside read-lock section

[Denis Efremov]

As it noted in the comment before the br_handle_frame_finish
function, this function should be called under rcu_read_lock.

The problem callgraph:
br_dev_xmit -> br_nf_pre_routing_finish_bridge_slow ->
-> br_handle_frame_finish -> br_port_get_rcu -> rcu_dereference

And in this case there is no read-lock section.
I have put lock/unlock in br_nf_pre_routing_finish_bridge_slow,
as the only function that calls it(for now) - is br_dev_xmit.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Denis Efremov 
---
 include/linux/netfilter_bridge.h |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/netfilter_bridge.h b/include/linux/netfilter_bridge.h
index 31d2844..ceb048e 100644
--- a/include/linux/netfilter_bridge.h
+++ b/include/linux/netfilter_bridge.h
@@ -79,6 +79,7 @@ extern int br_handle_frame_finish(struct sk_buff *skb);
 /* Only used in br_device.c */
 static inline int br_nf_pre_routing_finish_bridge_slow(struct sk_buff *skb)
 {
+   int res;
struct nf_bridge_info *nf_bridge = skb->nf_bridge;
 
skb_pull(skb, ETH_HLEN);
@@ -86,7 +87,10 @@ static inline int 
br_nf_pre_routing_finish_bridge_slow(struct sk_buff *skb)
skb_copy_to_linear_data_offset(skb, -(ETH_HLEN-ETH_ALEN),
   skb->nf_bridge->data, ETH_HLEN-ETH_ALEN);
skb->dev = nf_bridge->physindev;
-   return br_handle_frame_finish(skb);
+   rcu_read_lock();
+   res = br_handle_frame_finish(skb);
+   rcu_read_unlock();
+   return res;
 }
 
 /* This is called by the IP fragmenting code and it ensures there is
-- 
1.7.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 2/2] kvm: KVM_EOIFD, an eventfd for EOIs

[Alex Williamson]

On Tue, 2012-08-14 at 01:06 +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 03:34:01PM -0600, Alex Williamson wrote:
> > On Sun, 2012-08-12 at 11:36 +0300, Avi Kivity wrote:
> > > On 08/09/2012 10:26 PM, Alex Williamson wrote:
> > > > On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
> > > >> On 08/06/2012 01:38 PM, Avi Kivity wrote:
> > > >> 
> > > >> > Regarding the implementation, instead of a linked list, would an 
> > > >> > array
> > > >> > of counters parallel to the bitmap make it simpler?
> > > >> 
> > > >> Or even, replace the bitmap with an array of counters.
> > > > 
> > > > I'm not sure a counter array is what we're really after.  That gives us
> > > > reference counting for the irq source IDs, but not the key->gsi lookup.
> > > 
> > > You can look up the gsi while registering the eoifd, so it's accessible
> > > as eoifd->gsi instead of eoifd->source->gsi.  The irqfd can go away
> > > while the eoifd is still active, but is this a problem?
> > 
> > In my opinion, no, but Michael disagrees.
> > 
> > > > It also highlights another issue, that we have a limited set of source
> > > > IDs.  Looks like we have BITS_PER_LONG IDs, with two already used, one
> > > > for the shared userspace ID and another for the PIT.  How happy are we
> > > > going to be with a limit of 62 level interrupts in use at one time?
> > > 
> > > When we start being unhappy we can increase that number.  On the other
> > > hand more locks and lists makes me unhappy now.
> > 
> > Yep, good point.  My latest version removes the source ID object lock
> > and list (and objects).  I still have a lock and list for the ack
> > notification, but it's hard not to unless we combine them into one
> > mega-irqfd ioctl as Michael suggests.
> >
> > > > It's arguably a reasonable number since the most virtualization friendly
> > > > devices (sr-iov VFs) don't even support this kind of interrupt.  It's
> > > > also very wasteful allocating an entire source ID for a single GSI
> > > > within that source ID.  PCI supports interrupts A, B, C, and D, which,
> > > > in the most optimal config, each go to different GSIs.  So we could
> > > > theoretically be more efficient in our use and allocation of irq source
> > > > IDs if we tracked use by the source ID, gsi pair.
> > > 
> > > There are, in one userspace, just three gsis available for PCI links, so
> > > you're compressing the source id space by 3.
> > 
> > I imagine there's a way to put each PCI interrupt pin on a GSI, but
> > still only 4, not a great expansion of source ID space.  I like
> > Michael's idea of re-using source IDs if we run out better.
> > 
> > > > That probably makes it less practical to replace anything at the top
> > > > level with a counter array.  The key that we pass back is currently the
> > > > actual source ID, but we don't specify what it is, so we could split it
> > > > and have it encode a 16bit source ID plus 16 bit GSI.  It could also be
> > > > an idr entry.
> > > 
> > > We can fix those kinds of problems by adding another layer of
> > > indirection.  But I doubt they will be needed.  I don't see people
> > > assigning 60 legacy devices to one guest.
> > 
> > Yep, we can ignore it for now and put it in the hands of userspace to
> > re-use IDs if needed.
> > 
> > > > Michael, would the interface be more acceptable to you if we added
> > > > separate ioctls to allocate and free some representation of an irq
> > > > source ID, gsi pair?  For instance, an ioctl might return an idr entry
> > > > for an irq source ID/gsi object which would then be passed as a
> > > > parameter in struct kvm_irqfd and struct kvm_eoifd so that the object
> > > > representing the source id/gsi isn't magically freed on it's own.  This
> > > > would also allow us to deassign/close one end and reconfigure it later.
> > > > Thanks,
> > > 
> > > Another option is to push the responsibility for allocating IDs for the
> > > association to userspace.  Let userspace both create the irqfd and the
> > > eoifd with the same ID, the kernel matches them at registration time and
> > > copies the gsi/sourceid from the first to the second eventfd.
> > 
> > Aside from the copying gsi/sourceid bit, you've just described my latest
> > attempt at this series.  Specifying both a sourceid and gsi also allows
> > userspace to make better use of the sourceid address space (use more
> > than one gsi if userspace wants the complexity of managing them).
> > Thanks,
> > 
> > Alex
> 
> Turns out per device source ID is a bug copied from existing
> device assignment. I am amazed we did not notice before.
> There we have small # of devices so it's not a problem but there's no
> reason just not to have a source ID for all irqfds.
> So the problem goes away, and there is no limit on # of level irqfds,
> and no need to manage IDs in userspace at all.
> You can still have cookies in userspace if you like but do not map them
> to source IDs.

IMHO it's not a bug, it's an implementation decision.  They could 

Re: [PATCH 1/1] boot: Put initcall_debug into its own Kconfig option DEBUG_INITCALL

[Randy Dunlap]

On 08/13/2012 03:08 PM, Thai Bui wrote:

Hi all,

I am as part of a capstone group at Portland State University is working
to tinify the kernel as small as possible. The ultimate goal is to make
the kernel small enough to use on micro-controller (or under < 200k).
This patch is one of them, it saves 176 bytes on a minimal configuration
of the kernel (the bzImage file was reduced from 363264 bytes to 363264
bytes applying this patch).

Aside from the purpose of reducing the size of the kernel. We are also
trying to clean up the kernel by making Kconfig options to compile out
the stuffs that aren't used often.


IMO the kernel already has too many kconfig options.

Also, personally I would not merge a patch that saves so little memory,
especially on what I consider a very useful option.



On Mon, Aug 13, 2012 at 5:21 PM, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:

On Mon, Aug 13, 2012 at 01:57:11PM -0700, Thai Bui wrote:
 > Putting DEBUG_INITCALL config option to compile out the
command-line option
 > "initcall_debug".

Can you explain the benfits of this please?
 >
 > Signed-off-by: Thai Bui mailto:blquyt...@gmail.com>>
 > Reviewed-by: Josh Triplett mailto:j...@joshtriplett.org>>
 > ---
 >  Documentation/kernel-parameters.txt |3 ++-
 >  include/linux/init.h|4 
 >  init/main.c |2 ++
 >  lib/Kconfig.debug   |9 +
 >  4 files changed, 17 insertions(+), 1 deletion(-)
 >
 > diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
 > index d99fd9c..3dbaf15 100644
 > --- a/Documentation/kernel-parameters.txt
 > +++ b/Documentation/kernel-parameters.txt
 > @@ -1026,7 +1026,8 @@ bytes respectively. Such letter suffixes
can also be entirely omitted.
 >
 >   initcall_debug  [KNL] Trace initcalls as they are executed.
  Useful
 >   for working out where the kernel is dying
during
 > - startup.
 > + startup. DEBUG_INITCALL needs to be enabled
in order
 > + for this option to work.
 >
 >   initrd= [BOOT] Specify the location of the initial
ramdisk
 >
 > diff --git a/include/linux/init.h b/include/linux/init.h
 > index 6b95109..d2f31f1 100644
 > --- a/include/linux/init.h
 > +++ b/include/linux/init.h
 > @@ -157,7 +157,11 @@ void prepare_namespace(void);
 >
 >  extern void (*late_time_init)(void);
 >
 > +#ifdef CONFIG_DEBUG_INITCALL
 >  extern bool initcall_debug;
 > +#else
 > +static const bool initcall_debug = false;
 > +#endif /* CONFIG_DEBUG_INITCALL */
 >
 >  #endif
 >
 > diff --git a/init/main.c b/init/main.c
 > index ff49a6d..65837f7 100644
 > --- a/init/main.c
 > +++ b/init/main.c
 > @@ -648,8 +648,10 @@ static void __init do_ctors(void)
 >  #endif
 >  }
 >
 > +#ifdef CONFIG_DEBUG_INITCALL
 >  bool initcall_debug;
 >  core_param(initcall_debug, initcall_debug, bool, 0644);
 > +#endif /* CONFIG_DEBUG_INITCALL */
 >
 >  static char msgbuf[64];
 >
 > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
 > index 8745ac7..424ac93 100644
 > --- a/lib/Kconfig.debug
 > +++ b/lib/Kconfig.debug
 > @@ -769,6 +769,15 @@ config DEBUG_WRITECOUNT
 >
 > If unsure, say N.
 >
 > +config DEBUG_INITCALL
 > + bool "Debug initcalls as they are executed"
 > + depends on DEBUG_KERNEL
 > + help
 > +   Enable this for tracing initcalls during startup. Useful
for working
 > +   out where the kernel is dying during startup.
 > +
 > +   If unsure, say N
 > +
 >  config DEBUG_MEMORY_INIT
 >   bool "Debug memory initialisation" if EXPERT
 >   default !EXPERT
 > --


--
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/

[ 00/44] 3.0.41-stable review

[Greg Kroah-Hartman]

From: Greg KH 

This is the start of the stable review cycle for the 3.0.41 release.
There are 44 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Aug 15 22:01:40 UTC 2012.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.41-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
 MAINTAINERS   |2 +-
 Makefile  |4 +-
 arch/arm/configs/mxs_defconfig|1 -
 arch/arm/include/asm/cacheflush.h |8 +-
 arch/arm/include/asm/mutex.h  |  119 +--
 arch/arm/mm/tlb-v7.S  |   12 ++
 arch/arm/vfp/vfpmodule.c  |6 +
 arch/ia64/include/asm/atomic.h|4 +-
 arch/ia64/kernel/irq_ia64.c   |1 -
 arch/x86/kernel/alternative.c |2 +-
 arch/x86/kernel/microcode_core.c  |   31 ++-
 drivers/char/mspec.c  |2 +-
 drivers/char/random.c |  374 ++---
 drivers/firmware/dmi_scan.c   |3 +
 drivers/firmware/pcdp.c   |4 +-
 drivers/input/tablet/wacom_wac.c  |2 +-
 drivers/mfd/ab3100-core.c |5 -
 drivers/mfd/ab3550-core.c |2 -
 drivers/mfd/ezx-pcap.c|2 +-
 drivers/mfd/wm831x-otp.c  |8 +
 drivers/net/e1000e/82571.c|4 +-
 drivers/net/wireless/rt2x00/rt61pci.c |3 +-
 drivers/rtc/rtc-wm831x.c  |   24 ++-
 drivers/usb/core/hub.c|9 +
 fs/nilfs2/ioctl.c |4 +-
 fs/nilfs2/super.c |3 +
 fs/nilfs2/the_nilfs.c |1 +
 fs/nilfs2/the_nilfs.h |2 +
 include/linux/irqdesc.h   |1 -
 include/linux/mfd/ezx-pcap.h  |1 +
 include/linux/random.h|   19 +-
 include/trace/events/random.h |  134 
 kernel/irq/handle.c   |7 +-
 kernel/irq/manage.c   |   17 --
 mm/hugetlb.c  |   25 ++-
 mm/memory-failure.c   |6 +-
 mm/mmu_notifier.c |   45 ++--
 net/core/dev.c|3 +
 net/core/rtnetlink.c  |1 +
 net/mac80211/mesh.c   |1 +
 net/sunrpc/rpcb_clnt.c|4 +-
 net/wireless/core.c   |5 +
 net/wireless/core.h   |1 +
 net/wireless/util.c   |5 +-
 sound/pci/hda/patch_conexant.c|1 -
 45 files changed, 589 insertions(+), 329 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 03/44] nilfs2: fix deadlock issue between chcp and thaw ioctls

[Greg Kroah-Hartman]

From: Greg KH 

3.0-stable review patch.  If anyone has any objections, please let me know.

--

From: Ryusuke Konishi 

commit 572d8b3945a31bee7c40d21556803e4807fd9141 upstream.

An fs-thaw ioctl causes deadlock with a chcp or mkcp -s command:

 chcpD 88013870f3d0 0  1325   1324 0x0004
 ...
 Call Trace:
   nilfs_transaction_begin+0x11c/0x1a0 [nilfs2]
   wake_up_bit+0x20/0x20
   copy_from_user+0x18/0x30 [nilfs2]
   nilfs_ioctl_change_cpmode+0x7d/0xcf [nilfs2]
   nilfs_ioctl+0x252/0x61a [nilfs2]
   do_page_fault+0x311/0x34c
   get_unmapped_area+0x132/0x14e
   do_vfs_ioctl+0x44b/0x490
   __set_task_blocked+0x5a/0x61
   vm_mmap_pgoff+0x76/0x87
   __set_current_blocked+0x30/0x4a
   sys_ioctl+0x4b/0x6f
   system_call_fastpath+0x16/0x1b
 thawD 88013870d890 0  1352   1351 0x0004
 ...
 Call Trace:
   rwsem_down_failed_common+0xdb/0x10f
   call_rwsem_down_write_failed+0x13/0x20
   down_write+0x25/0x27
   thaw_super+0x13/0x9e
   do_vfs_ioctl+0x1f5/0x490
   vm_mmap_pgoff+0x76/0x87
   sys_ioctl+0x4b/0x6f
   filp_close+0x64/0x6c
   system_call_fastpath+0x16/0x1b

where the thaw ioctl deadlocked at thaw_super() when called while chcp was
waiting at nilfs_transaction_begin() called from
nilfs_ioctl_change_cpmode().  This deadlock is 100% reproducible.

This is because nilfs_ioctl_change_cpmode() first locks sb->s_umount in
read mode and then waits for unfreezing in nilfs_transaction_begin(),
whereas thaw_super() locks sb->s_umount in write mode.  The locking of
sb->s_umount here was intended to make snapshot mounts and the downgrade
of snapshots to checkpoints exclusive.

This fixes the deadlock issue by replacing the sb->s_umount usage in
nilfs_ioctl_change_cpmode() with a dedicated mutex which protects snapshot
mounts.

Signed-off-by: Ryusuke Konishi 
Cc: Fernando Luis Vazquez Cao 
Tested-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/ioctl.c |4 ++--
 fs/nilfs2/super.c |3 +++
 fs/nilfs2/the_nilfs.c |1 +
 fs/nilfs2/the_nilfs.h |2 ++
 4 files changed, 8 insertions(+), 2 deletions(-)

--- a/fs/nilfs2/ioctl.c
+++ b/fs/nilfs2/ioctl.c
@@ -182,7 +182,7 @@ static int nilfs_ioctl_change_cpmode(str
if (copy_from_user(, argp, sizeof(cpmode)))
goto out;
 
-   down_read(>i_sb->s_umount);
+   mutex_lock(>ns_snapshot_mount_mutex);
 
nilfs_transaction_begin(inode->i_sb, , 0);
ret = nilfs_cpfile_change_cpmode(
@@ -192,7 +192,7 @@ static int nilfs_ioctl_change_cpmode(str
else
nilfs_transaction_commit(inode->i_sb); /* never fails */
 
-   up_read(>i_sb->s_umount);
+   mutex_unlock(>ns_snapshot_mount_mutex);
 out:
mnt_drop_write(filp->f_path.mnt);
return ret;
--- a/fs/nilfs2/super.c
+++ b/fs/nilfs2/super.c
@@ -951,6 +951,8 @@ static int nilfs_attach_snapshot(struct
struct nilfs_root *root;
int ret;
 
+   mutex_lock(>ns_snapshot_mount_mutex);
+
down_read(>ns_segctor_sem);
ret = nilfs_cpfile_is_snapshot(nilfs->ns_cpfile, cno);
up_read(>ns_segctor_sem);
@@ -975,6 +977,7 @@ static int nilfs_attach_snapshot(struct
ret = nilfs_get_root_dentry(s, root, root_dentry);
nilfs_put_root(root);
  out:
+   mutex_unlock(>ns_snapshot_mount_mutex);
return ret;
 }
 
--- a/fs/nilfs2/the_nilfs.c
+++ b/fs/nilfs2/the_nilfs.c
@@ -76,6 +76,7 @@ struct the_nilfs *alloc_nilfs(struct blo
nilfs->ns_bdev = bdev;
atomic_set(>ns_ndirtyblks, 0);
init_rwsem(>ns_sem);
+   mutex_init(>ns_snapshot_mount_mutex);
INIT_LIST_HEAD(>ns_dirty_files);
INIT_LIST_HEAD(>ns_gc_inodes);
spin_lock_init(>ns_inode_lock);
--- a/fs/nilfs2/the_nilfs.h
+++ b/fs/nilfs2/the_nilfs.h
@@ -47,6 +47,7 @@ enum {
  * @ns_flags: flags
  * @ns_bdev: block device
  * @ns_sem: semaphore for shared states
+ * @ns_snapshot_mount_mutex: mutex to protect snapshot mounts
  * @ns_sbh: buffer heads of on-disk super blocks
  * @ns_sbp: pointers to super block data
  * @ns_sbwtime: previous write time of super block
@@ -99,6 +100,7 @@ struct the_nilfs {
 
struct block_device*ns_bdev;
struct rw_semaphore ns_sem;
+   struct mutexns_snapshot_mount_mutex;
 
/*
 * used for


--
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/

[ 05/44] mm: fix wrong argument of migrate_huge_pages() in soft_offline_huge_page()

[Greg Kroah-Hartman]

From: Greg KH 

3.0-stable review patch.  If anyone has any objections, please let me know.

--

From: Joonsoo Kim 

commit dc32f63453f56d07a1073a697dcd843dd3098c09 upstream.

Commit a6bc32b89922 ("mm: compaction: introduce sync-light migration for
use by compaction") changed the declaration of migrate_pages() and
migrate_huge_pages().

But it missed changing the argument of migrate_huge_pages() in
soft_offline_huge_page().  In this case, we should call
migrate_huge_pages() with MIGRATE_SYNC.

Additionally, there is a mismatch between type the of argument and the
function declaration for migrate_pages().

Signed-off-by: Joonsoo Kim 
Cc: Christoph Lameter 
Cc: Mel Gorman 
Acked-by: David Rientjes 
Cc: "Aneesh Kumar K.V" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/memory-failure.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1334,8 +1334,8 @@ static int soft_offline_huge_page(struct
/* Keep page count to indicate a given hugepage is isolated. */
 
list_add(>lru, );
-   ret = migrate_huge_pages(, new_page, MPOL_MF_MOVE_ALL, 0,
-   true);
+   ret = migrate_huge_pages(, new_page, MPOL_MF_MOVE_ALL, false,
+   MIGRATE_SYNC);
if (ret) {
struct page *page1, *page2;
list_for_each_entry_safe(page1, page2, , lru)
@@ -1464,7 +1464,7 @@ int soft_offline_page(struct page *page,
page_is_file_cache(page));
list_add(>lru, );
ret = migrate_pages(, new_page, MPOL_MF_MOVE_ALL,
-   0, MIGRATE_SYNC);
+   false, MIGRATE_SYNC);
if (ret) {
putback_lru_pages();
pr_info("soft offline: %#lx: migration failed %d, type 
%lx\n",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 08/44] ARM: 7478/1: errata: extend workaround for erratum #720789

[Greg Kroah-Hartman]

From: Greg KH 

3.0-stable review patch.  If anyone has any objections, please let me know.

--

From: Will Deacon 

commit 5a783cbc48367cfc7b65afc75430953dfe60098f upstream.

Commit cdf357f1 ("ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS
operations can broadcast a faulty ASID") replaced by-ASID TLB flushing
operations with all-ASID variants to workaround A9 erratum #720789.

This patch extends the workaround to include the tlb_range operations,
which were overlooked by the original patch.

Tested-by: Steve Capper 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mm/tlb-v7.S |   12 
 1 file changed, 12 insertions(+)

--- a/arch/arm/mm/tlb-v7.S
+++ b/arch/arm/mm/tlb-v7.S
@@ -38,11 +38,19 @@ ENTRY(v7wbi_flush_user_tlb_range)
dsb
mov r0, r0, lsr #PAGE_SHIFT @ align address
mov r1, r1, lsr #PAGE_SHIFT
+#ifdef CONFIG_ARM_ERRATA_720789
+   mov r3, #0
+#else
asidr3, r3  @ mask ASID
+#endif
orr r0, r3, r0, lsl #PAGE_SHIFT @ Create initial MVA
mov r1, r1, lsl #PAGE_SHIFT
 1:
+#ifdef CONFIG_ARM_ERRATA_720789
+   ALT_SMP(mcr p15, 0, r0, c8, c3, 3)  @ TLB invalidate U MVA all ASID 
(shareable)
+#else
ALT_SMP(mcr p15, 0, r0, c8, c3, 1)  @ TLB invalidate U MVA 
(shareable)
+#endif
ALT_UP(mcr  p15, 0, r0, c8, c7, 1)  @ TLB invalidate U MVA
 
add r0, r0, #PAGE_SZ
@@ -70,7 +78,11 @@ ENTRY(v7wbi_flush_kern_tlb_range)
mov r0, r0, lsl #PAGE_SHIFT
mov r1, r1, lsl #PAGE_SHIFT
 1:
+#ifdef CONFIG_ARM_ERRATA_720789
+   ALT_SMP(mcr p15, 0, r0, c8, c3, 3)  @ TLB invalidate U MVA all ASID 
(shareable)
+#else
ALT_SMP(mcr p15, 0, r0, c8, c3, 1)  @ TLB invalidate U MVA 
(shareable)
+#endif
ALT_UP(mcr  p15, 0, r0, c8, c7, 1)  @ TLB invalidate U MVA
add r0, r0, #PAGE_SZ
cmp r0, r1


--
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/