[PATCH v3 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 
Reviewed-by: Arnd Bergmann 
Tested-by: Borislav Petkov 
---
 drivers/mmc/host/Kconfig  |7 +
 drivers/mmc/host/Makefile |2 +
 drivers/mmc/host/rtsx_pci_sdmmc.c | 1341 +
 3 files changed, 1350 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..1976b77
--- /dev/null
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -0,0 +1,1341 @@
+/* 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 
+
+/* 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 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) == MMC_SEND_TUNING_BLOCK)
+   trans_mode = SD_TM_AUTO_TUNING;
+   else
+   trans_mode 

[PATCH v3 0/2] Add modules to support realtek PCIE card reader

[wei_wang]

From: Wei WANG 

1. Fix a bug that DMA out of SW-IOMMU space in Lenovo Thinkpad x121e
2. Tested by Borislav Petkov 

Wei WANG (2):
  drivers/mfd: Add realtek pcie card reader driver
  drivers/mmc: Add realtek pcie sdmmc host driver

 drivers/mfd/Kconfig   |9 +
 drivers/mfd/Makefile  |4 +
 drivers/mfd/rts5209.c |  104 +++
 drivers/mfd/rts5229.c |  119 
 drivers/mfd/rtsx_pcr.c| 1286 +++
 drivers/mfd/rtsx_pcr.h|   31 +
 drivers/mmc/host/Kconfig  |7 +
 drivers/mmc/host/Makefile |2 +
 drivers/mmc/host/rtsx_pci_sdmmc.c | 1341 +
 include/linux/mfd/rtsx_common.h   |   47 ++
 include/linux/mfd/rtsx_pci.h  |  690 +++
 11 files changed, 3640 insertions(+)
 create mode 100644 drivers/mfd/rts5209.c
 create mode 100644 drivers/mfd/rts5229.c
 create mode 100644 drivers/mfd/rtsx_pcr.c
 create mode 100644 drivers/mfd/rtsx_pcr.h
 create mode 100644 drivers/mmc/host/rtsx_pci_sdmmc.c
 create mode 100644 include/linux/mfd/rtsx_common.h
 create mode 100644 include/linux/mfd/rtsx_pci.h

-- 
1.7.9.5

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

Re: [PATCH 3/3] writeback: add dirty_ratio_time per bdi variable (NFS write performance)

[Namjae Jeon]

2012/8/21, J. Bruce Fields :
> On Mon, Aug 20, 2012 at 12:00:04PM +1000, Dave Chinner wrote:
>> On Sun, Aug 19, 2012 at 10:57:24AM +0800, Fengguang Wu wrote:
>> > On Sat, Aug 18, 2012 at 05:50:02AM -0400, Namjae Jeon wrote:
>> > > From: Namjae Jeon 
>> > >
>> > > This patch is based on suggestion by Wu Fengguang:
>> > > https://lkml.org/lkml/2011/8/19/19
>> > >
>> > > kernel has mechanism to do writeback as per dirty_ratio and
>> > > dirty_background
>> > > ratio. It also maintains per task dirty rate limit to keep balance of
>> > > dirty pages at any given instance by doing bdi bandwidth estimation.
>> > >
>> > > Kernel also has max_ratio/min_ratio tunables to specify percentage of
>> > > writecache
>> > > to control per bdi dirty limits and task throtelling.
>> > >
>> > > However, there might be a usecase where user wants a writeback tuning
>> > > parameter to flush dirty data at desired/tuned time interval.
>> > >
>> > > dirty_background_time provides an interface where user can tune
>> > > background
>> > > writeback start time using /sys/block/sda/bdi/dirty_background_time
>> > >
>> > > dirty_background_time is used alongwith average bdi write bandwidth
>> > > estimation
>> > > to start background writeback.
>> >
>> > Here lies my major concern about dirty_background_time: the write
>> > bandwidth estimation is an _estimation_ and will sure become wildly
>> > wrong in some cases. So the dirty_background_time implementation based
>> > on it will not always work to the user expectations.
>> >
>> > One important case is, some users (eg. Dave Chinner) explicitly take
>> > advantage of the existing behavior to quickly create & delete a big
>> > 1GB temp file without worrying about triggering unnecessary IOs.
>>
>> It's a fairly common use case - short term temp files are used by
>> lots of applications and avoiding writing them - especially on NFS -
>> is a big performance win. Forcing immediate writeback will
>> definitely cause unprdictable changes in performance for many
>> people...
>>
>> > > Results are:-
>> > > ==
>> > > Case:1 - Normal setup without any changes
>> > > ./performancetest_arm ./100MB write
>> > >
>> > >  RecSize  WriteSpeed   RanWriteSpeed
>> > >
>> > >  10485760  7.93MB/sec   8.11MB/sec
>> > >   1048576  8.21MB/sec   7.80MB/sec
>> > >524288  8.71MB/sec   8.39MB/sec
>> > >262144  8.91MB/sec   7.83MB/sec
>> > >131072  8.91MB/sec   8.95MB/sec
>> > > 65536  8.95MB/sec   8.90MB/sec
>> > > 32768  8.76MB/sec   8.93MB/sec
>> > > 16384  8.78MB/sec   8.67MB/sec
>> > >  8192  8.90MB/sec   8.52MB/sec
>> > >  4096  8.89MB/sec   8.28MB/sec
>> > >
>> > > Average speed is near 8MB/seconds.
>> > >
>> > > Case:2 - Modified the dirty_background_time
>> > > ./performancetest_arm ./100MB write
>> > >
>> > >  RecSize  WriteSpeed   RanWriteSpeed
>> > >
>> > >  10485760  10.56MB/sec  10.37MB/sec
>> > >   1048576  10.43MB/sec  10.33MB/sec
>> > >524288  10.32MB/sec  10.02MB/sec
>> > >262144  10.52MB/sec  10.19MB/sec
>> > >131072  10.34MB/sec  10.07MB/sec
>> > > 65536  10.31MB/sec  10.06MB/sec
>> > > 32768  10.27MB/sec  10.24MB/sec
>> > > 16384  10.54MB/sec  10.03MB/sec
>> > >  8192  10.41MB/sec  10.38MB/sec
>> > >  4096  10.34MB/sec  10.12MB/sec
>> > >
>> > > we can see, average write speed is increased to ~10-11MB/sec.
>> > > 
>> >
>> > The numbers are impressive!
>>
>> All it shows is that avoiding the writeback delay writes a file a
>> bit faster. i.e. 5s delay + 10s @ 10MB/s vs no delay and 10s
>> @10MB/s. That's pretty obvious, really, and people have been trying
>> to make this "optimisation" for NFS clients for years in the
>> misguided belief that short-cutting writeback caching is beneficial
>> to application performance.
>>
>> What these numbers don't show that is whether over-the-wire
>> writeback speed has improved at all. Or what happens when you have a
>> network that is faster than the server disk, or even faster than the
>> client can write into memory? What about when there are multiple
>> threads, or the network is congested, or the server overloaded? In
>> those cases the performance differential will disappear and
>> there's a good chance that the existing code will be significantly
>> faster because it places less imediate load on the server and
>> network.D...
>>
>> If you need immediate dispatch of your data for single threaded
>> performance then sync_file_range() is your friend.
>>
>> > FYI, I tried another NFS specific approach
>> > to avoid big NFS COMMITs, which achieved similar performance gains:
>> >
>> > nfs: writeback pages wait queue
>> > https://lkml.org/lkml/2011/10/20/235
>>
>> Which is basically controlling the server IO latency when commits
>> occur - smaller ranges mean the commit (fsync) is faster, and more
>> frequent commits mean the data goes to disk sooner. This is
>> something that will 

udev 182: response timeout for request_firmware in module_probe path

[Ming Lei]

Hi Kay,

I found that udev 182 doesn't response for the request_firmware in
module_probe path until 30sec later after the 'ADD' event of firmware
device, but no such problem in udev175, sounds like a regression of udev?

I find there was a related discussion in [1], so CC guys who discussed before.

Just grep under kernel root dir, there are about 360 request_firmware callers,
and looks most of them are called in .probe path.


[1], https://lkml.org/lkml/2012/2/19/57

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

Re: [PATCH 0/4] fat: fix ESTALE errors

[Namjae Jeon]

2012/8/21, J. Bruce Fields :
> On Mon, Aug 20, 2012 at 01:19:51PM +0900, Namjae Jeon wrote:
>> 2012/8/18, OGAWA Hirofumi :
>> > Al Viro  writes:
>> >
>> >> On Sat, Aug 18, 2012 at 05:41:39AM -0400, Namjae Jeon wrote:
>> >>> From: Namjae Jeon 
>> >>>
>> >>> This patch-set eliminates the client side ESTALE errors when
>> >>> a FAT partition exported over NFS has its dentries evicted
>> >>> from the cache.
>> >>>
>> >>> One of the reasons for this error is lack of permanent inode
>> >>> numbers on FAT which makes it difficult to construct persistent
>> >>> file handles.This can be overcome by using the on-disk location
>> >>> of the directory entries (i_pos) as the inode number.
>> >>
>> >> The hell it can.  You've just made them unstable on rename(2).
>> >
>> > As more hint. We can't use i_pos as the inode number.
>> >
>> > E.g. inode is unlinked but is still opened (orphaned inode), the dir
>> > entry is free and you can create the inode on same i_pos. After that,
>> > both inodes have same i_pos (so inode number).
>> >
>> > Thanks.
>> Hi. Ogawa.
>> Thanks for specific explanation. I will check it.
>
Hi Bruce.
> Fo somebody that knows more about fat than me--is there really any hope
> of making it play well with nfs?

I think that this patch is only solution to fix estale issue from
inode cache eviction.
In case FAT - it makes use of iunique() to get unique inode number
-which is just based upon getting an incremented value from unique
counter variable. So, there is no way to reconstruct the inode based
upon inode numbers - like in case of other filesystems

We can check it easily like this.

1. ls -al /directory on nfs client.
2. echo 3 > /proc/sys/vm/drop_caches
3. ls -al /directory on nfs client again. estale error will be occurred.

There is no estale issue from reclaim with this patch.

And.. Hi Ogawa.
I checked other filesystem about unlink - inode issue. but I found
Ext4 have same issue.
Although other filesysm is having this issue, Can we think It could be
only FAT issue ?
>
> --b.
>
--
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 0/6] virtio-trace: Support virtio-trace

[Amit Shah]

On (Thu) 09 Aug 2012 [21:30:29], Yoshihiro YUNOMAE wrote:
> Hi All,
> 
> The following patch set provides a low-overhead system for collecting kernel
> tracing data of guests by a host in a virtualization environment.

ACK this series.

I ran it through the virtio-serial test suite, and there's no
regression in existing functionality.

I encourage you to check out the virtio-serial test suite[1] as well
as the virtio-serial unit tests in the autotest[2] code, and
contribute to them to add tests for the new functionality you've
added.

[1]
http://fedorapeople.org/cgit/amitshah/public_git/test-virtserial.git/

[2]
https://github.com/autotest/autotest/blob/e91cd67b845b291622c8d079a8289c4b0cb1e6ae/client/tests/kvm/tests/virtio_console.py


Thanks,

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

Re: regression with poll(2)

[Eric Dumazet]

On Mon, 2012-08-20 at 16:20 -0700, Andrew Morton wrote:
> On Mon, 20 Aug 2012 11:30:59 +0200
> Eric Dumazet  wrote:
> 
> > On Mon, 2012-08-20 at 10:04 +0100, Mel Gorman wrote:
> > 
> > > Can the following patch be tested please? It is reported to fix an fio
> > > regression that may be similar to what you are experiencing but has not
> > > been picked up yet.
> > > 
> > > -
> > 
> > This seems to help here.
> > 
> > Boot your machine with "mem=768M" or a bit less depending on your setup,
> > and try a netperf.
> > 
> > -> before patch :
> > 
> > # netperf
> > MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> > localhost.localdomain () port 0 AF_INET
> > Recv   SendSend  
> > Socket Socket  Message  Elapsed  
> > Size   SizeSize Time Throughput  
> > bytes  bytes   bytessecs.10^6bits/sec  
> > 
> >  87380  16384  1638414.00   6.05   
> > 
> > -> after patch :
> > 
> > Recv   SendSend  
> > Socket Socket  Message  Elapsed  
> > Size   SizeSize Time Throughput  
> > bytes  bytes   bytessecs.10^6bits/sec  
> > 
> >  87380  16384  1638410.0018509.73   
> 
> "seem to help"?  Was previous performance fully restored?

I did some tests this morning on my HP Z600, and got same numbers than
3.5.0

Of course, its a bit difficult to say, because there is no
CONFIG_PFMEMALLOC to test real impact.



--
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: [ 04/16] drm/i915: correctly order the ring init sequence

[Herton Ronaldo Krzesinski]

On Sun, Aug 19, 2012 at 08:56:03PM -0700, Greg Kroah-Hartman wrote:
> From: Greg KH 
> 
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Daniel Vetter 
> 
> commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.
> 
> We may only start to set up the new register values after having
> confirmed that the ring is truely off. Otherwise the hw might lose the
> newly written register values. This is caught later on in the init
> sequence, when we check whether the register writes have stuck.
> 
> Reviewed-by: Jani Nikula 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
> Tested-by: Yang Guang 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Greg Kroah-Hartman 
[...]

I had the same problem as on 3.2 with this change, i915 stopped working
unable to initialize render ring, eg. on one of the boots here:
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f003 
head 1020 tail  start 1000 

But unlike I was expecting as with 3.2 case, picking commit
f01db988ef6f6c70a6cc36ee71e4a98a68901229 ("drm/i915: Add wait_for in
init_ring_common") here isn't enough, it continues to fail even if I
try to increase the delay in the wait_for, I'm not sure why yet... may
be something else is going on, or 3.0 has something else missing.

Also the same proposed patch for 3.4.10 gives the same problem, but
picking f01db988ef6f6c70a6cc36ee71e4a98a68901229 there made things work
again like happend on first 3.2.28 proposed update. Only 3.0
is misteriously failing either way here.

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

Re: [RFC PATCH 0/6] virtio-trace: Support virtio-trace

[Amit Shah]

On (Tue) 21 Aug 2012 [11:47:16], Rusty Russell wrote:
> On Thu, 9 Aug 2012 15:46:20 +0530, Amit Shah  wrote:
> > Hi,
> > 
> > On (Tue) 24 Jul 2012 [11:36:57], Yoshihiro YUNOMAE wrote:
> > > Hi All,
> > > 
> > > The following patch set provides a low-overhead system for collecting 
> > > kernel
> > > tracing data of guests by a host in a virtualization environment.
> > 
> > So I just have one minor comment, please post a non-RFC version of the
> > patch.
> > 
> > Since you have an ACK from Steven for the ftrace patch, I guess Rusty
> > can push this in via his virtio tree?
> > 
> > I'll ack the virtio-console bits in the next series you send.
> 
> You didn't Ack, BTW.  At least, AFAICT.

Ah, sorry.  Will do that now.

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

Re: [RFC PATCH 0/6] virtio-trace: Support virtio-trace

[Rusty Russell]

On Thu, 9 Aug 2012 15:46:20 +0530, Amit Shah  wrote:
> Hi,
> 
> On (Tue) 24 Jul 2012 [11:36:57], Yoshihiro YUNOMAE wrote:
> > Hi All,
> > 
> > The following patch set provides a low-overhead system for collecting kernel
> > tracing data of guests by a host in a virtualization environment.
> 
> So I just have one minor comment, please post a non-RFC version of the
> patch.
> 
> Since you have an ACK from Steven for the ftrace patch, I guess Rusty
> can push this in via his virtio tree?
> 
> I'll ack the virtio-console bits in the next series you send.

You didn't Ack, BTW.  At least, AFAICT.

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/

linux-next: manual merge of the signal tree with Linus' tree

[Stephen Rothwell]

Hi Al,

Today's linux-next merge of the signal tree got a conflict in
arch/alpha/kernel/process.c between commit 28d353d9891c ("alpha: take
kernel_execve() out of entry.S") from Linus' tree and commit 68f596a7a045
("alpha: rewrite kernel_execve in C") from the signal tree.

These appear to be the same patch with a slight difference in this file.
I just used the version from Linus' tree.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpV2DU8ITZdv.pgp
Description: PGP signature

Re: [PATCH v6 1/4] xattr: extract simple_xattr code from tmpfs

[Hugh Dickins]

On Mon, 20 Aug 2012, Aristeu Rozanski wrote:
> On Mon, Aug 20, 2012 at 12:10:09AM -0700, Hugh Dickins wrote:
> > Yes, it looks nice to me.  I might have preferred more as inlines in
> > the header file to lower the slight init/evict overhead, and I don't
> > see why __simple_xattr_set() isn't using simple_xattr_alloc() in the
> > same way that shmem_xattr_set() used shmem_xattr_alloc().  But none
> > of that matters:
> > 
> > Acked-by: Hugh Dickins 
> 
> I can submit additional patches to fix these. What functions you want
> inlined?

Oh, thank you.  I was thinking that it's uncommon for tmpfs files to
have xattrs (and the same probably true of other filesystems), so it's
best to minimize xattrs impact on shared paths.  If simple_xattrs_init()
and simple_xattrs_free() can be static inline functions in linux/xattr.h,
that would be nice.

Probably more important would be to remove spin_lock() and spin_unlock()
(and INIT_LIST_HEAD) from simple_xattrs_free() - those are unnecessary
in shmem_evict_inode(), and wouldn't they be unnecessary whenever
simple_xattrs_free() gets called?

Hugh

> 
> On why __simple_xattr_set() is not using simple_xattr_alloc(), there's
> no reason to be that way, I missed it.
> 
> Thanks for reviewing!
> 
> -- 
> Aristeu
> 
> 
--
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: root=PARTUUID for MBR/NT disk signatures?

[Will Drewry]

On Mon, Aug 20, 2012 at 1:30 PM, Stephen Warren  wrote:
> On 08/20/2012 12:22 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Aug 17, 2012 at 04:10:52PM -0600, Stephen Warren wrote:
>>> I was considering extending the kernel command-line option
>>> root=PARTUUID= to also support MBR (NT disk signatures). I was thinking
>>> of a syntax along the lines of:
>>>
>>> root=PARTUUID=-PP[/PARTNROFF=%d]
>>>
>>> ... where  is the hex representation of the NT disk signature,
>>> and PP is the hex representation of the partition number. Like GPT,
>>> /PARTNROFF could be used too if desired.
>>>
>>> Related, I was thinking of changing struct partition_meta_info's uuid
>>> field to be a string, so that it could simply be strcmp'd against the
>>> UUID value on the kernel command-line. That way, the type of the UUID is
>>> irrelevant.
>>>
>>> Does anyone have any objection to that?
>>
>> Wouldn't that be able to break setups which work currently?
>
> I don't believe so:
>
> Since the newly supported UUID syntax wouldn't ever match any EFI UUID
> (the lengths differ in all cases), I don't believe the new syntax would
> affect behavior for any existing usage.
>
> Obviously, part_efi.c would be modified to initialize struct
> partition_meta_info's uuid field to the appropriate string
> representation of the UUID so that the str(case)cmp would still succeed
> for existing command-lines. I ended up coding up that part of the change
> late Friday, and the feature was certainly still working OK.

Functionally, I suspect this will work fine, but I am concerned that
it is a bad move from an efficiency perspective (not unfixable
though).  Right now, the user-supplied value is converted from
string-uuid to packed-uuid.  This is then memcmp'd across any and all
partitions - be it 2 or 200 - across all attached storage.  If we move
to a pure string, then we end up needing to unpack every packed UUID
at disk scan time (or search, depending on impl) rather than just the
one user supplied value.

Perhaps the cost is negligible on modern machines, but it seems like
the wrong place to put the cost (per entry rather than per search
value).

I'd be happy to test out any proposed patch to see if I can measure
any differences in my specific environments, but I don't know if it
will slow down partition scanning for other EFI UUID users out there.
Maybe the NT disk sigs could be massaged to be memcmp friendly instead
of the opposite?

thanks!
will
--
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 71/74] lto, kprobes: Use KSYM_NAME_LEN to size identifier buffers

[Ananth N Mavinakayanahalli]

On Sat, Aug 18, 2012 at 07:57:07PM -0700, Andi Kleen wrote:
> From: Joe Mario 
> 
> Use KSYM_NAME_LEN to size identifier buffers, so that it can
> be easier increased.
> 
> Cc: ana...@in.ibm.com
> Signed-off-by: Joe Mario 
> Signed-off-by: Andi Kleen 

Acked-by: Ananth N Mavinakayanahalli 

> ---
>  kernel/kprobes.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index c62b854..b9bd2a8 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1955,7 +1955,7 @@ static int __init init_kprobes(void)
>  {
>   int i, err = 0;
>   unsigned long offset = 0, size = 0;
> - char *modname, namebuf[128];
> + char *modname, namebuf[KSYM_NAME_LEN];
>   const char *symbol_name;
>   void *addr;
>   struct kprobe_blackpoint *kb;
> @@ -2081,7 +2081,7 @@ static int __kprobes show_kprobe_addr(struct seq_file 
> *pi, void *v)
>   const char *sym = NULL;
>   unsigned int i = *(loff_t *) v;
>   unsigned long offset = 0;
> - char *modname, namebuf[128];
> + char *modname, namebuf[KSYM_NAME_LEN];
> 
>   head = _table[i];
>   preempt_disable();
> -- 
> 1.7.7.6

--
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] Fixes for dw_dmac and atmel-mci for AP700x

[viresh kumar]

Hi Hein,

I have added linux-kernel list in cc as there might be other users of
this patch.
Also, please try to keep spear-devel list in cc for dw_dmac as we are using this
driver for SPEAr.

On Sun, Aug 19, 2012 at 9:36 PM, Hein Tibosch  wrote:
> Hi Hans-Christian,
>
> Do you know to which list I could send the patch(es) below?
>
> Viresh Kumar: did you have an urgent reason to replace __raw_readl
> and __raw_writel with readl/writel in the dw_dmac module?
> (see 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/044799.html)
>
> Here's a draft:
>
> Because of the changes since 2.6.38 to dw_dmac.c and atmel-mci.c,
> the MCI driver on the AP700x platforms didn't work anymore using DMA.
> The PIO method still worked well.
>
> I found several problems. The patch below makes it work again.
> It was tested on an atngw100 board.
>
> atmel-mci:
> - The AP700x has an MCI controller with version 0x210
>   Therefor it was supposed to work the PDC (peripheral DMA
>   controller). However, in this CPU the PDC is not connected
>   to the MCI.
> - When using DMA, the driver was accessing a register ATMCI_DMA
>   at offset 0x50, which is undefined for the AP700x. But it
>   probably doesn't hurt either...
>
> dw_dmac:
> - After 2.6.39, the registers were accessed using readl/writel
>   in stead of the __raw_readl and __raw_writel causing a 16-bit
>   swap of all values (little endian access)

A!! Firstly we can't use __raw* for architectures >= ARMv6. It is not
only for endianess but for memory barriers. Why are they getting swapped
for your case? Does your processor and dw_dmac have different endianess?

And if i am not wrong, we should always try not to use __raw* variants just
due to endianess things... instead use either readl/writel OR
readl_/writel_ relaxed.
I am not sure if relaxed versions are available for architectures
other than ARM.

> - Access to memory was sometimes done in chunks of 64-bits,
>   which gives an undefined value of 0x03 for SRC/DST_TR_WIDTH
>   field in the CTLxL register

Looks fine. But there should be a separate patch for this.

> - The SMS field in the CTLxL register received the wrong value:
>   0 in stead of 1

I believe it is not for dw_dmac?

--
viresh

> Signed-off-by: Hein Tibosch 
> ---
>  arch/avr32/mach-at32ap/at32ap700x.c |6 ++
>  drivers/dma/dw_dmac.c   |8 
>  drivers/dma/dw_dmac_regs.h  |8 
>  drivers/mmc/host/atmel-mci.c|   19 ---
>  4 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/arch/avr32/mach-at32ap/at32ap700x.c 
> b/arch/avr32/mach-at32ap/at32ap700x.c
> index 0445c4f..06b6eff 100644
> --- a/arch/avr32/mach-at32ap/at32ap700x.c
> +++ b/arch/avr32/mach-at32ap/at32ap700x.c
> @@ -1355,6 +1355,12 @@ at32_add_device_mci(unsigned int id, struct 
> mci_platform_data *data)
> | DWC_CFGH_DST_PER(1));
> slave->sdata.cfg_lo &= ~(DWC_CFGL_HS_DST_POL
> | DWC_CFGL_HS_SRC_POL);
> +   /* value for SMS: Source Master Select */
> +   slave->sdata.src_master = 1;
> +   /* value for DMS: Destination Master Select */
> +   slave->sdata.dst_master = 0;
> +   /* SRC/DST_TR_WIDTH register only accepts 0,1,2 */
> +   slave->sdata.max_mem_width = 2;
> data->dma_slave = slave;
>  diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 7212961..a4bdf1d 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -754,6 +754,10 @@ dwc_prep_slave_sg(struct dma_chan *chan, struct 
> scatterlist *sgl,
> mem_width = 1;
> else
> mem_width = 0;
> +   /* Some controllers don't support 64-bits mem access 
> */
> +   if (dws->max_mem_width &&
> +   mem_width > dws->max_mem_width)
> +   mem_width = dws->max_mem_width;
>   slave_sg_todev_fill_desc:
> desc = dwc_desc_get(dwc);
> @@ -821,6 +825,10 @@ slave_sg_todev_fill_desc:
> mem_width = 1;
> else
> mem_width = 0;
> +   /* Some controllers don't support 64-bits mem access 
> */
> +   if (dws->max_mem_width &&
> +   mem_width > dws->max_mem_width)
> +   mem_width = dws->max_mem_width;
>   slave_sg_fromdev_fill_desc:
> desc = dwc_desc_get(dwc);
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index f298f69..b380d5f 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -176,9 +176,9 @@ __dwc_regs(struct dw_dma_chan *dwc)
>  }
>   #define channel_readl(dwc, name) \
> -   readl(&(__dwc_regs(dwc)->name))
> +   __raw_readl(&(__dwc_regs(dwc)->name))
>  #define 

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

[Cui, Dexuan]

Bjorn Helgaas wrote on 2012-08-21:
> On Mon, Aug 20, 2012 at 10:10 AM, Bjorn Helgaas 
> wrote:
> 
>> So I'll try pulling your branch (I'll do something about the tsi721.c
>> stuff myself).
> 
> I pulled this into
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> pci/jiang-pcie-cap with the following changes:
> 
>   - Dropped some "pci_" prefixes on internal functions in access.c -
>   Minor restructure of pcie_capability_read_*() - Removed export of
>   pcie_capability_reg_implemented() - Reworked
>   reset_intel_82599_sfp_virtfn() to check for FLR bit in DEVCAP rather
>   than using pcie_capability_reg_implemented() - Split driver patches
>   into one driver per patch - Fixed myri10ge_toggle_relaxed() --
>   previous code returned useful value, but your patch made it always
>   return zero - Use 16-bit, not 32-bit, accesses for DEVCTL, DEVCTL2
>   (tsi721)
> I am still concerned about reset_intel_82599_sfp_virtfn().  It looks
> wrong and possibly unnecessary.  It looks wrong because it sets
> PCI_EXP_DEVCTL_BCR_FLR and blindly clears all other bits in
> PCI_EXP_DEVCTL.  Most of the bits are probably cleared by the FLR
> anyway, but Aux Power PM Enable is RWS ("sticky"), so it is *not*
> modified by FLR.  Therefore, using reset_intel_82599_sfp_virtfn() has
> the probably unintended side effect of clearing Aux Power PM Enable.
> 
> It looks possibly unnecessary because the generic pcie_flr() does
> essentially the same thing, so it's not clear why we need a special
> case for 82599.
> 
> Yu or Dexuan, can you comment on these 82599 questions?
(Removed Yu Zhao from the To list since he has left Intel and the same
email is now used by another unrelated person...)

Hi Bjorn
I think reset_intel_82599_sfp_virtfn() is correct AND necessary.
(pcie_flr() doesn't work here)

Please note the 82599 VF is a special PCIe device that doesn't report
PCIe FLR capability though actually it does support that.
That is why we put it in quirks.c. :-)

The PCI_EXP_DEVCTL_AUX_PME bit of the 82599 VF is read-only and
always zero.

Please see 
http://www.intel.com/content/dam/doc/datasheet/82599-10-gbe-controller-datasheet.pdf
9.5 Virtual Functions Configuration Space
  Table 9.7 VF PCIe Configuration Space
  9.5.2.2.1 VF Device Control Register (0xA8; RW)

Surely I should say sorry for not putting these necessary information
in the git commit description.
Now I don't know why I forgot to do that at that time(almost 3 years ago...).

It would be great if you could help to add a comment in the code. :-)

> 
> The proposed new code is here:
> http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=blob;f=driver
> s/pci/
> quirks.c;h=9abbf56e93fe5c98364a7dfe2b0b724047dfa4a9;hb=ef529bf0cb560
> 6ff5bd1422d2d2700a821d8218b#l3082
> 
> Bjorn

Thanks,
-- Dexuan

--
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] vme: vme_tsi148.c: fix to use list_for_each_safe() when delete list items

[Wei Yongjun]

From: Wei Yongjun 

Since we will be removing items off the list using list_del() we need
to use a safer version of the list_for_each() macro aptly named
list_for_each_safe(). 

Signed-off-by: Wei Yongjun 
---
 drivers/vme/bridges/vme_tsi148.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index 880d924..5fbd08f 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -2350,7 +2350,7 @@ static int tsi148_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 {
int retval, i, master_num;
u32 data;
-   struct list_head *pos = NULL;
+   struct list_head *pos = NULL, *n;
struct vme_bridge *tsi148_bridge;
struct tsi148_driver *tsi148_device;
struct vme_master_resource *master_image;
@@ -2615,28 +2615,28 @@ err_reg:
 err_crcsr:
 err_lm:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->lm_resources) {
+   list_for_each_safe(pos, n, _bridge->lm_resources) {
lm = list_entry(pos, struct vme_lm_resource, list);
list_del(pos);
kfree(lm);
}
 err_dma:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->dma_resources) {
+   list_for_each_safe(pos, n, _bridge->dma_resources) {
dma_ctrlr = list_entry(pos, struct vme_dma_resource, list);
list_del(pos);
kfree(dma_ctrlr);
}
 err_slave:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->slave_resources) {
+   list_for_each_safe(pos, n, _bridge->slave_resources) {
slave_image = list_entry(pos, struct vme_slave_resource, list);
list_del(pos);
kfree(slave_image);
}
 err_master:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->master_resources) {
+   list_for_each_safe(pos, n, _bridge->master_resources) {
master_image = list_entry(pos, struct vme_master_resource,
list);
list_del(pos);


--
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] vme: vme_ca91cx42.c: use list_for_each_safe() when delete list items

[Wei Yongjun]

From: Wei Yongjun 

Since we will be removing items off the list using list_del() we need
to use a safer version of the list_for_each() macro aptly named
list_for_each_safe(). We should use the safe macro if the loop
involves deletions of items.

Signed-off-by: Wei Yongjun 
---
 drivers/vme/bridges/vme_ca91cx42.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/vme/bridges/vme_ca91cx42.c 
b/drivers/vme/bridges/vme_ca91cx42.c
index e0df92e..1425d22c 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -1603,7 +1603,7 @@ static int ca91cx42_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 {
int retval, i;
u32 data;
-   struct list_head *pos = NULL;
+   struct list_head *pos = NULL, *n;
struct vme_bridge *ca91cx42_bridge;
struct ca91cx42_driver *ca91cx42_device;
struct vme_master_resource *master_image;
@@ -1821,28 +1821,28 @@ err_reg:
ca91cx42_crcsr_exit(ca91cx42_bridge, pdev);
 err_lm:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->lm_resources) {
+   list_for_each_safe(pos, n, _bridge->lm_resources) {
lm = list_entry(pos, struct vme_lm_resource, list);
list_del(pos);
kfree(lm);
}
 err_dma:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->dma_resources) {
+   list_for_each_safe(pos, n, _bridge->dma_resources) {
dma_ctrlr = list_entry(pos, struct vme_dma_resource, list);
list_del(pos);
kfree(dma_ctrlr);
}
 err_slave:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->slave_resources) {
+   list_for_each_safe(pos, n, _bridge->slave_resources) {
slave_image = list_entry(pos, struct vme_slave_resource, list);
list_del(pos);
kfree(slave_image);
}
 err_master:
/* resources are stored in link list */
-   list_for_each(pos, _bridge->master_resources) {
+   list_for_each_safe(pos, n, _bridge->master_resources) {
master_image = list_entry(pos, struct vme_master_resource,
list);
list_del(pos);
@@ -1868,7 +1868,7 @@ err_struct:
 
 static void ca91cx42_remove(struct pci_dev *pdev)
 {
-   struct list_head *pos = NULL;
+   struct list_head *pos = NULL, *n;
struct vme_master_resource *master_image;
struct vme_slave_resource *slave_image;
struct vme_dma_resource *dma_ctrlr;
@@ -1905,28 +1905,28 @@ static void ca91cx42_remove(struct pci_dev *pdev)
ca91cx42_crcsr_exit(ca91cx42_bridge, pdev);
 
/* resources are stored in link list */
-   list_for_each(pos, _bridge->lm_resources) {
+   list_for_each_safe(pos, n, _bridge->lm_resources) {
lm = list_entry(pos, struct vme_lm_resource, list);
list_del(pos);
kfree(lm);
}
 
/* resources are stored in link list */
-   list_for_each(pos, _bridge->dma_resources) {
+   list_for_each_safe(pos, n, _bridge->dma_resources) {
dma_ctrlr = list_entry(pos, struct vme_dma_resource, list);
list_del(pos);
kfree(dma_ctrlr);
}
 
/* resources are stored in link list */
-   list_for_each(pos, _bridge->slave_resources) {
+   list_for_each_safe(pos, n, _bridge->slave_resources) {
slave_image = list_entry(pos, struct vme_slave_resource, list);
list_del(pos);
kfree(slave_image);
}
 
/* resources are stored in link list */
-   list_for_each(pos, _bridge->master_resources) {
+   list_for_each_safe(pos, n, _bridge->master_resources) {
master_image = list_entry(pos, struct vme_master_resource,
list);
list_del(pos);


--
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] spi-topcliff-pch: fix to use list_for_each_entry_safe() when delete items

[Wei Yongjun]

From: Wei Yongjun 

Since we will be removing items off the list using list_del() we need
to use a safer version of the list_for_each_entry() macro aptly named
list_for_each_entry_safe(). We should use the safe macro if the loop
involves deletions of items.

Signed-off-by: Wei Yongjun 
---
 drivers/spi/spi-topcliff-pch.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index cd56dcf..309b717 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -615,7 +615,7 @@ static void pch_spi_set_tx(struct pch_spi_data *data, int 
*bpw)
int size;
u32 n_writes;
int j;
-   struct spi_message *pmsg;
+   struct spi_message *pmsg, *tmp;
const u8 *tx_buf;
const u16 *tx_sbuf;
 
@@ -656,7 +656,7 @@ static void pch_spi_set_tx(struct pch_spi_data *data, int 
*bpw)
if (!data->pkt_rx_buff) {
/* flush queue and set status of all transfers to -ENOMEM */
dev_err(>master->dev, "%s :kzalloc failed\n", __func__);
-   list_for_each_entry(pmsg, data->queue.next, queue) {
+   list_for_each_entry_safe(pmsg, tmp, data->queue.next, queue) {
pmsg->status = -ENOMEM;
 
if (pmsg->complete != 0)
@@ -703,7 +703,7 @@ static void pch_spi_set_tx(struct pch_spi_data *data, int 
*bpw)
 
 static void pch_spi_nomore_transfer(struct pch_spi_data *data)
 {
-   struct spi_message *pmsg;
+   struct spi_message *pmsg, *tmp;
dev_dbg(>master->dev, "%s called\n", __func__);
/* Invoke complete callback
 * [To the spi core..indicating end of transfer] */
@@ -740,7 +740,7 @@ static void pch_spi_nomore_transfer(struct pch_spi_data 
*data)
dev_dbg(>master->dev,
"%s suspend/remove initiated, flushing queue\n",
__func__);
-   list_for_each_entry(pmsg, data->queue.next, queue) {
+   list_for_each_entry_safe(pmsg, tmp, data->queue.next, queue) {
pmsg->status = -EIO;
 
if (pmsg->complete)
@@ -1187,7 +1187,7 @@ static void pch_spi_handle_dma(struct pch_spi_data *data, 
int *bpw)
 
 static void pch_spi_process_messages(struct work_struct *pwork)
 {
-   struct spi_message *pmsg;
+   struct spi_message *pmsg, *tmp;
struct pch_spi_data *data;
int bpw;
 
@@ -1199,7 +1199,7 @@ static void pch_spi_process_messages(struct work_struct 
*pwork)
if (data->board_dat->suspend_sts || (data->status == STATUS_EXITING)) {
dev_dbg(>master->dev, "%s suspend/remove initiated,"
"flushing queue\n", __func__);
-   list_for_each_entry(pmsg, data->queue.next, queue) {
+   list_for_each_entry_safe(pmsg, tmp, data->queue.next, queue) {
pmsg->status = -EIO;
 
if (pmsg->complete != 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/

[PATCH 1/1] xhci: Unconditionally switch ports to xHCI on powerup

[manoj . iyer]

From: Manoj Iyer 

USB 3.0 devices show up as high-speed devices on powerup, after an
s3 cycle they are correctly recognized as SuperSpeed. At powerup
unconditionally switch the port to xHCI like we do when we resume
from suspend.

BugLink: http://bugs.launchpad.net/bugs/1000424

Signed-off-by: Manoj Iyer 
---
 drivers/usb/host/xhci-pci.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9bfd4ca11..5c8dbea 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -48,6 +48,14 @@ static int xhci_pci_reinit(struct xhci_hcd *xhci, struct 
pci_dev *pdev)
if (!pci_set_mwi(pdev))
xhci_dbg(xhci, "MWI active\n");
 
+   /*
+* USB SuperSpeed ports are recognized as HighSpeed ports on powerup
+* unconditionally switch the ports to xHCI like we do when resume
+* from suspend.
+*/
+   if (usb_is_intel_switchable_xhci(pdev))
+   usb_enable_xhci_ports(pdev);
+
xhci_dbg(xhci, "Finished xhci_pci_reinit\n");
return 0;
 }
-- 
1.7.9.5

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

[PATCH 0/1] xhci: Unconditionally switch ports to xHCI on powerup

[manoj . iyer]

From: Manoj Iyer 

USB 3.0 devices show up as high-speed devices on powerup, after an
s3 cycle they are correctly recognized as SuperSpeed. At powerup
unconditionally switch the port to xHCI like we do when we resume
from suspend.

BugLink: http://bugs.launchpad.net/bugs/1000424

Test results:
This patch was tested by me on a Lenovo system:

00:14.0 USB controller [0c03]: Intel Corporation Panther Point USB xHCI Host Con
troller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo Device [17aa:5002]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the workqueues tree with the hid tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
drivers/hid/hid-picolcd.c between commit fabdbf2fd22f ("HID: picoLCD:
split driver code") from the hid tree and commit 43829731dd37
("workqueue: deprecate flush[_delayed]_work_sync()") from the workqueues
tree.

The former commit moved the code changed by the latter into a new file
(and removed the old file) and then a later commit removed the call to
flush_work_sync().  I just removed the file.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpDieI8aH5hM.pgp
Description: PGP signature

Re: [PATCH]mm: fix-up zone present pages

[Petr Tesarik]

Dne Po 20. srpna 2012 08:38:10 wujianguo napsal(a):
> From: Jianguo Wu 
> 
> Hi all,
>   I think zone->present_pages indicates pages that buddy system can
> management, it should be:
>   zone->present_pages = spanned pages - absent pages - bootmem pages,
> but now:
>   zone->present_pages = spanned pages - absent pages - memmap pages.
> spanned pages：total size, including holes.
> absent pages: holes.
> bootmem pages: pages used in system boot, managed by bootmem allocator.
> memmap pages: pages used by page structs.

Absolutely. The memory allocated to page structs should be counted in.

> This may cause zone->present_pages less than it should be.
> For example, numa node 1 has ZONE_NORMAL and ZONE_MOVABLE,
> it's memmap and other bootmem will be allocated from ZONE_MOVABLE,
> so ZONE_NORMAL's present_pages should be spanned pages - absent pages,
> but now it also minus memmap pages(free_area_init_core), which are actually
> allocated from ZONE_MOVABLE. When offline all memory of a zone, This will
> cause zone->present_pages less than 0, because present_pages is unsigned
> long type, it is actually a very large integer, it indirectly caused
> zone->watermark[WMARK_MIN] become a large
> integer(setup_per_zone_wmarks()), than cause totalreserve_pages become a
> large integer(calculate_totalreserve_pages()), and finally cause memory
> allocating failure when fork process(__vm_enough_memory()).
> 
> [root@localhost ~]# dmesg
> -bash: fork: Cannot allocate memory
> 
> I think bug described in http://marc.info/?l=linux-mm=134502182714186=2
> is also caused by wrong zone present pages.

And yes, I can confirm that the bug I reported is caused by a too low number 
for the present pages counter. Your patch does fix the bug for me.

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

[PATCH] mm/ia64: fix a memory block size bug

[wujianguo]

From: Jianguo Wu 

Hi all,
I found following definition in include/linux/memory.h, in my IA64
platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE will be 0.
#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)

Because MIN_MEMORY_BLOCK_SIZE is 32bits, so MIN_MEMORY_BLOCK_SIZE(1 << 
32)
will equal to 0. This will cause wrong system memory infomation in sysfs. I 
think
it should be:
#define MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS)

linux-drf:/sys/devices/system/memory # ll
total 0
-r--r--r-- 1 root root 65536 Aug 20 02:35 block_size_bytes
drwxr-xr-x 3 root root 0 Aug 20 02:19 memory0
drwxr-xr-x 2 root root 0 Aug 20 02:35 power
-rw-r--r-- 1 root root 65536 Aug 20 02:35 uevent

linux-drf:/sys/devices/system/memory # cat block_size_bytes
0

linux-drf:/sys/devices/system/memory/memory0 # cat *
8000
cat: node0: Is a directory
cat: node1: Is a directory
cat: node2: Is a directory
cat: node3: Is a directory
0
8000
cat: power: Is a directory
1
online
cat: subsystem: Is a directory

And "echo offline > memory0/state" will cause following call trace:

kernel BUG at mm/memory_hotplug.c:885!
sh[6455]: bugcheck! 0 [1]

Pid: 6455, CPU 0, comm:   sh
psr : 101008526030 ifs : 8fa4 ip  : []Not 
tainted (3.6.0-rc1)
ip is at offline_pages+0x210/0xee0
unat:  pfs : 0fa4 rsc : 0003
rnat: a001008f2d50 bsps:  pr  : 65519a96659a9565
ldrs:  ccv : 010b9263f310 fpsr: 0009804c0270033f
csd :  ssd : 
b0  : a001008c40f0 b6  : a00100473980 b7  : a001000106d0
f6  : 0 f7  : 1003e85c9354c
f8  : 1003e0044b82fa09b5a53 f9  : 1003e00d65cd62abf
f10 : 1003efd02efdec682803d f11 : 1003e0042
r1  : a0010152c2e0 r2  : 6ada r3  : fffe
r8  : 0026 r9  : a0010121cc18 r10 : a001013309f0
r11 : 65519a96659a19e9 r12 : e0070a91fdf0 r13 : e0070a91
r14 : 6ada r15 : 4000 r16 : 6ad8356c
r17 : a001019a525e r18 : 7fff r19 : 
r20 : 6ad6 r21 : 6ad6 r22 : a0010133bec8
r23 : 6ad4 r24 : 0002 r25 : 82260038
r26 : 04f9 r27 : 04f8 r28 : 0001cf98
r29 : 0038 r30 : a001019a5ae0 r31 : 0001cf60

Call Trace:
 [] show_stack+0x80/0xa0
sp=e0070a91f9b0 bsp=e0070a9115e0
 [] show_regs+0x640/0x920
sp=e0070a91fb80 bsp=e0070a911588
 [] die+0x190/0x2c0
sp=e0070a91fb90 bsp=e0070a911548
 [] die_if_kernel+0x50/0x80
sp=e0070a91fb90 bsp=e0070a911518
 [] ia64_bad_break+0x3d0/0x6e0
sp=e0070a91fb90 bsp=e0070a9114f0
 [] ia64_native_leave_kernel+0x0/0x270
sp=e0070a91fc20 bsp=e0070a9114f0
 [] offline_pages+0x210/0xee0
sp=e0070a91fdf0 bsp=e0070a9113c8
 [] alloc_pages_current+0x180/0x2a0
sp=e0070a91fe20 bsp=e0070a9113a

This patch is trying to fix the bug.

Signed-off-by: Jianguo Wu 
---
 include/linux/memory.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/memory.h b/include/linux/memory.h
index 1ac7f6e..ff9a9f8 100644
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -19,7 +19,7 @@
 #include 
 #include 

-#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
+#define MIN_MEMORY_BLOCK_SIZE (1UL << SECTION_SIZE_BITS)

 struct memory_block {
unsigned long start_section_nr;
-- 
1.7.6.1




.



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

Re: [PATCH 4/8] time: Condense timekeeper.xtime into xtime_sec

[John Stultz]

On 08/20/2012 01:04 PM, Andreas Schwab wrote:

John Stultz  writes:


Huh.  Yea, that looks fine.  And without the
__timekeeping_inject_sleeptime() call, the system resumed ok?

Yes, it does.


So I'm mostly still stumped on this. But I did find one possible related 
bugfix that maybe you can try?


Let me know if the patch below dodges the problem, and if not, please 
send me the JDB printk output.
(if the resume hangs without any output, add a "return;" before the 
tk_xtime_add() call between the JDB printks).


thanks
-john



diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index e16af19..1a9b9c5 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -115,6 +115,7 @@ static void tk_xtime_add(struct timekeeper *tk, const 
struct timespec *ts)
 {
tk->xtime_sec += ts->tv_sec;
tk->xtime_nsec += (u64)ts->tv_nsec << tk->shift;
+   tk_normalize_xtime(tk);
 }
 
 static void tk_set_wall_to_mono(struct timekeeper *tk, struct timespec wtm)

@@ -695,9 +696,22 @@ static void __timekeeping_inject_sleeptime(struct 
timekeeper *tk,
"sleep delta value!\n");
return;
}
+
+   printk("JDB: pre xt %ld:%ld  wtm: %ld:%ld st: %ld:%ld\n",
+   tk_xtime(tk).tv_sec, tk_xtime(tk).tv_nsec,
+   tk->wall_to_monotonic.tv_sec,tk->wall_to_monotonic.tv_nsec,
+   tk->total_sleep_time.tv_sec, tk->total_sleep_time.tv_nsec);
+   printk("JDB: Adding %ld:%ld\n", delta->tv_sec, delta->tv_nsec);
+
tk_xtime_add(tk, delta);
tk_set_wall_to_mono(tk, timespec_sub(tk->wall_to_monotonic, *delta));
tk_set_sleep_time(tk, timespec_add(tk->total_sleep_time, *delta));
+
+   printk("JDB: post xt %ld:%ld  wtm: %ld:%ld st: %ld:%ld\n",
+   tk_xtime(tk).tv_sec, tk_xtime(tk).tv_nsec,
+   tk->wall_to_monotonic.tv_sec,tk->wall_to_monotonic.tv_nsec,
+   tk->total_sleep_time.tv_sec, tk->total_sleep_time.tv_nsec);
+
 }
 
 /**


--
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] regulator: max8907: Properly set pmic pointer in max8907_regulator_remove()

[Axel Lin]

2012/8/20 Stephen Warren :
> On 08/18/2012 12:33 AM, Axel Lin wrote:
>> Add missing platform_get_drvdata() call in max8907_regulator_remove(), this
>> fixes below build warning:
>>
>>   CC [M]  drivers/regulator/max8907-regulator.o
>> drivers/regulator/max8907-regulator.c: In function 
>> 'max8907_regulator_remove':
>> drivers/regulator/max8907-regulator.c:353:23: warning: 'pmic' is used 
>> uninitialized in this function [-Wuninitialized]
>
> That's odd; while this warning and the patch are obviously correct, I
> can't get my compiler to warn about it at all, and it usually is pretty
> strict about emitting warnings. Oh well.

I got this error message only when I compile it as a module. :-)

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

Re: [GIT PULL 1/2] Btrfs fixes

[Chris Samuel]

On 21/08/12 11:55, Linus Torvalds wrote:

> Read my -rc2 release notes.

Ahh, thanks (I'm not on LKML so didn't see those).

> TL;DR: I rejected big pull requests that didn't convince me. Make a
> damn good case for it, or send minimal fixes instead.

Can't argue with that!

> I'm tried of these "oops, what we sent you for -rc1 wasn't ready, so
> here's a thousand lines of changes" crap.

I can understand that with respect to the send/recv stuff, so it's
really down to Chris Mason to extract just the fixes to problems that
are in 3.5 and earlier and submit just those instead.

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC
--
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 v6 12/12] KVM: indicate readonly access fault

[Xiao Guangrong]

Introduce write_readonly_mem in mmio-exit-info to indicate this exit is
caused by write access on readonly memslot

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c   |   23 ++-
 include/linux/kvm.h  |3 +++
 include/linux/kvm_host.h |1 +
 virt/kvm/kvm_main.c  |3 +++
 4 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 42bbf41..6d7fe4a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3710,9 +3710,10 @@ int emulator_write_phys(struct kvm_vcpu *vcpu, gpa_t gpa,

ret = kvm_write_guest(vcpu->kvm, gpa, val, bytes);
if (ret < 0)
-   return 0;
+   return ret;
+
kvm_mmu_pte_write(vcpu, gpa, val, bytes);
-   return 1;
+   return 0;
 }

 struct read_write_emulator_ops {
@@ -3742,7 +3743,7 @@ static int read_prepare(struct kvm_vcpu *vcpu, void *val, 
int bytes)
 static int read_emulate(struct kvm_vcpu *vcpu, gpa_t gpa,
void *val, int bytes)
 {
-   return !kvm_read_guest(vcpu->kvm, gpa, val, bytes);
+   return kvm_read_guest(vcpu->kvm, gpa, val, bytes);
 }

 static int write_emulate(struct kvm_vcpu *vcpu, gpa_t gpa,
@@ -3807,7 +3808,8 @@ static int emulator_read_write_onepage(unsigned long 
addr, void *val,
if (ret)
goto mmio;

-   if (ops->read_write_emulate(vcpu, gpa, val, bytes))
+   ret = ops->read_write_emulate(vcpu, gpa, val, bytes);
+   if (!ret)
return X86EMUL_CONTINUE;

 mmio:
@@ -3829,6 +3831,7 @@ mmio:
frag->gpa = gpa;
frag->data = val;
frag->len = now;
+   frag->write_readonly_mem = (ret == -EPERM);

gpa += now;
val += now;
@@ -3842,8 +3845,8 @@ int emulator_read_write(struct x86_emulate_ctxt *ctxt, 
unsigned long addr,
struct x86_exception *exception,
struct read_write_emulator_ops *ops)
 {
+   struct kvm_mmio_fragment *frag;
struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
-   gpa_t gpa;
int rc;

if (ops->read_write_prepare &&
@@ -3875,17 +3878,18 @@ int emulator_read_write(struct x86_emulate_ctxt *ctxt, 
unsigned long addr,
if (!vcpu->mmio_nr_fragments)
return rc;

-   gpa = vcpu->mmio_fragments[0].gpa;
+   frag = >mmio_fragments[0];

vcpu->mmio_needed = 1;
vcpu->mmio_cur_fragment = 0;

-   vcpu->run->mmio.len = vcpu->mmio_fragments[0].len;
+   vcpu->run->mmio.len = frag->len;
vcpu->run->mmio.is_write = vcpu->mmio_is_write = ops->write;
vcpu->run->exit_reason = KVM_EXIT_MMIO;
-   vcpu->run->mmio.phys_addr = gpa;
+   vcpu->run->mmio.phys_addr = frag->gpa;
+   vcpu->run->mmio.write_readonly_mem = frag->write_readonly_mem;

-   return ops->read_write_exit_mmio(vcpu, gpa, val, bytes);
+   return ops->read_write_exit_mmio(vcpu, frag->gpa, val, bytes);
 }

 static int emulator_read_emulated(struct x86_emulate_ctxt *ctxt,
@@ -5525,6 +5529,7 @@ static int complete_mmio(struct kvm_vcpu *vcpu)
++frag;
run->exit_reason = KVM_EXIT_MMIO;
run->mmio.phys_addr = frag->gpa;
+   vcpu->run->mmio.write_readonly_mem = frag->write_readonly_mem;
if (vcpu->mmio_is_write)
memcpy(run->mmio.data, frag->data, frag->len);
run->mmio.len = frag->len;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index d808694..9d8002f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -226,6 +226,9 @@ struct kvm_run {
__u8  data[8];
__u32 len;
__u8  is_write;
+#ifdef __KVM_HAVE_READONLY_MEM
+   __u8 write_readonly_mem;
+#endif
} mmio;
/* KVM_EXIT_HYPERCALL */
struct {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 5972c98..c37b225 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -189,6 +189,7 @@ struct kvm_mmio_fragment {
gpa_t gpa;
void *data;
unsigned len;
+   bool write_readonly_mem;
 };

 struct kvm_vcpu {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3416f8a..0c7def7 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1456,6 +1456,9 @@ int kvm_write_guest_page(struct kvm *kvm, gfn_t gfn, 
const void *data,
unsigned long addr;

addr = gfn_to_hva(kvm, gfn);
+   if (addr == KVM_HVA_ERR_RO_BAD)
+   return -EPERM;
+
if (kvm_is_error_hva(addr))
return -EFAULT;
r = __copy_to_user((void __user *)addr + offset, data, len);
-- 
1.7.7.6

--
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 v6 11/12] KVM: introduce readonly memslot

[Xiao Guangrong]

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

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

Signed-off-by: Xiao Guangrong 
---
 Documentation/virtual/kvm/api.txt |   10 +++-
 arch/x86/include/asm/kvm.h|1 +
 arch/x86/kvm/mmu.c|9 
 arch/x86/kvm/x86.c|1 +
 include/linux/kvm.h   |6 ++-
 include/linux/kvm_host.h  |7 +--
 virt/kvm/kvm_main.c   |   96 ++---
 7 files changed, 102 insertions(+), 28 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index bf33aaa..b91bfd4 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -857,7 +857,8 @@ struct kvm_userspace_memory_region {
 };

 /* for kvm_memory_region::flags */
-#define KVM_MEM_LOG_DIRTY_PAGES  1UL
+#define KVM_MEM_LOG_DIRTY_PAGES(1UL << 0)
+#define KVM_MEM_READONLY   (1UL << 1)

 This ioctl allows the user to create or modify a guest physical memory
 slot.  When changing an existing slot, it may be moved in the guest
@@ -873,9 +874,12 @@ It is recommended that the lower 21 bits of 
guest_phys_addr and userspace_addr
 be identical.  This allows large pages in the guest to be backed by large
 pages in the host.

-The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which
+The flags field supports two flag, KVM_MEM_LOG_DIRTY_PAGES, which
 instructs kvm to keep track of writes to memory within the slot.  See
-the KVM_GET_DIRTY_LOG ioctl.
+the KVM_GET_DIRTY_LOG ioctl. Another flag is KVM_MEM_READONLY when the
+KVM_CAP_READONLY_MEM capability, it indicates the guest memory is read-only,
+that means, guest is only allowed to read it. Writes will be posted to
+userspace as KVM_EXIT_MMIO exits.

 When the KVM_CAP_SYNC_MMU capability, changes in the backing of the memory
 region are automatically reflected into the guest.  For example, an mmap()
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index 246617e..521bf25 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
@@ -25,6 +25,7 @@
 #define __KVM_HAVE_DEBUGREGS
 #define __KVM_HAVE_XSAVE
 #define __KVM_HAVE_XCRS
+#define __KVM_HAVE_READONLY_MEM

 /* Architectural interrupt line count. */
 #define KVM_NR_INTERRUPTS 256
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 5548971..8e312a2 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2647,6 +2647,15 @@ static void kvm_send_hwpoison_signal(unsigned long 
address, struct task_struct *

 static int kvm_handle_bad_page(struct kvm_vcpu *vcpu, gfn_t gfn, pfn_t pfn)
 {
+   /*
+* Do not cache the mmio info caused by writing the readonly gfn
+* into the spte otherwise read access on readonly gfn also can
+* caused mmio page fault and treat it as mmio access.
+* Return 1 to tell kvm to emulate it.
+*/
+   if (pfn == KVM_PFN_ERR_RO_FAULT)
+   return 1;
+
if (pfn == KVM_PFN_ERR_HWPOISON) {
kvm_send_hwpoison_signal(gfn_to_hva(vcpu->kvm, gfn), current);
return 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 704680d..42bbf41 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2175,6 +2175,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_GET_TSC_KHZ:
case KVM_CAP_PCI_2_3:
case KVM_CAP_KVMCLOCK_CTRL:
+   case KVM_CAP_READONLY_MEM:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2de335d..d808694 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -106,7 +106,8 @@ struct kvm_userspace_memory_region {
  * other bits are reserved for kvm internal use which are defined in
  * include/linux/kvm_host.h.
  */
-#define KVM_MEM_LOG_DIRTY_PAGES  1UL
+#define KVM_MEM_LOG_DIRTY_PAGES(1UL << 0)
+#define KVM_MEM_READONLY   (1UL << 1)

 /* for KVM_IRQ_LINE */
 struct kvm_irq_level {
@@ -621,6 +622,9 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_PPC_GET_SMMU_INFO 78
 #define KVM_CAP_S390_COW 79
 #define KVM_CAP_PPC_ALLOC_HTAB 80
+#ifdef __KVM_HAVE_READONLY_MEM
+#define KVM_CAP_READONLY_MEM 81
+#endif

 #ifdef KVM_CAP_IRQ_ROUTING

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a913ac7..5972c98 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -465,6 +465,7 @@ int gfn_to_page_many_atomic(struct kvm *kvm, gfn_t gfn, 
struct page **pages,

 struct page *gfn_to_page(struct kvm *kvm, gfn_t gfn);
 unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn);
+unsigned long gfn_to_hva_memslot(struct kvm_memory_slot *slot, gfn_t 

[PATCH v6 09/12] KVM: introduce KVM_HVA_ERR_BAD

[Xiao Guangrong]

Then, remove bad_hva and inline kvm_is_error_hva

Signed-off-by: Xiao Guangrong 
---
 include/linux/kvm_host.h |8 +++-
 virt/kvm/kvm_main.c  |   13 +
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 4fd33e0..b9bba60 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -82,6 +82,13 @@ static inline bool is_invalid_pfn(pfn_t pfn)
return !is_noslot_pfn(pfn) && is_error_pfn(pfn);
 }

+#define KVM_HVA_ERR_BAD(PAGE_OFFSET)
+
+static inline bool kvm_is_error_hva(unsigned long addr)
+{
+   return addr == PAGE_OFFSET;
+}
+
 #define KVM_ERR_PTR_BAD_PAGE   (ERR_PTR(-ENOENT))

 static inline bool is_error_page(struct page *page)
@@ -430,7 +437,6 @@ id_to_memslot(struct kvm_memslots *slots, int id)
return slot;
 }

-int kvm_is_error_hva(unsigned long addr);
 int kvm_set_memory_region(struct kvm *kvm,
  struct kvm_userspace_memory_region *mem,
  int user_alloc);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c89d1b5..e3e1658 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -931,17 +931,6 @@ void kvm_disable_largepages(void)
 }
 EXPORT_SYMBOL_GPL(kvm_disable_largepages);

-static inline unsigned long bad_hva(void)
-{
-   return PAGE_OFFSET;
-}
-
-int kvm_is_error_hva(unsigned long addr)
-{
-   return addr == bad_hva();
-}
-EXPORT_SYMBOL_GPL(kvm_is_error_hva);
-
 struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
 {
return __gfn_to_memslot(kvm_memslots(kvm), gfn);
@@ -988,7 +977,7 @@ static unsigned long gfn_to_hva_many(struct kvm_memory_slot 
*slot, gfn_t gfn,
 gfn_t *nr_pages)
 {
if (!slot || slot->flags & KVM_MEMSLOT_INVALID)
-   return bad_hva();
+   return KVM_HVA_ERR_BAD;

if (nr_pages)
*nr_pages = slot->npages - (gfn - slot->base_gfn);
-- 
1.7.7.6

--
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 v6 10/12] KVM: introduce KVM_HVA_ERR_RO_BAD

[Xiao Guangrong]

In the later patch, it indicates failure when we try to get a writable
hva from the readonly memslot

Signed-off-by: Xiao Guangrong 
---
 include/linux/kvm_host.h |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index b9bba60..a913ac7 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -82,11 +82,12 @@ static inline bool is_invalid_pfn(pfn_t pfn)
return !is_noslot_pfn(pfn) && is_error_pfn(pfn);
 }

-#define KVM_HVA_ERR_BAD(PAGE_OFFSET)
+#define KVM_HVA_ERR_BAD(PAGE_OFFSET)
+#define KVM_HVA_ERR_RO_BAD (PAGE_OFFSET + PAGE_SIZE)

 static inline bool kvm_is_error_hva(unsigned long addr)
 {
-   return addr == PAGE_OFFSET;
+   return addr >= PAGE_OFFSET;
 }

 #define KVM_ERR_PTR_BAD_PAGE   (ERR_PTR(-ENOENT))
-- 
1.7.7.6

--
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 v6 08/12] KVM: introduce KVM_PFN_ERR_RO_FAULT

[Xiao Guangrong]

In the later patch, it indicates failure when we try to get a writable
pfn from the readonly memslot

Signed-off-by: Xiao Guangrong 
---
 include/linux/kvm_host.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 52c86e4..4fd33e0 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -65,6 +65,7 @@
 #define KVM_PFN_ERR_FAULT  (KVM_PFN_ERR_MASK)
 #define KVM_PFN_ERR_HWPOISON   (KVM_PFN_ERR_MASK + 1)
 #define KVM_PFN_ERR_BAD(KVM_PFN_ERR_MASK + 2)
+#define KVM_PFN_ERR_RO_FAULT   (KVM_PFN_ERR_MASK + 3)

 static inline bool is_error_pfn(pfn_t pfn)
 {
-- 
1.7.7.6

--
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 v6 07/12] KVM: use 'writable' as a hint to map writable pfn

[Xiao Guangrong]

In current code, we always map writable pfn for the read fault, in order
to support readonly memslot, we map writable pfn only if 'writable'
is not NULL

Signed-off-by: Xiao Guangrong 
---
 virt/kvm/kvm_main.c |   24 +++-
 1 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index aa4a38a..c89d1b5 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1054,6 +1054,14 @@ static bool hva_to_pfn_fast(unsigned long addr, bool 
atomic, bool *async,
if (!(async || atomic))
return false;

+   /*
+* Fast pin a writable pfn only if it is a write fault request
+* or the caller allows to map a writable pfn for a read fault
+* request.
+*/
+   if (!(write_fault || writable))
+   return false;
+
npages = __get_user_pages_fast(addr, 1, 1, page);
if (npages == 1) {
*pfn = page_to_pfn(page[0]);
@@ -1093,7 +1101,7 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
*async, bool write_fault,
return npages;

/* map read fault as writable if possible */
-   if (unlikely(!write_fault)) {
+   if (unlikely(!write_fault) && writable) {
struct page *wpage[1];

npages = __get_user_pages_fast(addr, 1, 1, wpage);
@@ -1109,6 +1117,20 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
*async, bool write_fault,
return npages;
 }

+/*
+ * Pin guest page in memory and return its pfn.
+ * @addr: host virtual address which maps memory to the guest
+ * @atomic: whether this function can sleep
+ * @async: whether this function need to wait IO complete if the
+ * host page is not in the memory
+ * @write_fault: whether we should get a writable host page
+ * @writable: whether it allows to map a writable host page for !@write_fault
+ *
+ * The function will map a writable host page for these two cases:
+ * 1): @write_fault = true
+ * 2): @write_fault = false && @writable, @writable will tell the caller
+ * whether the mapping is writable.
+ */
 static pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
bool write_fault, bool *writable)
 {
-- 
1.7.7.6

--
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 v6 06/12] KVM: reorganize hva_to_pfn

[Xiao Guangrong]

We do too many things in hva_to_pfn, this patch reorganize the code,
let it be better readable

Signed-off-by: Xiao Guangrong 
---
 virt/kvm/kvm_main.c |  159 +++
 1 files changed, 97 insertions(+), 62 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6e3ea15..aa4a38a 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1041,83 +1041,118 @@ static inline int check_user_page_hwpoison(unsigned 
long addr)
return rc == -EHWPOISON;
 }

-static pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
-   bool write_fault, bool *writable)
+/*
+ * The atomic path to get the writable pfn which will be stored in @pfn,
+ * true indicates success, otherwise false is returned.
+ */
+static bool hva_to_pfn_fast(unsigned long addr, bool atomic, bool *async,
+   bool write_fault, bool *writable, pfn_t *pfn)
 {
struct page *page[1];
-   int npages = 0;
-   pfn_t pfn;
+   int npages;

-   /* we can do it either atomically or asynchronously, not both */
-   BUG_ON(atomic && async);
+   if (!(async || atomic))
+   return false;

-   BUG_ON(!write_fault && !writable);
+   npages = __get_user_pages_fast(addr, 1, 1, page);
+   if (npages == 1) {
+   *pfn = page_to_pfn(page[0]);

-   if (writable)
-   *writable = true;
+   if (writable)
+   *writable = true;
+   return true;
+   }
+
+   return false;
+}

-   if (atomic || async)
-   npages = __get_user_pages_fast(addr, 1, 1, page);
+/*
+ * The slow path to get the pfn of the specified host virtual address,
+ * 1 indicates success, -errno is returned if error is detected.
+ */
+static int hva_to_pfn_slow(unsigned long addr, bool *async, bool write_fault,
+  bool *writable, pfn_t *pfn)
+{
+   struct page *page[1];
+   int npages = 0;

-   if (unlikely(npages != 1) && !atomic) {
-   might_sleep();
+   might_sleep();

-   if (writable)
-   *writable = write_fault;
-
-   if (async) {
-   down_read(>mm->mmap_sem);
-   npages = get_user_page_nowait(current, current->mm,
-addr, write_fault, page);
-   up_read(>mm->mmap_sem);
-   } else
-   npages = get_user_pages_fast(addr, 1, write_fault,
-page);
-
-   /* map read fault as writable if possible */
-   if (unlikely(!write_fault) && npages == 1) {
-   struct page *wpage[1];
-
-   npages = __get_user_pages_fast(addr, 1, 1, wpage);
-   if (npages == 1) {
-   *writable = true;
-   put_page(page[0]);
-   page[0] = wpage[0];
-   }
-   npages = 1;
+   if (writable)
+   *writable = write_fault;
+
+   if (async) {
+   down_read(>mm->mmap_sem);
+   npages = get_user_page_nowait(current, current->mm,
+ addr, write_fault, page);
+   up_read(>mm->mmap_sem);
+   } else
+   npages = get_user_pages_fast(addr, 1, write_fault,
+page);
+   if (npages != 1)
+   return npages;
+
+   /* map read fault as writable if possible */
+   if (unlikely(!write_fault)) {
+   struct page *wpage[1];
+
+   npages = __get_user_pages_fast(addr, 1, 1, wpage);
+   if (npages == 1) {
+   *writable = true;
+   put_page(page[0]);
+   page[0] = wpage[0];
}
+
+   npages = 1;
}
+   *pfn = page_to_pfn(page[0]);
+   return npages;
+}
+
+static pfn_t hva_to_pfn(unsigned long addr, bool atomic, bool *async,
+   bool write_fault, bool *writable)
+{
+   struct vm_area_struct *vma;
+   pfn_t pfn = 0;
+   int npages;

-   if (unlikely(npages != 1)) {
-   struct vm_area_struct *vma;
+   /* we can do it either atomically or asynchronously, not both */
+   BUG_ON(atomic && async);

-   if (atomic)
-   return KVM_PFN_ERR_FAULT;
+   BUG_ON(!write_fault && !writable);

-   down_read(>mm->mmap_sem);
-   if (npages == -EHWPOISON ||
-   (!async && check_user_page_hwpoison(addr))) {
-   up_read(>mm->mmap_sem);
-   return KVM_PFN_ERR_HWPOISON;
-   }
+   if (hva_to_pfn_fast(addr, atomic, async, write_fault, writable, 

[PATCH v6 05/12] KVM: introduce gfn_to_hva_read/kvm_read_hva/kvm_read_hva_atomic

[Xiao Guangrong]

This set of functions is only used to read data from host space, in the
later patch, we will only get a readonly hva in gfn_to_hva_read, and
the function name is a good hint to let gfn_to_hva_read to pair with
kvm_read_hva()/kvm_read_hva_atomic()

Signed-off-by: Xiao Guangrong 
---
 virt/kvm/kvm_main.c |   27 +++
 1 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 543f9b7..6e3ea15 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1002,6 +1002,25 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn)
 }
 EXPORT_SYMBOL_GPL(gfn_to_hva);

+/*
+ * The hva returned by this function is only allowed to be read.
+ * It should pair with kvm_read_hva() or kvm_read_hva_atomic().
+ */
+static unsigned long gfn_to_hva_read(struct kvm *kvm, gfn_t gfn)
+{
+   return gfn_to_hva_many(gfn_to_memslot(kvm, gfn), gfn, NULL);
+}
+
+static int kvm_read_hva(void *data, void __user *hva, int len)
+{
+   return __copy_from_user(data, hva, len);
+}
+
+static int kvm_read_hva_atomic(void *data, void __user *hva, int len)
+{
+   return __copy_from_user_inatomic(data, hva, len);
+}
+
 int get_user_page_nowait(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, int write, struct page **page)
 {
@@ -1274,10 +1293,10 @@ int kvm_read_guest_page(struct kvm *kvm, gfn_t gfn, 
void *data, int offset,
int r;
unsigned long addr;

-   addr = gfn_to_hva(kvm, gfn);
+   addr = gfn_to_hva_read(kvm, gfn);
if (kvm_is_error_hva(addr))
return -EFAULT;
-   r = __copy_from_user(data, (void __user *)addr + offset, len);
+   r = kvm_read_hva(data, (void __user *)addr + offset, len);
if (r)
return -EFAULT;
return 0;
@@ -1312,11 +1331,11 @@ int kvm_read_guest_atomic(struct kvm *kvm, gpa_t gpa, 
void *data,
gfn_t gfn = gpa >> PAGE_SHIFT;
int offset = offset_in_page(gpa);

-   addr = gfn_to_hva(kvm, gfn);
+   addr = gfn_to_hva_read(kvm, gfn);
if (kvm_is_error_hva(addr))
return -EFAULT;
pagefault_disable();
-   r = __copy_from_user_inatomic(data, (void __user *)addr + offset, len);
+   r = kvm_read_hva_atomic(data, (void __user *)addr + offset, len);
pagefault_enable();
if (r)
return -EFAULT;
-- 
1.7.7.6

--
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 v6 04/12] KVM: introduce gfn_to_pfn_memslot_atomic

[Xiao Guangrong]

It can instead of hva_to_pfn_atomic

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c   |5 +
 include/linux/kvm_host.h |3 ++-
 virt/kvm/kvm_main.c  |   14 --
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9651c2c..5548971 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2510,15 +2510,12 @@ static pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 bool no_dirty_log)
 {
struct kvm_memory_slot *slot;
-   unsigned long hva;

slot = gfn_to_memslot_dirty_bitmap(vcpu, gfn, no_dirty_log);
if (!slot)
return KVM_PFN_ERR_FAULT;

-   hva = gfn_to_hva_memslot(slot, gfn);
-
-   return hva_to_pfn_atomic(hva);
+   return gfn_to_pfn_memslot_atomic(slot, gfn);
 }

 static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d4bd4d4..52c86e4 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -462,7 +462,6 @@ void kvm_release_page_dirty(struct page *page);
 void kvm_set_page_dirty(struct page *page);
 void kvm_set_page_accessed(struct page *page);

-pfn_t hva_to_pfn_atomic(unsigned long addr);
 pfn_t gfn_to_pfn_atomic(struct kvm *kvm, gfn_t gfn);
 pfn_t gfn_to_pfn_async(struct kvm *kvm, gfn_t gfn, bool *async,
   bool write_fault, bool *writable);
@@ -470,6 +469,8 @@ pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn);
 pfn_t gfn_to_pfn_prot(struct kvm *kvm, gfn_t gfn, bool write_fault,
  bool *writable);
 pfn_t gfn_to_pfn_memslot(struct kvm_memory_slot *slot, gfn_t gfn);
+pfn_t gfn_to_pfn_memslot_atomic(struct kvm_memory_slot *slot, gfn_t gfn);
+
 void kvm_release_pfn_dirty(pfn_t pfn);
 void kvm_release_pfn_clean(pfn_t pfn);
 void kvm_set_pfn_dirty(pfn_t pfn);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7b94d70..543f9b7 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1102,12 +1102,6 @@ static pfn_t hva_to_pfn(unsigned long addr, bool atomic, 
bool *async,
return pfn;
 }

-pfn_t hva_to_pfn_atomic(unsigned long addr)
-{
-   return hva_to_pfn(addr, true, NULL, true, NULL);
-}
-EXPORT_SYMBOL_GPL(hva_to_pfn_atomic);
-
 static pfn_t __gfn_to_pfn(struct kvm *kvm, gfn_t gfn, bool atomic, bool *async,
  bool write_fault, bool *writable)
 {
@@ -1155,6 +1149,14 @@ pfn_t gfn_to_pfn_memslot(struct kvm_memory_slot *slot, 
gfn_t gfn)
return hva_to_pfn(addr, false, NULL, true, NULL);
 }

+pfn_t gfn_to_pfn_memslot_atomic(struct kvm_memory_slot *slot, gfn_t gfn)
+{
+   unsigned long addr = gfn_to_hva_memslot(slot, gfn);
+
+   return hva_to_pfn(addr, true, NULL, true, NULL);
+}
+EXPORT_SYMBOL_GPL(gfn_to_pfn_memslot_atomic);
+
 int gfn_to_page_many_atomic(struct kvm *kvm, gfn_t gfn, struct page **pages,
  int nr_pages)
 {
-- 
1.7.7.6

--
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 v6 03/12] KVM: hide KVM_MEMSLOT_INVALID from userspace

[Xiao Guangrong]

Quote Avi's comment:
| KVM_MEMSLOT_INVALID is actually an internal symbol, not used by
| userspace.  Please move it to kvm_host.h.

Also, we divide the memlsot->flags into two parts, the lower 16 bits
are visible for userspace, the higher 16 bits are internally used in
kvm

Signed-off-by: Xiao Guangrong 
---
 include/linux/kvm.h  |7 +--
 include/linux/kvm_host.h |7 +++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2ce09aa..2de335d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -101,9 +101,12 @@ struct kvm_userspace_memory_region {
__u64 userspace_addr; /* start of the userspace allocated memory */
 };

-/* for kvm_memory_region::flags */
+/*
+ * The bit 0 ~ bit 15 of kvm_memory_region::flags are visible for userspace,
+ * other bits are reserved for kvm internal use which are defined in
+ * include/linux/kvm_host.h.
+ */
 #define KVM_MEM_LOG_DIRTY_PAGES  1UL
-#define KVM_MEMSLOT_INVALID  (1UL << 1)

 /* for KVM_IRQ_LINE */
 struct kvm_irq_level {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d2b897e..d4bd4d4 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -36,6 +36,13 @@
 #endif

 /*
+ * The bit 16 ~ bit 31 of kvm_memory_region::flags are internally used
+ * in kvm, other bits are visible for userspace which are defined in
+ * include/linux/kvm_h.
+ */
+#define KVM_MEMSLOT_INVALID(1UL << 16)
+
+/*
  * If we support unaligned MMIO, at most one fragment will be split into two:
  */
 #ifdef KVM_UNALIGNED_MMIO
-- 
1.7.7.6

--
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 v6 02/12] KVM: fix missing check for memslot flags

[Xiao Guangrong]

Check flags when memslot is registered from userspace as Avi's suggestion

Signed-off-by: Xiao Guangrong 
---
 virt/kvm/kvm_main.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a2e85af..7b94d70 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -678,6 +678,14 @@ void update_memslots(struct kvm_memslots *slots, struct 
kvm_memory_slot *new)
slots->generation++;
 }

+static int check_memory_region_flags(struct kvm_userspace_memory_region *mem)
+{
+   if (mem->flags & ~KVM_MEM_LOG_DIRTY_PAGES)
+   return -EINVAL;
+
+   return 0;
+}
+
 /*
  * Allocate some memory and give it an address in the guest physical address
  * space.
@@ -698,6 +706,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
struct kvm_memory_slot old, new;
struct kvm_memslots *slots, *old_memslots;

+   r = check_memory_region_flags(mem);
+   if (r)
+   goto out;
+
r = -EINVAL;
/* General sanity checks */
if (mem->memory_size & (PAGE_SIZE - 1))
-- 
1.7.7.6

--
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 v6 01/12] KVM: x86: fix possible infinite loop caused by reexecute_instruction

[Xiao Guangrong]

Currently, we reexecute all unhandleable instructions if they do not
access on the mmio, however, it can not work if host map the readonly
memory to guest. If the instruction try to write this kind of memory,
it will fault again when guest retry it, then we will goto a infinite
loop: retry instruction -> write #PF -> emulation fail ->
retry instruction -> ...

Fix it by retrying the instruction only when it faults on the writable
memory

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/x86.c |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fb0d937..704680d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4473,6 +4473,7 @@ static int handle_emulation_failure(struct kvm_vcpu *vcpu)
 static bool reexecute_instruction(struct kvm_vcpu *vcpu, gva_t gva)
 {
gpa_t gpa;
+   pfn_t pfn;

if (tdp_enabled)
return false;
@@ -4490,8 +4491,17 @@ static bool reexecute_instruction(struct kvm_vcpu *vcpu, 
gva_t gva)
if (gpa == UNMAPPED_GVA)
return true; /* let cpu generate fault */

-   if (!kvm_is_error_hva(gfn_to_hva(vcpu->kvm, gpa >> PAGE_SHIFT)))
+   /*
+* Do not retry the unhandleable instruction if it faults on the
+* readonly host memory, otherwise it will goto a infinite loop:
+* retry instruction -> write #PF -> emulation fail -> retry
+* instruction -> ...
+*/
+   pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
+   if (!is_error_pfn(pfn)) {
+   kvm_release_pfn_clean(pfn);
return true;
+   }

return false;
 }
-- 
1.7.7.6

--
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 v6 00/12] KVM: introduce readonly memslot

[Xiao Guangrong]

Changelog:
- fix endless retrying for unhandleable instruction which accesses on readonly
  host memory
- divide slot->flags by 16:16, the lower part is visible for userspace, the
  reset is internally used in kvm, and document this in the code
- check slot->flags for gfn_to_hva_memslot

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.

--
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] serial: add a new helper function

[Huang Shijie]

On Sun, Aug 19, 2012 at 11:46 PM, Alan Cox  wrote:
> On Sat, 18 Aug 2012 23:44:29 -0700
> Greg KH  wrote:
>
>> On Sun, Aug 19, 2012 at 02:27:12PM -0400, Huang Shijie wrote:
>> > --- a/include/linux/tty.h
>> > +++ b/include/linux/tty.h
>> > @@ -43,6 +43,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >
>> >
>> > @@ -513,6 +514,12 @@ static inline struct tty_port *tty_port_get(struct 
>> > tty_port *port)
>> > return port;
>> >  }
>> >
>> > +/* If the cts flow control is enabled, return true. */
>> > +static inline bool tty_port_cts_enabled(struct tty_port *port)
>> > +{
>> > +   return port->flags & ASYNC_CTS_FLOW;
>> > +}
>> > +
>>
>> The fact that you have to add serial.h to this file kind of implies that
>> this function shouldn't be here, right?
>>
>> How about serial.h instead?  Not all tty drivers are serial drivers :)
>
> tty_port is tty generic so possibly if there is a generic helper the
> flags and helper should likewise be this way.
>
> As it stands at the moment ASYNC_CTS_FLOW is a convention a few drivers
> use. So calling it tty_port_xxx is going to misleading.

this patch makes the header files in a mess.
Please just ignore this patch if it is not good enough.

thanks
Huang Shijie

>



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

linux-next: manual merge of the rr tree with Linus' tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/alpha/Kconfig between commit f2db633d301b ("alpha: Use new generic
strncpy_from_user() and strnlen_user()") from Linus' tree and commit
d673c23ca730 ("Make most arch asm/module.h files use
asm-generic/module.h") from the rr tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/alpha/Kconfig
index 9944ded,e73a1a7..000
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@@ -18,8 -18,8 +18,10 @@@ config ALPH
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_SMP_IDLE_THREAD
select GENERIC_CMOS_UPDATE
 +  select GENERIC_STRNCPY_FROM_USER
 +  select GENERIC_STRNLEN_USER
+   select HAVE_MOD_ARCH_SPECIFIC
+   select MODULES_USE_ELF_RELA
help
  The Alpha is a 64-bit general-purpose processor designed and
  marketed by the Digital Equipment Corporation of blessed memory,


pgpIPbWC7tH3m.pgp
Description: PGP signature

Re: [GIT PULL 1/2] Btrfs fixes

[Chris Samuel]

On 10/08/12 01:50, Chris Mason wrote:

> Hi everyone,
> 
> This first pull is the bulk of our changes for the next rc.  It is
> against the 3.5 kernel so people testing the new features have a stable
> point to work against.  This was tested against Linus' current tree as
> well.
[...]

This pull request with a whole heap of btrfs fixes (46 commits) appears
not to have been merged yet, does anyone know if it was rejected or just
missed ?

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC
--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[Fengguang Wu]

On Mon, Aug 20, 2012 at 06:46:05PM -0700, John Stultz wrote:
> On 08/20/2012 06:31 PM, Fengguang Wu wrote:
> >On Mon, Aug 20, 2012 at 06:10:57PM -0700, John Stultz wrote:
> >>On 08/20/2012 06:04 PM, Fengguang Wu wrote:
> >>>Hi John,
> >>>
> >>>The below oops happens in v3.5..v3.6-rc2 and it's bisected down to commit
> >>>2a8c0883c ("time: Move xtime_nsec adjustment underflow handling 
> >>>timekeeping_adjust").
> >>>
> >>>However linux-next is working fine. Do you have any fixes not yet sent to 
> >>>Linus?
> >>Yea, there's a fix pending in tip/timers/urgent
> >>(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values
> >>from settimeofday or the cmos clock that might overflow a ktime_t.
> >That's great!
> >
> >>Out of curiosity, how are you triggering/reproducing this?
> >I boot test lots of randconfig kernels in kvm, and this oops shows up
> >several times in one ranconfig and some of the test boxes. I find it
> >pretty hard to reproduce, but managed to bisect it down by counting
> >1000 good boots as bisect success and running dozens of KVM instances
> >in parallel in several test boxes to speed up the progress. Here is one step:
> 
> Oof.  That's an really impressive setup!

Thank you :)
 
> That said, if this happens only at boot up, and you don't have
> systems with crazy cmos values, I'm not sure I see how commit
> 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b might fix this.  So that's
> not very reassuring.

Sorry if my words mislead you, but the bug happens after booting the
user space. Look at the following dmesg mixed with userspace logs.
I noticed this when doing the bisects: the [5.310905] suddenly
jumped to [ 2204.090146] in very short wall time.

[5.303661] device: 'input2': device_add
[5.304677] PM: Adding info for No Bus:input2
[5.305666] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input2
[5.307546] device: 'mouse0': device_add
[5.308452] PM: Adding info for No Bus:mouse0
[5.309505] driver: 'serio1': driver_bound: bound to device 'psmouse'
[5.310905] bus: 'serio': really_probe: bound device serio1 to 
driver psmouse
modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

[ 2204.090146] plymouthd (52) used greatest stack depth: 6324 bytes left
modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

 * Asking all remaining processes to terminate...

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

modprobe: FATAL: Could not load /lib/modules/3.6.0-rc1/modules.dep: No 
such file or directory

 * Killing all remaining processes...

mount: unknown filesystem type 'devpts'
mountall: mount /dev/pts [1267] terminated with status 32
mountall: Filesystem could not be mounted: /dev/pts
mountall: Skipping mounting /dev/pts since Plymouth is not available

udevd[1346]: error creating signalfd

udevd[1360]: error creating signalfd

 * Deactivating swap...
[ 2220.929173] ip (1388) used greatest stack depth: 6132 bytes left
udevd[1381]: error creating signalfd

udevd[1397]: error creating signalfd

[ 2221.089504] VFS: Busy inodes after unmount of tmpfs. Self-destruct 
in 5 seconds.  Have a nice day...
[ 2221.091656] BUG: unable to handle kernel NULL pointer dereference at 
000c   
[ 2221.093256] IP: [<810d2a2c>] shmem_free_inode+0x10/0x45
[ 2221.093927] *pde = 

> As a tangent, I think this sort of big-data style testing is a
> really great contribution, so thank you for setting up and doing all
> this work.

I'm glad you love it. Thanks!

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

Re: [GIT PULL 1/2] Btrfs fixes

[Linus Torvalds]

On Mon, Aug 20, 2012 at 6:53 PM, Chris Samuel  wrote:
>
> This pull request with a whole heap of btrfs fixes (46 commits) appears
> not to have been merged yet, does anyone know if it was rejected or just
> missed ?

Read my -rc2 release notes.

TL;DR: I rejected big pull requests that didn't convince me. Make a
damn good case for it, or send minimal fixes instead.

I'm tried of these "oops, what we sent you for -rc1 wasn't ready, so
here's a thousand lines of changes" crap.

 Linus
--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[John Stultz]

On 08/20/2012 06:40 PM, Fengguang Wu wrote:

On Mon, Aug 20, 2012 at 06:15:00PM -0700, John Stultz wrote:

On 08/20/2012 06:10 PM, John Stultz wrote:

On 08/20/2012 06:04 PM, Fengguang Wu wrote:

Hi John,

The below oops happens in v3.5..v3.6-rc2 and it's bisected down
to commit
2a8c0883c ("time: Move xtime_nsec adjustment underflow handling
timekeeping_adjust").

However linux-next is working fine. Do you have any fixes not
yet sent to Linus?

Yea, there's a fix pending in tip/timers/urgent
(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values

>from settimeofday or the cmos clock that might overflow a ktime_t.

Out of curiosity, how are you triggering/reproducing this?


Looking at the commit you pointed out, it seems more likely Ingo's
fix (1d17d17484d40f2d5b35c79518597a2b25296996) might be related, but
that should have landed in v3.6-rc2.  So I'm not sure.

Ah ok, looking back into the logs, I didn't find v3.6-rc2 being
tested. Sorry I should have confused it with another bug.

I'll test v3.6-rc2.
Ok. If v3.6-rc2 doesn't show the problem that would make me feel a bit 
better that Ingo's fix is the one that is resolving this for you.


thanks again!
-john




--
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] pstore/ftrace: Convert to its own enable/disable debugfs knob

[Anton Vorontsov]

On Wed, Jul 18, 2012 at 12:30:52PM -0700, Anton Vorontsov wrote:
> With this patch we no longer reuse function tracer infrastructure, now
> we register our own tracer back-end via a debugfs knob.
> 
> It's a bit more code, but that is the only downside. On the bright side we
> have:
> 
> - Ability to make persistent_ram module removable (when needed, we can
>   move ftrace_ops struct into a module). Note that persistent_ram is still
>   not removable for other reasons, but with this patch it's just one
>   thing less to worry about;
> 
> - Pstore part is more isolated from the generic function tracer. We tried
>   it already by registering our own tracer in available_tracers, but that
>   way we're loosing ability to see the traces while we record them to
>   pstore. This solution is somewhere in the middle: we only register
>   "internal ftracer" back-end, but not the "front-end";
> 
> - When there is only pstore tracing enabled, the kernel will only write
>   to the pstore buffer, omitting function tracer buffer (which, of course,
>   still can be enabled via 'echo function > current_tracer').
> 
> Suggested-by: Steven Rostedt 
> Signed-off-by: Anton Vorontsov 
> ---

Hi Steven,

Unless there are any issues, may I take the patch via linux-pstore.git
tree?

Thanks!

>  Documentation/ramoops.txt  |4 +-
>  fs/pstore/Kconfig  |1 +
>  fs/pstore/ftrace.c |   96 
> +++-
>  fs/pstore/internal.h   |6 +++
>  fs/pstore/platform.c   |1 +
>  include/linux/pstore.h |8 
>  kernel/trace/trace_functions.c |   15 +--
>  7 files changed, 105 insertions(+), 26 deletions(-)
> 
> diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
> index 197ad59..69b3cac 100644
> --- a/Documentation/ramoops.txt
> +++ b/Documentation/ramoops.txt
> @@ -102,9 +102,7 @@ related hangs. The functions call chain log is stored in 
> a "ftrace-ramoops"
>  file. Here is an example of usage:
>  
>   # mount -t debugfs debugfs /sys/kernel/debug/
> - # cd /sys/kernel/debug/tracing
> - # echo function > current_tracer
> - # echo 1 > options/func_pstore
> + # echo 1 > /sys/kernel/debug/pstore/record_ftrace
>   # reboot -f
>   [...]
>   # mount -t pstore pstore /mnt/
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index d39bb5c..ca71db6 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -23,6 +23,7 @@ config PSTORE_FTRACE
>   bool "Persistent function tracer"
>   depends on PSTORE
>   depends on FUNCTION_TRACER
> + depends on DEBUG_FS
>   help
> With this option kernel traces function calls into a persistent
> ram buffer that can be decoded and dumped after reboot through
> diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
> index a130d48..2d57e1a 100644
> --- a/fs/pstore/ftrace.c
> +++ b/fs/pstore/ftrace.c
> @@ -17,19 +17,113 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include "internal.h"
>  
> -void notrace pstore_ftrace_call(unsigned long ip, unsigned long parent_ip)
> +static void notrace pstore_ftrace_call(unsigned long ip,
> +unsigned long parent_ip)
>  {
> + unsigned long flags;
>   struct pstore_ftrace_record rec = {};
>  
>   if (unlikely(oops_in_progress))
>   return;
>  
> + local_irq_save(flags);
> +
>   rec.ip = ip;
>   rec.parent_ip = parent_ip;
>   pstore_ftrace_encode_cpu(, raw_smp_processor_id());
>   psinfo->write_buf(PSTORE_TYPE_FTRACE, 0, NULL, 0, (void *),
> sizeof(rec), psinfo);
> +
> + local_irq_restore(flags);
> +}
> +
> +static struct ftrace_ops pstore_ftrace_ops __read_mostly = {
> + .func   = pstore_ftrace_call,
> +};
> +
> +static DEFINE_MUTEX(pstore_ftrace_lock);
> +static bool pstore_ftrace_enabled;
> +
> +static ssize_t pstore_ftrace_knob_write(struct file *f, const char __user 
> *buf,
> + size_t count, loff_t *ppos)
> +{
> + u8 on;
> + ssize_t ret;
> +
> + ret = kstrtou8_from_user(buf, count, 2, );
> + if (ret)
> + return ret;
> +
> + mutex_lock(_ftrace_lock);
> +
> + if (!on ^ pstore_ftrace_enabled)
> + goto out;
> +
> + if (on)
> + ret = register_ftrace_function(_ftrace_ops);
> + else
> + ret = unregister_ftrace_function(_ftrace_ops);
> + if (ret) {
> + pr_err("%s: unable to %sregister ftrace ops: %zd\n",
> +__func__, on ? "" : "un", ret);
> + goto err;
> + }
> +
> + pstore_ftrace_enabled = on;
> +out:
> + ret = count;
> +err:
> + mutex_unlock(_ftrace_lock);
> +
> + return ret;
> +}
> +
> +static ssize_t pstore_ftrace_knob_read(struct file *f, char __user *buf,
> +size_t count, loff_t *ppos)
> +{
> + 

[PATCH] [trivial] Fix typo "endianess" in printk

[Masanari Iida]

Correct spelling typo "endianess" in various printk

Signed-off-by: Masanari Iida 
---
 drivers/firewire/ohci.c| 2 +-
 drivers/remoteproc/remoteproc_elf_loader.c | 4 ++--
 fs/qnx6/inode.c| 2 +-
 fs/qnx6/qnx6.h | 2 +-
 scripts/basic/fixdep.c | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index c788dbd..86d3d10 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -329,7 +329,7 @@ module_param_named(quirks, param_quirks, int, 0644);
 MODULE_PARM_DESC(quirks, "Chip quirks (default = 0"
", nonatomic cycle timer = "__stringify(QUIRK_CYCLE_TIMER)
", reset packet generation = "  __stringify(QUIRK_RESET_PACKET)
-   ", AR/selfID endianess = "  __stringify(QUIRK_BE_HEADERS)
+   ", AR/selfID endianness = " __stringify(QUIRK_BE_HEADERS)
", no 1394a enhancements = "__stringify(QUIRK_NO_1394A)
", disable MSI = "  __stringify(QUIRK_NO_MSI)
", TI SLLZ059 erratum = "   __stringify(QUIRK_TI_SLLZ059)
diff --git a/drivers/remoteproc/remoteproc_elf_loader.c 
b/drivers/remoteproc/remoteproc_elf_loader.c
index e1f89d6..0d36f94 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -66,13 +66,13 @@ rproc_elf_sanity_check(struct rproc *rproc, const struct 
firmware *fw)
return -EINVAL;
}
 
-   /* We assume the firmware has the same endianess as the host */
+   /* We assume the firmware has the same endianness as the host */
 # ifdef __LITTLE_ENDIAN
if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
 # else /* BIG ENDIAN */
if (ehdr->e_ident[EI_DATA] != ELFDATA2MSB) {
 # endif
-   dev_err(dev, "Unsupported firmware endianess\n");
+   dev_err(dev, "Unsupported firmware endianness\n");
return -EINVAL;
}
 
diff --git a/fs/qnx6/inode.c b/fs/qnx6/inode.c
index 1b37fff..9bdfd71 100644
--- a/fs/qnx6/inode.c
+++ b/fs/qnx6/inode.c
@@ -285,7 +285,7 @@ static struct buffer_head 
*qnx6_check_first_superblock(struct super_block *s,
if (fs32_to_cpu(sbi, sb->sb_magic) == QNX6_SUPER_MAGIC) {
/* we got a big endian fs */
QNX6DEBUG((KERN_INFO "qnx6: fs got different"
-   " endianess.\n"));
+   " endianness.\n"));
return bh;
} else
sbi->s_bytesex = BYTESEX_LE;
diff --git a/fs/qnx6/qnx6.h b/fs/qnx6/qnx6.h
index b00fcc9..81b7224 100644
--- a/fs/qnx6/qnx6.h
+++ b/fs/qnx6/qnx6.h
@@ -31,7 +31,7 @@ struct qnx6_sb_info {
int s_blks_off; /* blkoffset fs-startpoint */
int s_ptrbits;  /* indirect pointer bitfield */
unsigned long   s_mount_opt;/* all mount options */
-   int s_bytesex;  /* holds endianess info */
+   int s_bytesex;  /* holds endianness info */
struct inode *  inodes;
struct inode *  longfile;
 };
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index cb1f50c..7f6425e 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -409,7 +409,7 @@ static void traps(void)
int *p = (int *)test;
 
if (*p != INT_CONF) {
-   fprintf(stderr, "fixdep: sizeof(int) != 4 or wrong endianess? 
%#x\n",
+   fprintf(stderr, "fixdep: sizeof(int) != 4 or wrong endianness? 
%#x\n",
*p);
exit(2);
}
-- 
1.7.12.rc3.4.g91e4bfe

--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[John Stultz]

On 08/20/2012 06:31 PM, Fengguang Wu wrote:

On Mon, Aug 20, 2012 at 06:10:57PM -0700, John Stultz wrote:

On 08/20/2012 06:04 PM, Fengguang Wu wrote:

Hi John,

The below oops happens in v3.5..v3.6-rc2 and it's bisected down to commit
2a8c0883c ("time: Move xtime_nsec adjustment underflow handling 
timekeeping_adjust").

However linux-next is working fine. Do you have any fixes not yet sent to Linus?

Yea, there's a fix pending in tip/timers/urgent
(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values
from settimeofday or the cmos clock that might overflow a ktime_t.

That's great!


Out of curiosity, how are you triggering/reproducing this?

I boot test lots of randconfig kernels in kvm, and this oops shows up
several times in one ranconfig and some of the test boxes. I find it
pretty hard to reproduce, but managed to bisect it down by counting
1000 good boots as bisect success and running dozens of KVM instances
in parallel in several test boxes to speed up the progress. Here is one step:


Oof.  That's an really impressive setup!

That said, if this happens only at boot up, and you don't have systems 
with crazy cmos values, I'm not sure I see how commit 
4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b might fix this.  So that's not 
very reassuring.


As a tangent, I think this sort of big-data style testing is a really 
great contribution, so thank you for setting up and doing all this work.

-john

--
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] pstore: add missed platform_device_unregister

[Anton Vorontsov]

On Mon, Aug 20, 2012 at 02:58:26PM +0800, Jovi Zhang wrote:
> From 152373a6262045d19023cf45de84ad3c69316a45 Mon Sep 17 00:00:00 2001
> From: Jovi Zhang 
> Date: Mon, 20 Aug 2012 14:20:01 +0800
> Subject: [PATCH] pstore: add missed platform_device_unregister
> 
> we need unregister platform device when module exit, add it.
> 
> Signed-off-by: Jovi Zhang 
> ---
>  fs/pstore/ram.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 0b311bc..adb218a 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -537,6 +537,7 @@ postcore_initcall(ramoops_init);
>  static void __exit ramoops_exit(void)
>  {
>   platform_driver_unregister(_driver);
> + platform_device_unregister(dummy);
>   kfree(dummy_data);
>  }
>  module_exit(ramoops_exit);

It looks OK to me. Unless there are objections I'll apply it to
linux-pstore.git.

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

Re: BUG: NULL pointer dereference in shmem_evict_inode()

[Fengguang Wu]

On Mon, Aug 20, 2012 at 06:15:00PM -0700, John Stultz wrote:
> On 08/20/2012 06:10 PM, John Stultz wrote:
> >On 08/20/2012 06:04 PM, Fengguang Wu wrote:
> >>Hi John,
> >>
> >>The below oops happens in v3.5..v3.6-rc2 and it's bisected down
> >>to commit
> >>2a8c0883c ("time: Move xtime_nsec adjustment underflow handling
> >>timekeeping_adjust").
> >>
> >>However linux-next is working fine. Do you have any fixes not
> >>yet sent to Linus?
> >Yea, there's a fix pending in tip/timers/urgent
> >(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values
> >from settimeofday or the cmos clock that might overflow a ktime_t.
> >
> >Out of curiosity, how are you triggering/reproducing this?
> >
> 
> Looking at the commit you pointed out, it seems more likely Ingo's
> fix (1d17d17484d40f2d5b35c79518597a2b25296996) might be related, but
> that should have landed in v3.6-rc2.  So I'm not sure.

Ah ok, looking back into the logs, I didn't find v3.6-rc2 being
tested. Sorry I should have confused it with another bug.

I'll test v3.6-rc2.

Thanks,
Fengguang
--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[Fengguang Wu]

On Mon, Aug 20, 2012 at 06:10:57PM -0700, John Stultz wrote:
> On 08/20/2012 06:04 PM, Fengguang Wu wrote:
> >Hi John,
> >
> >The below oops happens in v3.5..v3.6-rc2 and it's bisected down to commit
> >2a8c0883c ("time: Move xtime_nsec adjustment underflow handling 
> >timekeeping_adjust").
> >
> >However linux-next is working fine. Do you have any fixes not yet sent to 
> >Linus?
> Yea, there's a fix pending in tip/timers/urgent
> (4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values
> from settimeofday or the cmos clock that might overflow a ktime_t.

That's great!

> Out of curiosity, how are you triggering/reproducing this?

I boot test lots of randconfig kernels in kvm, and this oops shows up
several times in one ranconfig and some of the test boxes. I find it
pretty hard to reproduce, but managed to bisect it down by counting
1000 good boots as bisect success and running dozens of KVM instances
in parallel in several test boxes to speed up the progress. Here is one step:

2012-08-20-02:51:57 detecting boot state #9 12345...OK 6...OK 7.OK 8OK .OK 
9OK 10OK 11OK 12OK 13.OK .OK 1415..OK 16OK 1718OK 19...OK .20.OK 21OK 
22...OK 23OK 24OK .25..OK 26..OK 27OK 28OK 29.OK 30..OK 31..OK 32OK 
33OK 34.OK 35.OK 36OK 37..OK .OK 38OK 39...OK .40OK 41.OK .OK 42..OK 43OK 
44OK 45..OK 46.OK 47OK 48..OK 49..OK 50.OK 5152.OK 53.OK 54OK 55..OK 56..OK 
57.OK 58OK 59...OK 60OK .OK 61.OK 62OK 63.OK 64OK .OK 65.OK .66OK .67.OK 68.OK 
69OK 70.OK 71OK 72OK 73...OK 74..OK 75.OK 76OK 77OK 78OK 79OK 80.OK 81..OK 
82...OK .OK 83.OK 8485OK 86.OK 87.OK .88OK 89OK 90OK 91OK 92OK 93.OK 94.OK 
95.OK 96...OK .97.OK 98OK 99.OK .100OK .101OK 102OK 103.OK 104OK 105OK 
106OK 107.OK 108..OK 109.OK .OK 110OK 111...OK 112.OK 113.OK 114.OK 115116.OK 
117OK 118OK 119120.OK .121..OK 122..OK 123.OK 124OK 125OK 126OK 127..OK 128.OK 
129.OK 130.OK 131OK .OK 132OK 133134OK 135..OK 136.OK 137...OK 138.OK 139OK 
140OK 141.OK 142.OK 143.OK 144.OK 145OK 146OK 147.OK 148OK 149150.OK 
151..OK 152OK 153.OK 154OK .OK 155156.OK 157.OK 158OK 159.OK 160OK 161.OK 
162.OK 163...OK 164OK .OK 165166OK 167OK 168OK 169..OK 170...OK 171.OK 
172OK 173.OK 174OK 175OK 176...OK 177..OK 178179OK 180OK 181OK 182OK 183.OK 
184185..OK 186...OK 187OK 188OK .OK 189OK .190OK 191192..OK 193OK 194OK 
195OK .196OK 197OK 198OK 199..OK 200...OK 201OK 202OK 203204OK 205206OK 
207...OK 208...OK 209OK 210OK 211.OK 212OK .213...OK 214..OK .OK 215OK 216OK 
217.OK 218OK 219OK 220OK 221OK 222OK .OK 223OK 224OK 225OK 
226.OK 227OK 228OK 229..OK 230.OK 231OK 232.OK 233OK 234OK 235.OK 236OK 
237..OK 238.OK 239OK 240OK 241.OK 242OK 243OK .244.OK 245..OK 246OK 247OK 248OK 
249.OK 250.OK 251.OK 252..OK 253..OK 254OK 255OK 256.OK 257OK 258.OK 
259..OK 260OK 261OK 262.OK 263OK 264..OK 265.OK 266OK 267268OK 269.OK 
270..OK 271.OK 272OK 273.OK 274OK 275OK 276..OK 277OK .OK 278OK 279.OK 
280OK 281OK 282..OK 283OK 284OK 285286OK 287.OK 288OK 289.OK 290.OK 291OK 
292.OK 293OK 294OK 295.OK 296OK .297.OK 298..OK 299..OK 300OK 301OK 302.OK 
303OK 304..OK 305..O
K 306..OK 307OK 308OK 309OK .OK 310OK 311..OK 312..OK .313.OK 314OK 315.OK 
316OK 317OK 318..OK 319...OK 320.OK 321OK 322.OK 323OK 324OK 325..OK 326...OK 
327OK 328OK 329OK 330OK .331OK 332OK 333..OK 334...OK 335OK 336OK 337338OK 
339.OK 340.OK 341.OK 342OK 343OK 344.OK 345OK 346..OK 347.OK 348...OK .OK 
349OK 350.OK 351OK 352..OK 353.OK .354OK .355OK 356OK 357358OK 359OK 360OK 
361.OK 362.OK 363OK 364OK 365.OK 366OK 367OK 368...OK 369OK 370OK 
371.OK 372OK 373OK 374...OK 375OK 376377OK 378.OK 379OK 380...OK 381OK 
382.OK 383OK .OK 384.OK 385.OK .OK 386OK 387.OK 388OK 389OK .390OK 391.OK 
392...OK 393OK 394OK 395OK .396OK 397..OK 398.OK 399...OK 400OK 401OK .OK 
402.OK 403..OK .404OK 405...OK 406OK 407.OK 408OK 409OK 410...OK 411OK 
412OK 413OK .OK 414OK 415OK 416...OK 417OK 418419OK 420OK .OK 421422.OK 
423.OK 424...OK 425OK 426.OK 427OK 428OK 429OK 430.OK 431.OK 432..OK 433OK 
434OK 435OK .436OK 437OK .438.OK 439OK 440OK 441442OK 443.OK 444.OK 445.OK 
.446..OK 447OK 448OK 449.OK 450 TEST FAILURE
Bisecting: 2627 revisions left to test after this (roughly 11 steps)

Before this, I bisected another soft lockup bug to the same commit
2a8c0883c, however it seems to be fixed by another commit in Linus'
tree, so I didn't report it. But here are the call traces as FYI:

[ 2215.030127] [sched_delayed] sched: RT throttling activated
[ 2215.026783] BUG: soft lockup - CPU#1 stuck for 2047s! [99-trinity:504]
[ 2215.026783] Modules linked in:
[ 2215.026783] Pid: 504, comm: 99-trinity Not tainted 3.6.0-rc1 #225 Bochs Bochs
[ 2215.026783] EIP: 0060:[] EFLAGS: 0206 CPU: 1
[ 2215.026783] EIP is at __might_sleep+0x4b/0x14a
[ 2215.026783] EAX: c13ad954 EBX: c7121600 ECX:  EDX: 
[ 2215.026783] ESI: c1319bb0 EDI: 00aa EBP: c7111e94 ESP: c7111e84
[ 2215.026783]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 

[PATCH 5/5] X86/XEN: Add few lines explaining simple semantic for x86_init.paging.pagetable_init PVOPS

[Attilio Rao]

- Explain the purpose of the PVOPS
- Report execution constraints

Signed-off-by: Attilio Rao 
---
 arch/x86/include/asm/x86_init.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 995ea5c..7ea4186 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -82,6 +82,11 @@ struct x86_init_mapping {
 /**
  * struct x86_init_paging - platform specific paging functions
  * @pagetable_init:platform specific paging initialization call
+ *
+ * It does setup the kernel pagetables and prepares accessors functions to
+ * manipulate them.
+ * It must be called once, during the boot sequence and after the direct
+ * mapping for phys memory is setup.
  */
 struct x86_init_paging {
void (*pagetable_init)(void);
-- 
1.7.2.5

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

[PATCH 4/5] X86/XEN: Retire now unused x86_init.paging.pagetable_setup_start and x86_init.paging.pagetable_setup_done PVOPS

[Attilio Rao]

Now that x86_init.paging.pagetable_init PVOPS is implemented just
retire the 2 mentioned above and replace their usage with it.

Signed-off-by: Attilio Rao 
---
 arch/x86/include/asm/pgtable_types.h |4 ---
 arch/x86/include/asm/x86_init.h  |4 ---
 arch/x86/kernel/setup.c  |4 +--
 arch/x86/kernel/x86_init.c   |3 --
 arch/x86/mm/init_32.c|   40 +-
 arch/x86/xen/mmu.c   |   12 --
 6 files changed, 2 insertions(+), 65 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 55f24b5..db8fec6 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -304,12 +304,8 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
 extern void native_pagetable_init(void);
-extern void native_pagetable_setup_start(void);
-extern void native_pagetable_setup_done(void);
 #else
 #define native_pagetable_initpaging_init
-#define native_pagetable_setup_start x86_init_pgd_noop
-#define native_pagetable_setup_done  x86_init_pgd_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index a74cc19..995ea5c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -82,13 +82,9 @@ struct x86_init_mapping {
 /**
  * struct x86_init_paging - platform specific paging functions
  * @pagetable_init:platform specific paging initialization call
- * @pagetable_setup_start: platform specific pre paging_init() call
- * @pagetable_setup_done:  platform specific post paging_init() call
  */
 struct x86_init_paging {
void (*pagetable_init)(void);
-   void (*pagetable_setup_start)(void);
-   void (*pagetable_setup_done)(void);
 };
 
 /**
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3d8f00..4f16547 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,9 +961,7 @@ void __init setup_arch(char **cmdline_p)
kvmclock_init();
 #endif
 
-   x86_init.paging.pagetable_setup_start();
-   paging_init();
-   x86_init.paging.pagetable_setup_done();
+   x86_init.paging.pagetable_init();
 
if (boot_cpu_data.cpuid_level >= 0) {
/* A CPU has %cr4 if and only if it has CPUID */
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index c1e910a..7a3d075 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,6 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_noop(void) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
@@ -69,8 +68,6 @@ struct x86_init_ops x86_init __initdata = {
 
.paging = {
.pagetable_init = native_pagetable_init,
-   .pagetable_setup_start  = native_pagetable_setup_start,
-   .pagetable_setup_done   = native_pagetable_setup_done,
},
 
.timers = {
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 2ff4790..f8771ad 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -480,44 +480,6 @@ void __init native_pagetable_init(void)
paravirt_alloc_pmd(_mm, __pa(base) >> PAGE_SHIFT);
paging_init();
 }
-void __init native_pagetable_setup_start(void)
-{
-   unsigned long pfn, va;
-   pgd_t *base;
-   pgd_t *pgd;
-   pud_t *pud;
-   pmd_t *pmd;
-   pte_t *pte;
-
-   base = swapper_pg_dir;
-
-   /*
-* Remove any mappings which extend past the end of physical
-* memory from the boot time page table:
-*/
-   for (pfn = max_low_pfn + 1; pfn < 1<<(32-PAGE_SHIFT); pfn++) {
-   va = PAGE_OFFSET + (pfn<> PAGE_SHIFT);
-}
-
-void __init native_pagetable_setup_done(void)
-{
-}
 
 /*
  * Build a proper pagetable for the kernel mappings.  Up until this
@@ -531,7 +493,7 @@ void __init native_pagetable_setup_done(void)
  * If we're booting paravirtualized under a hypervisor, then there are
  * more options: we may already be running PAE, and the pagetable may
  * or may not be based in swapper_pg_dir.  In any case,
- * paravirt_pagetable_setup_start() will set up swapper_pg_dir
+ * paravirt_pagetable_init() will set up swapper_pg_dir
  * appropriately for the rest of the initialization to work.
  *
  * In general, pagetable_init() assumes that the pagetable may already
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 68466ce..4290d83 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1183,10 +1183,6 @@ static void __init xen_pagetable_init(void)
xen_post_allocator_init();
 }
 
-static void __init xen_pagetable_setup_start(void)
-{
-}
-
 static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
 {
  

[PATCH 2/5] XEN: Remove the base argument from x86_init.paging.pagetable_setup_start PVOPS

[Attilio Rao]

x86_init.paging.pagetable_setup_start for native will however use
swapper_pg_dir in the single place where it is used and for native the
argument is simply unused. Aditionally, the comments already point to
swapper_pg_dir as the sole base touched.
Finally, this will help with further merging of
x86_init.paging.pagetable_setup_start with
x86_init.paging.pagetable_setup_done PVOPS.

Signed-off-by: Attilio Rao 
---
 arch/x86/include/asm/pgtable_types.h |6 +++---
 arch/x86/include/asm/x86_init.h  |2 +-
 arch/x86/kernel/setup.c  |2 +-
 arch/x86/kernel/x86_init.c   |3 +--
 arch/x86/mm/init_32.c|5 -
 arch/x86/xen/mmu.c   |2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index f9e07b0..9b1c1f7 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,11 +303,11 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
-extern void native_pagetable_setup_start(pgd_t *base);
+extern void native_pagetable_setup_start(void);
 extern void native_pagetable_setup_done(void);
 #else
-#define native_pagetable_setup_start x86_init_pgd_start_noop
-#define native_pagetable_setup_done  x86_init_pgd_stop_noop
+#define native_pagetable_setup_start x86_init_pgd_noop
+#define native_pagetable_setup_done  x86_init_pgd_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 439a4c3..efd0075 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -85,7 +85,7 @@ struct x86_init_mapping {
  * @pagetable_setup_done:  platform specific post paging_init() call
  */
 struct x86_init_paging {
-   void (*pagetable_setup_start)(pgd_t *base);
+   void (*pagetable_setup_start)(void);
void (*pagetable_setup_done)(void);
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index ed9094d..d3d8f00 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,7 +961,7 @@ void __init setup_arch(char **cmdline_p)
kvmclock_init();
 #endif
 
-   x86_init.paging.pagetable_setup_start(swapper_pg_dir);
+   x86_init.paging.pagetable_setup_start();
paging_init();
x86_init.paging.pagetable_setup_done();
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index b27b30d..849be14 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,8 +26,7 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_start_noop(pgd_t *unused) { }
-void __init x86_init_pgd_stop_noop(void) { }
+void __init x86_init_pgd_noop(void) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 1019156..7999cef 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,14 +445,17 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
-void __init native_pagetable_setup_start(pgd_t *base)
+void __init native_pagetable_setup_start(void)
 {
unsigned long pfn, va;
+   pgd_t *base;
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
 
+   base = swapper_pg_dir;
+
/*
 * Remove any mappings which extend past the end of physical
 * memory from the boot time page table:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index d847548..04a0a8f 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,7 +1174,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
spin_unlock(>page_table_lock);
 }
 
-static void __init xen_pagetable_setup_start(pgd_t *base)
+static void __init xen_pagetable_setup_start(void)
 {
 }
 
-- 
1.7.2.5

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

[PATCH 3/5] X86/XEN: Introduce the x86_init.paging.pagetable_init PVOPS

[Attilio Rao]

This new PVOPS is responsible to setup the kernel pagetables and
replace entirely x86_init.paging.pagetable_setup_start and
x86_init.paging.pagetable_setup_done PVOPS work.

For performance the x86_64 stub is implemented as a macro to paging_init()
rather than an actual function stub.

Signed-off-by: Attilio Rao 
---
 arch/x86/include/asm/pgtable_types.h |2 +
 arch/x86/include/asm/x86_init.h  |2 +
 arch/x86/kernel/x86_init.c   |1 +
 arch/x86/mm/init_32.c|   35 ++
 arch/x86/xen/mmu.c   |   12 +-
 5 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 9b1c1f7..55f24b5 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,9 +303,11 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
+extern void native_pagetable_init(void);
 extern void native_pagetable_setup_start(void);
 extern void native_pagetable_setup_done(void);
 #else
+#define native_pagetable_initpaging_init
 #define native_pagetable_setup_start x86_init_pgd_noop
 #define native_pagetable_setup_done  x86_init_pgd_noop
 #endif
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index efd0075..a74cc19 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -81,10 +81,12 @@ struct x86_init_mapping {
 
 /**
  * struct x86_init_paging - platform specific paging functions
+ * @pagetable_init:platform specific paging initialization call
  * @pagetable_setup_start: platform specific pre paging_init() call
  * @pagetable_setup_done:  platform specific post paging_init() call
  */
 struct x86_init_paging {
+   void (*pagetable_init)(void);
void (*pagetable_setup_start)(void);
void (*pagetable_setup_done)(void);
 };
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 849be14..c1e910a 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -68,6 +68,7 @@ struct x86_init_ops x86_init __initdata = {
},
 
.paging = {
+   .pagetable_init = native_pagetable_init,
.pagetable_setup_start  = native_pagetable_setup_start,
.pagetable_setup_done   = native_pagetable_setup_done,
},
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 7999cef..2ff4790 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,6 +445,41 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
+void __init native_pagetable_init(void)
+{
+   unsigned long pfn, va;
+   pgd_t *base;
+   pgd_t *pgd;
+   pud_t *pud;
+   pmd_t *pmd;
+   pte_t *pte;
+
+   base = swapper_pg_dir;
+
+   /*
+* Remove any mappings which extend past the end of physical
+* memory from the boot time page table:
+*/
+   for (pfn = max_low_pfn + 1; pfn < 1<<(32-PAGE_SHIFT); pfn++) {
+   va = PAGE_OFFSET + (pfn<> PAGE_SHIFT);
+   paging_init();
+}
 void __init native_pagetable_setup_start(void)
 {
unsigned long pfn, va;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 04a0a8f..68466ce 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,6 +1174,15 @@ static void xen_exit_mmap(struct mm_struct *mm)
spin_unlock(>page_table_lock);
 }
 
+static void xen_post_allocator_init(void);
+
+static void __init xen_pagetable_init(void)
+{
+   paging_init();
+   xen_setup_shared_info();
+   xen_post_allocator_init();
+}
+
 static void __init xen_pagetable_setup_start(void)
 {
 }
@@ -1192,8 +1201,6 @@ static __init void xen_mapping_pagetable_reserve(u64 
start, u64 end)
}
 }
 
-static void xen_post_allocator_init(void);
-
 static void __init xen_pagetable_setup_done(void)
 {
xen_setup_shared_info();
@@ -2068,6 +2075,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 void __init xen_init_mmu_ops(void)
 {
x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
+   x86_init.paging.pagetable_init = xen_pagetable_init;
x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
pv_mmu_ops = xen_mmu_ops;
-- 
1.7.2.5

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

[PATCH 1/5] XEN: Remove the base argument from x86_init.paging.pagetable_setup_done PVOPS

[Attilio Rao]

x86_init.paging.pagetable_setup_done PVOPS does not really need to know about
the base argument, thus just remove it.

Signed-off-by: Attilio Rao 
---
 arch/x86/include/asm/pgtable_types.h |6 +++---
 arch/x86/include/asm/x86_init.h  |2 +-
 arch/x86/kernel/setup.c  |2 +-
 arch/x86/kernel/x86_init.c   |3 ++-
 arch/x86/mm/init_32.c|2 +-
 arch/x86/xen/mmu.c   |2 +-
 6 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 013286a..f9e07b0 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -304,10 +304,10 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
 extern void native_pagetable_setup_start(pgd_t *base);
-extern void native_pagetable_setup_done(pgd_t *base);
+extern void native_pagetable_setup_done(void);
 #else
-#define native_pagetable_setup_start x86_init_pgd_noop
-#define native_pagetable_setup_done  x86_init_pgd_noop
+#define native_pagetable_setup_start x86_init_pgd_start_noop
+#define native_pagetable_setup_done  x86_init_pgd_stop_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 38155f6..439a4c3 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -86,7 +86,7 @@ struct x86_init_mapping {
  */
 struct x86_init_paging {
void (*pagetable_setup_start)(pgd_t *base);
-   void (*pagetable_setup_done)(pgd_t *base);
+   void (*pagetable_setup_done)(void);
 };
 
 /**
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..ed9094d 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -963,7 +963,7 @@ void __init setup_arch(char **cmdline_p)
 
x86_init.paging.pagetable_setup_start(swapper_pg_dir);
paging_init();
-   x86_init.paging.pagetable_setup_done(swapper_pg_dir);
+   x86_init.paging.pagetable_setup_done();
 
if (boot_cpu_data.cpuid_level >= 0) {
/* A CPU has %cr4 if and only if it has CPUID */
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 9f3167e..b27b30d 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,8 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_noop(pgd_t *unused) { }
+void __init x86_init_pgd_start_noop(pgd_t *unused) { }
+void __init x86_init_pgd_stop_noop(void) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 575d86f..1019156 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -477,7 +477,7 @@ void __init native_pagetable_setup_start(pgd_t *base)
paravirt_alloc_pmd(_mm, __pa(base) >> PAGE_SHIFT);
 }
 
-void __init native_pagetable_setup_done(pgd_t *base)
+void __init native_pagetable_setup_done(void)
 {
 }
 
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b65a761..d847548 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1194,7 +1194,7 @@ static __init void xen_mapping_pagetable_reserve(u64 
start, u64 end)
 
 static void xen_post_allocator_init(void);
 
-static void __init xen_pagetable_setup_done(pgd_t *base)
+static void __init xen_pagetable_setup_done(void)
 {
xen_setup_shared_info();
xen_post_allocator_init();
-- 
1.7.2.5

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

[PATCH 0/5] X86/XEN: Merge x86_init.paging.pagetable_setup_start and x86_init.paging.pagetable_setup_done PVOPS and document the semantic

[Attilio Rao]

Currently the definition of x86_init.paging.pagetable_setup_start and
x86_init.paging.pagetable_setup_done is twisted and not really well
defined (in terms of prototypes desired). More specifically:
pagetable_setup_start:
 * it is a nop on x86_32
 * it is a nop for the XEN case
 * cleans up the boot time page table in the x86_64 case

pagetable_setup_done:
 * it is a nop on x86_32
 * sets up accessor functions for pagetable manipulation, for the
   XEN case
 * it is a nop on x86_64

Most of this logic can be skipped by creating a new PVOPS that can handle
pagetable setup and pre/post operations on it.
The new PVOPS must be called only once, during boot-time setup and
after the direct mapping for physical memory is available.

Attilio Rao (5):
  XEN: Remove the base argument from
x86_init.paging.pagetable_setup_done PVOPS
  XEN: Remove the base argument from
x86_init.paging.pagetable_setup_start PVOPS
  X86/XEN: Introduce the x86_init.paging.pagetable_init() PVOPS
  X86/XEN: Retire now unused x86_init.paging.pagetable_setup_start and
x86_init.paging.pagetable_setup_done PVOPS
  X86/XEN: Add few lines explaining simple semantic for
x86_init.paging.pagetable_init PVOPS

 arch/x86/include/asm/pgtable_types.h |6 ++
 arch/x86/include/asm/x86_init.h  |   11 +++
 arch/x86/kernel/setup.c  |4 +---
 arch/x86/kernel/x86_init.c   |4 +---
 arch/x86/mm/init_32.c|   12 ++--
 arch/x86/xen/mmu.c   |   18 +++---
 6 files changed, 24 insertions(+), 31 deletions(-)

-- 
1.7.2.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] regulator: max8907: fix compile error when !CONFIG_OF

[Axel Lin]

> +
> +static inline struct regulator_init_data *match_init_data(int index)
> +{
> +   return NULL;
> +}
> +

Now match_init_data() returns NULL if !CONFIG_OF, so idata may be NULL.

Then I think we may hit NULL pointer dereference here:

switch (pmic->desc[i].id) {
case MAX8907_MBATT:
mbatt_rail_name = idata->constraints.name;
break;

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

Re: [PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence

[Omar Ramirez Luna]

Hi Benoit,

On 20 August 2012 05:21, Benoit Cousson  wrote:
> Hi Omar,
>
> On 08/03/2012 05:52 PM, Omar Ramirez Luna wrote:
>> On 3 August 2012 00:24, Vaibhav Hiremath  wrote:
>>> On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote:
 So in _enable:

 _enable_clocks(oh);
 if (soc_ops.enable_module)
 soc_ops.enable_module(oh);

 The enable_module part seems redundant to me, since the module should
 be already enabled by the first call to _enable_clocks.
>>>
>>> Yes they do same thing, I believe the plan is to get rid of all clock
>>> leaf-nodes in the near future, and let hwmod handle module
>>> enable/disable part.
>>
>> If this is the case then an enable_module call is needed in my patch
>> for when these changes are made. The original works fine but only
>> because currently clock framework does what enable_module is doing.
>
> Yes, that's the case, but I plan to remove most of the leaf clocks ASAP,
> so we cannot rely on that.
>
>> Please let me know if you want me to resend with this change.
>
> Yes, could you please repost with that change?

Not a problem.

> It will be good as well that you remove the leaf clock and use the
> parent clock of current leaf as the main_clock. In that case it will
> ensure that this is the hwmod fmwk that does enable the modulemode and
> not the clock fmwk.

Ok, let me try that.

Thanks for the comments,

Omar
--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[John Stultz]

On 08/20/2012 06:10 PM, John Stultz wrote:

On 08/20/2012 06:04 PM, Fengguang Wu wrote:

Hi John,

The below oops happens in v3.5..v3.6-rc2 and it's bisected down to 
commit
2a8c0883c ("time: Move xtime_nsec adjustment underflow handling 
timekeeping_adjust").


However linux-next is working fine. Do you have any fixes not yet 
sent to Linus?
Yea, there's a fix pending in tip/timers/urgent 
(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values from 
settimeofday or the cmos clock that might overflow a ktime_t.


Out of curiosity, how are you triggering/reproducing this?



Looking at the commit you pointed out, it seems more likely Ingo's fix 
(1d17d17484d40f2d5b35c79518597a2b25296996) might be related, but that 
should have landed in v3.6-rc2.  So I'm not sure.


thanks
-john


--
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/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled

[Omar Ramirez Luna]

Hi Benoit,

On 20 August 2012 09:49, Benoit Cousson  wrote:
> On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote:
>> Some IP blocks might not be using/controlling more than one
>> reset line, this check loosens the restriction to fully use
>> hwmod framework for those drivers.
>>
>> E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
>> - cpu1 might not be used and hence (with previous check)
>>   won't be fully enabled by hwmod code.
>
> You mean that you might have some case where you need to enable the
> mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the
> cpu1 under reset?
>
> So the any_hardreset is indeed not appropriate in that case.
>
> In fact, since the hardreset cannot be handled at all by the hwmod fmwk,
> I'm even wondering if we should take care of checking the state at all.
> But as Paul stated, if was done due to the lack of understanding about
> the diver usage, so maybe things will become clearer once we will have
> that code available.
>
> So I guess that checking for all the lines for the hardreset state is
> anyway already a first step toward a good understanding of the reset
> need for the remote processors.
>
> The patch looks fine to me considering that we do not have a lot of
> information about the usage :-(
>
> Maybe you could add more information in the changelog to explain the way
> you are going to use the reset API.

I'll add an updated description with more information.

Thanks for the comments,

Omar
--
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: BUG: NULL pointer dereference in shmem_evict_inode()

[John Stultz]

On 08/20/2012 06:04 PM, Fengguang Wu wrote:

Hi John,

The below oops happens in v3.5..v3.6-rc2 and it's bisected down to commit
2a8c0883c ("time: Move xtime_nsec adjustment underflow handling 
timekeeping_adjust").

However linux-next is working fine. Do you have any fixes not yet sent to Linus?
Yea, there's a fix pending in tip/timers/urgent 
(4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b) to catch crazy values from 
settimeofday or the cmos clock that might overflow a ktime_t.


Out of curiosity, how are you triggering/reproducing this?

thanks
-john

--
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: [discussion]sched: a rough proposal to enable power saving in scheduler

[Alex Shi]

On 08/20/2012 11:47 PM, Vincent Guittot wrote:

> On 16 August 2012 07:03, Alex Shi  wrote:
>> On 08/16/2012 12:19 AM, Matthew Garrett wrote:
>>
>>> On Mon, Aug 13, 2012 at 08:21:00PM +0800, Alex Shi wrote:
>>>
 power aware scheduling), this proposal will adopt the
 sched_balance_policy concept and use 2 kind of policy: performance, power.
>>>
>>> Are there workloads in which "power" might provide more performance than
>>> "performance"? If so, don't use these terms.
>>>
>>
>>
>> Power scheme should no chance has better performance in design.
> 
> A side effect of packing small tasks on one core is that you always
> use the core with the lowest C-state which will minimize the wake up
> latency so you can sometime get better results than performance mode
> which will try to use a other core in another cluster which will take
> more time to wake up that waiting for the end of the current task.
> 


Sure. some scenario packing tasks into smaller domain will bring
performance benefit.
--
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: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

[Randy Dunlap]

On 08/20/2012 05:23 PM, Dave Airlie wrote:

> On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap  wrote:
>> On 08/19/2012 10:22 PM, Dave Airlie wrote:
>>
>>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
 On 08/17/12 15:55, Dave Airlie wrote:

> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  
>> wrote:
>>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>>
 for , we have verified cases on inteldrmfb, radeondrmfb, and
 cirrusdrmfb.

 This is the last message displayed before the system hangs.  This seems
 to be hitting a large number of users in Fedora, though certainly not
 everyone.  This started happening with the 3.5 updates, and is still an
 issue.  It appears to be a race condition, because various things have
 allowed boot to continue for some users, though there is no clear work
 around. Has anyone else run across this?  Any ideas.  For more
 background we have the following bugs:

 inteldrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=843826

 radeondrmfb:
 https://bugzilla.redhat.com/show_bug.cgi?id=845745

 cirrusdrmfb :
 https://bugzilla.redhat.com/show_bug.cgi?id=843860

 It should be noted that the conflicting fb hw usage message is not new,
 it has been around for a while, but this is the last message seen 
 before
 the hang.
>>>
>>>
>>> Hi,  (adding dri-devel mailing list)
>>>
>>>
>>> I started seeing this problem on 3.5-rc6.
>>>
>>> AFAICT, the system is not actually hung, it's just that no output
>>> is showing up on the real (physical) output device (display) -- it's
>>> going somewhere else (or to the bit bucket).
>>>
>>
>> Can we bisect this at all?

 I guess I'll have to try again.  My first attempt did not
 prove anything, I think because the conflict does not happen
 100% of the time (i.e., it feels like a timing problem).

>> I worry the intel one will bisect to where we moved the conflict
>> resolution earlier, but I'd like to see if applying that patch earlier
>> causes the issue, since radeon has it.

 Do you know of a specific commit that I could revert and test?
>>>
>>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
>>>
>>> might work, but it just changes the timing mostly.
>>>
>>> also testing 3.4 with that on top would be good.
>>
>>
>> That commit doesn't apply cleanly to 3.4, but reverting
>> it on 3.5-rc6 (where I first saw the problem) allows me to boot
>> 3.5-rc6 multiple times without a problem.
>>
>> Maybe Justin can get more stable testing done also..
> 
> Randy do you have a vga= on your kernel command line?


Ah, yes:  "vga=ask"

-- 
~Randy
--
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: [discussion]sched: a rough proposal to enable power saving in scheduler

[Alex Shi]

On 08/20/2012 11:36 PM, Vincent Guittot wrote:

>> > What you want it to keep track of a per-cpu utilization level (inverse
>> > of idle-time) and using PJTs per-task runnable avg see if placing the
>> > new task on will exceed the utilization limit.
>> >
>> > I think some of the Linaro people actually played around with this,
>> > Vincent?
> Sorry for the late reply but I had almost no network access during last weeks.
> 
> So Linaro also works on a power aware scheduler as Peter mentioned.
> 
> Based on previous tests, we have concluded that main drawback of the
> (now removed) old power scheduler was that we had no way to make
> difference between short and long running tasks whereas it's a key
> input (at least for phone) for deciding to pack tasks and for
> selecting the core on an asymmetric system.


It is hard to estimate future in general view point. but from hack
point, maybe you can add something to hint this from task_struct. :)

> One additional key information is the power distribution in the system
> which can have a finer granularity than current sched_domain
> description. Peter's proposal was to use a SHARE_POWERLINE flag
> similarly to flags that already describe if a sched_domain share
> resources or cpu capacity.


Seems I missed this. what's difference with current SD_SHARE_CPUPOWER
and SD_SHARE_PKG_RESOURCES.

> 
> With these 2 new information, we can have a 1st power saving scheduler
> which spread or packed tasks across core and package


Fine, I like to test them on X86, plus SMT and NUMA :)

> 
> Vincent


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

[Minchan Kim]

On Thu, Aug 16, 2012 at 10:47:58PM -0700, Nitin Gupta wrote:
> On 08/13/2012 11:22 PM, Minchan Kim wrote:
> > Hi Greg,
> > 
> > On Mon, Aug 13, 2012 at 07:35:30PM -0700, 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
> > 
> > Thanks!
> > 
> >> without getting acks from the -mm maintainers, sorry.  Please work with
> > 
> > Nitin suggested zsmalloc could be in /lib or /zram out of /mm but I want
> > to confirm it from akpm so let's wait his opinion.
> > 
> 
> akpm, please?

To Nitin
Now both zram/zcache uses zsmalloc so I think second place is under /lib than
/zram if we really want to put it out of /mm but my preference is still
under /mm. If akpm don't oppose, I will do.
(Let's not consider removal of zsmalloc in zcache at the moment because
it's just Dan's trial and it's not realized yet. It's very twisted problem
and I don't expect it will finish soon :( )

To akpm,

I would like to put zsmalloc under /mm because it uses a few field of struct
page freely. IIRC, you pointed out, too. What do you think about it?
If you don't want, I will put zsmalloc under /lib.

To Jens,

I would like to put zram under driver/blocks.
Can I get your Ack?

> 
> > Anyway, another question. zram would be under driver/blocks.
> > Do I need ACK from Jens for that?
> > 
> 
> Added Jens to CC list.
> 
> Thanks,
> Nitin
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

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

Re: [PATCH 0/2][resend] genirq: export patches

[Kuninori Morimoto]

Hi all

> These are "resend" of genirq export patches.
> 
> Kuninori Morimoto (2):
>   genirq: export irq_set_chip_and_handler_name()
>   genirq: export dummy_irq_chip

get_maintainer.pl showed me that Thomas is the maintainer
of ${LINUX}/kernel/irq/,
but am I wrong ?
I think there is no response for these patches.

Who can care these patches ?
Should I resend again ?

> 
> 
> > 
> > Hi Thomas
> > 
> > Could you please teach me current status of these patches ?
> > 
> > Kuninori Morimoto (2):
> >   genirq: export irq_set_chip_and_handler_name()
> >   genirq: export dummy_irq_chip
> > 
> > At Mon, 9 Jul 2012 22:34:23 +0200,
> > Linus Walleij wrote:
> > > 
> > > On Mon, Jul 9, 2012 at 4:04 AM, Kuninori Morimoto
> > >  wrote:
> > > 
> > > > Hi Linus Walleij, Stephen, and Thomas
> > > >
> > > >> >> > After merging the gpio-lw tree, today's linux-next build (x86_64
> > > >> >> > allmodconfig) failed like this:
> > > >> >> >
> > > >> >> > ERROR: "irq_set_chip_and_handler_name" 
> > > >> >> > [drivers/gpio/gpio-pcf857x.ko] undefined!
> > > >> >> > ERROR: "dummy_irq_chip" [drivers/gpio/gpio-pcf857x.ko] undefined!
> > > >> >>
> > > >> >> Thanks, I've dropped the offending patch, Kuninori can you look 
> > > >> >> into this and
> > > >> >> provide a new patch? It's the second patch from your patch set.
> > > >> >
> > > >> > OK. I will, but it will be next week.
> > > >> > And could you please show me where is your repository/branch ?
> > > >>
> > > >> http://git.kernel.org/?p=linux/kernel/git/linusw/linux-gpio.git;a=summary
> > > >> branch devel/for-next
> > > >
> > > > In my check, these are export symbol issue.
> > > > I think above 2 function/struct were not exported for module.
> > > >
> > > > Is it poosible to solve this issue by these patches ?
> > > 
> > > Hm Thomas has to answer to that (and merge the patches, if he
> > > likes them).
> > > 
> > > Yours,
> > > Linus Walleij
> > 
> > 
> > Best regards
> > ---
> > Kuninori Morimoto


Best regards
---
Kuninori Morimoto
--
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 09/20] staging: comedi: adv_pci1723: fix initial dio subdevice state and io_bits

[H Hartley Sweeten]

On Monday, August 20, 2012 2:51 PM, H Hartley Sweeten wrote:
> On Monday, August 20, 2012 2:49 PM, Dan Carpenter wrote:
>> On Fri, Aug 17, 2012 at 06:17:38PM -0700, H Hartley Sweeten wrote:
>>> +   if (this_board->n_diochan) {
>>> +   s = dev->subdevices + subdev;
>>
>> This pointer math sucks still...  I feel like the unreadable code is
>> part of what caused this bug.
>>
>> We don't have to change these all at once.  If we fix only one line,
>> then at least one line will be readable and that is one more than
>> before so *improvement*.
>
> Hello Dan,
>
> I'll work of changing the pointer math to array access.
>
> I'll try to post a big chunk of them today.
>

Dan,

I just posted a patch that changes all the pointer math for the
comedi_subdevice to array access.

It's based on top of the changes I have already posted for the
comedi subsystem. As long as Greg doesn't find any issues with
those, this patch should apply cleanly.

If I need to I will rebase it.

Regards,
Hartley

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

[Paul Gortmaker]

I'm announcing the release of the 2.6.34.13 kernel.

All 2.6.34 users are strongly encouraged to update.

The updated 2.6.34.y git tree can be found at:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-2.6.34.y
and can be browsed at the normal kernel.org git web browser:
   
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-2.6.34.y

Thanks,
Paul.
---

The following changes since commit 744f2110ae5939ebb75b2a3dd57ec64708481f82:

  Linux 2.6.34.12 (2012-05-17 11:27:28 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
tags/v2.6.34.13

for you to fetch changes up to 5b765b08fa5fbbba1131dcc459f8991d81e4f8d7:

  Linux 2.6.34.13 (2012-08-20 14:45:22 -0400)


This is the 2.6.34.13 stable release


Al Viro (1):
  deal with races in /proc/*/{syscall,stack,personality}

Alan Stern (1):
  usb-storage: Accept 8020i-protocol commands longer than 12 bytes

Alex Williamson (2):
  KVM: Remove ability to assign a device without iommu support
  KVM: Device assignment permission checks

Alexandre Bounine (1):
  drivers/net/rionet.c: fix ethernet address macros for LE platforms

Andrew Vasquez (1):
  qla2xxx: Correct inadvertent loop state transitions during port-update 
handling.

Andrew Worsley (1):
  USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c

Aneesh Kumar K.V (1):
  fs/9p: Fid is not valid after a failed clunk.

Anton Blanchard (1):
  ipr: Always initiate hard reset in kdump kernel

Artur Zimmer (1):
  USB: Serial: Add PID(0xF7C0) to FTDI SIO driver for a zeitcontrol-device

Avi Kivity (1):
  KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

Axel Lin (2):
  ASoC: wm8940: Properly set codec->dapm.bias_level
  ASoC: ak4535: fixup cache register table

Bart Van Assche (1):
  [SCSI] Make scsi_free_queue() kill pending SCSI commands

Ben Hutchings (1):
  rose: Add length checks to CALL_REQUEST parsing

Bernd Schubert (1):
  nfsd4: Remove check for a 32-bit cookie in nfsd4_readdir()

Borislav Petkov (1):
  kbuild: Add extra gcc checks

Carlos Maiolino (1):
  xfs: Fix possible memory corruption in xfs_readlink

Carsten Otte (1):
  KVM: s390: check cpu_id prior to using it

Chris Wilson (2):
  drm/i915: Sanity check pread/pwrite
  drm/i915: Rephrase pwrite bounds checking to avoid any potential overflow

Dan Carpenter (2):
  PM / Suspend: Off by one in pm_suspend()
  hfs: add sanity check for file name length

Daniel Schwierzeck (1):
  atm: br2684: Fix oops due to skb->dev being NULL

Dave Jones (1):
  kbuild: Disable -Wunused-but-set-variable for gcc 4.6.0

David Henningsson (2):
  ALSA: HDA: Cirrus - fix "Surround Speaker" volume control name
  ALSA: HDA: Add new revision for ALC662

David Howells (1):
  KEYS: Fix a NULL pointer deref in the user-defined key type

David S. Miller (1):
  sparc: Allow handling signals when stack is corrupted.

Denis Pershin (1):
  usb: cdc-acm: Owen SI-30 support

Eric Benoit (1):
  USB: pl2303: add id for SMART device

Eric Dumazet (2):
  net_sched: Fix qdisc_notify()
  scm: lower SCM_MAX_FD

Eric Paris (1):
  fcaps: clear the same personality flags as suid when fcaps are used

Eric Van Hensbergen (1):
  net/9p: fix client code to fail more gracefully on protocol error

Filip Palian (1):
  Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

Florian Echtler (1):
  USB: Serial: Add device ID for Sierra Wireless MC8305

Greg Kroah-Hartman (1):
  hfsplus: Fix potential buffer overflows

H. Peter Anvin (6):
  regset: Prevent null pointer reference on readonly regsets
  x86, cpu: Add CPU flags for F16C and RDRND
  random: Add support for architectural random hooks
  x86, random: Architectural inlines to get random integers with RDRAND
  random: Adjust the number of loops when initializing
  random: mix in architectural randomness in extract_buf()

Hakan Kvist (1):
  USB: ftdi_sio: add PID for Sony Ericsson Urban

Hendrik Brueckner (1):
  hvc_console: Improve tty/console put_chars handling

Herbert Xu (1):
  ipv6: Add GSO support on forwarding path

Hugh Dickins (1):
  vm: fix vm_pgoff wrap in upward expansion

Ian Campbell (2):
  sparc: fix array bounds error setting up PCIC NMI trap
  xen/timer: Missing IRQF_NO_SUSPEND in timer code broke suspend.

Igor Mammedov (1):
  xen: x86_32: do not enable iterrupts when returning from exception in 
interrupt context

J. Bruce Fields (2):
  locks: fix checking of fcntl_setlease argument
  nfsd4: ignore WANT bits in open downgrade

Jack Wang (1):
  libsas: set sas_address and device type of rphy

James Bottomley (1):
  3w-9xxx: 

Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

[Dave Airlie]

On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap  wrote:
> On 08/19/2012 10:22 PM, Dave Airlie wrote:
>
>> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
>>> On 08/17/12 15:55, Dave Airlie wrote:
>>>
 On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  
> wrote:
>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>
>>> for , we have verified cases on inteldrmfb, radeondrmfb, and
>>> cirrusdrmfb.
>>>
>>> This is the last message displayed before the system hangs.  This seems
>>> to be hitting a large number of users in Fedora, though certainly not
>>> everyone.  This started happening with the 3.5 updates, and is still an
>>> issue.  It appears to be a race condition, because various things have
>>> allowed boot to continue for some users, though there is no clear work
>>> around. Has anyone else run across this?  Any ideas.  For more
>>> background we have the following bugs:
>>>
>>> inteldrmfb:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=843826
>>>
>>> radeondrmfb:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=845745
>>>
>>> cirrusdrmfb :
>>> https://bugzilla.redhat.com/show_bug.cgi?id=843860
>>>
>>> It should be noted that the conflicting fb hw usage message is not new,
>>> it has been around for a while, but this is the last message seen before
>>> the hang.
>>
>>
>> Hi,  (adding dri-devel mailing list)
>>
>>
>> I started seeing this problem on 3.5-rc6.
>>
>> AFAICT, the system is not actually hung, it's just that no output
>> is showing up on the real (physical) output device (display) -- it's
>> going somewhere else (or to the bit bucket).
>>
>
> Can we bisect this at all?
>>>
>>> I guess I'll have to try again.  My first attempt did not
>>> prove anything, I think because the conflict does not happen
>>> 100% of the time (i.e., it feels like a timing problem).
>>>
> I worry the intel one will bisect to where we moved the conflict
> resolution earlier, but I'd like to see if applying that patch earlier
> causes the issue, since radeon has it.
>>>
>>> Do you know of a specific commit that I could revert and test?
>>
>> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
>>
>> might work, but it just changes the timing mostly.
>>
>> also testing 3.4 with that on top would be good.
>
>
> That commit doesn't apply cleanly to 3.4, but reverting
> it on 3.5-rc6 (where I first saw the problem) allows me to boot
> 3.5-rc6 multiple times without a problem.
>
> Maybe Justin can get more stable testing done also..

Randy do you have a vga= on your kernel command line?

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

Re: changing timeslice in linux

[Namhyung Kim]

On Mon, 20 Aug 2012 07:51:52 -0700, Xin Tong wrote:
> On Sun, Aug 19, 2012 at 10:54 PM, Mike Galbraith  wrote:
>> On Sun, 2012-08-19 at 11:58 -0700, Xin Tong wrote:
>>> I have 2 questions about linux 2.6 x86_64 scheduler.
>>>
>>> 1. is the default scheduling algorithm SCHED_NORMAL in linux ?
>>
>> Yes.
> Is there any document describing what the sched_normal is ? it is more
> difficult than SCHED_RR to infer its meaning just based on its name ?
>>
>>> 2. how do i change the time slice in linux source code ?
>>
>> You shouldn't need to.  You can tune "slice" by adjusting
>> sched_latency_ns and sched_min_granularity_ns, but note that "slice" is
>> not a fixed quantum.  Also note that CFS preemption decisions are based
>> upon instantaneous state.  A task may have received a full (variable)
>> "slice" of CPU time, but preemption will be triggered only if a more
>> deserving task is available, so a "slice" is not the "max uninterrupted
>> CPU time" that you may expect it to be.. but it is somewhat similar.
>>
>> -Mike
>>
> This can be done without recompiling and reinstalling the kernel ?
> maybe one simply needs to write to a device file under /dev ?

You can find those files under /proc/sys/kernel/.

Thanks,
Namhyung
--
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: BUG: unable to handle kernel paging request at 00010016

[Dave Haywood]

On 19/08/2012 09:21, Artem Savkov wrote:

On Sat, Aug 18, 2012 at 11:25:43PM -0500, Shaun Ruffell wrote:

Adding linux-net to the CC list.

On Fri, Aug 17, 2012 at 11:57:56PM +0100, Dave Haywood wrote:

[1.] One line summary of the problem:
BUG: unable to handle kernel paging request at 00010016

System boots then crashes a 5-10 or so seconds after getting to the 
login prompt
Booting without the network cable attached prevents the crash (no 
evidence beyond 10 minutes after boot)

   Diagnostics:
Captured the boot and managed a login + dmesg before the crash
Some of the log looks corrupted. Probably my crappy usb dongle serial 
flow control but left it in anyway

[snip]

Just a note that I see this as well. It happens reliably for me after trying to
login to the machine via ssh.

Here is the back trace I collected on the serial port.

There is a patch posted on netdev that fixes this for me:
http://patchwork.ozlabs.org/patch/178525/


Bisected to:

5d299f3d3c8a2fbc732b1bf03af36333ccec3130 is the first bad commit

commit 5d299f3d3c8a2fbc732b1bf03af36333ccec3130

Author: Eric Dumazet 

Date:   Mon Aug 6 05:09:33 2012 +

net: ipv6: fix TCP early demux

IPv6 needs a cookie in dst_check() call.

We need to add rx_dst_cookie and provide a family independent

sk_rx_dst_set(sk, skb) method to properly support IPv6 TCP early demux.

Signed-off-by: Eric Dumazet 

Signed-off-by: David S. Miller 

:04 04 96ade77f304a89c1886fbaa125b03d1f5699e418 
485a021044b8f52ae8562e4e90d8f6536863f5e7 M  include

:04 04 1ebd6792af2014ad11979216b9a56504a28d5782 
7a53fc9e7fb219c4cacb1bbb3b6867f30790dfd1 M  net




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

Re: [PATCH 3/3] netfilter: replace list_for_each_continue_rcu with new interface

[Paul E. McKenney]

On Fri, Aug 17, 2012 at 12:33:39PM +0800, Michael Wang wrote:
> From: Michael Wang 
> 
> This patch replaces list_for_each_continue_rcu() with
> list_for_each_entry_continue_rcu() to allow removing
> list_for_each_continue_rcu().
> 
> Signed-off-by: Michael Wang 

Reviewed-by: Paul E. McKenney 

> ---
>  net/netfilter/core.c |   11 +++
>  1 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> index e19f365..50225bd 100644
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core.c
> @@ -131,14 +131,14 @@ unsigned int nf_iterate(struct list_head *head,
>   int hook_thresh)
>  {
>   unsigned int verdict;
> + struct nf_hook_ops *elem = list_entry_rcu(*i,
> + struct nf_hook_ops, list);
> 
>   /*
>* The caller must not block between calls to this
>* function because of risk of continuing from deleted element.
>*/
> - list_for_each_continue_rcu(*i, head) {
> - struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;
> -
> + list_for_each_entry_continue_rcu(elem, head, list) {
>   if (hook_thresh > elem->priority)
>   continue;
> 
> @@ -155,11 +155,14 @@ repeat:
>   continue;
>   }
>  #endif
> - if (verdict != NF_REPEAT)
> + if (verdict != NF_REPEAT) {
> + *i = >list;
>   return verdict;
> + }
>   goto repeat;
>   }
>   }
> + *i = >list;
>   return NF_ACCEPT;
>  }
> 
> -- 
> 1.7.4.1
> 
> 

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

Re: [PATCH 2/3] kmemleak: replace list_for_each_continue_rcu with new interface

[Paul E. McKenney]

On Fri, Aug 17, 2012 at 12:33:34PM +0800, Michael Wang wrote:
> From: Michael Wang 
> 
> This patch replaces list_for_each_continue_rcu() with
> list_for_each_entry_continue_rcu() to save a few lines
> of code and allow removing list_for_each_continue_rcu().
> 
> Signed-off-by: Michael Wang 

Reviewed-by: Paul E. McKenney 

> ---
>  mm/kmemleak.c |6 ++
>  1 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 45eb621..0de83b4 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -1483,13 +1483,11 @@ static void *kmemleak_seq_next(struct seq_file *seq, 
> void *v, loff_t *pos)
>  {
>   struct kmemleak_object *prev_obj = v;
>   struct kmemleak_object *next_obj = NULL;
> - struct list_head *n = _obj->object_list;
> + struct kmemleak_object *obj = prev_obj;
> 
>   ++(*pos);
> 
> - list_for_each_continue_rcu(n, _list) {
> - struct kmemleak_object *obj =
> - list_entry(n, struct kmemleak_object, object_list);
> + list_for_each_entry_continue_rcu(obj, _list, object_list) {
>   if (get_object(obj)) {
>   next_obj = obj;
>   break;
> -- 
> 1.7.4.1
> 
> 

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

Re: [PATCH 1/3] raid: replace list_for_each_continue_rcu with new interface

[Paul E. McKenney]

On Fri, Aug 17, 2012 at 12:33:29PM +0800, Michael Wang wrote:
> From: Michael Wang 
> 
> This patch replaces list_for_each_continue_rcu() with
> list_for_each_entry_continue_rcu() to save a few lines
> of code and allow removing list_for_each_continue_rcu().
> 
> Signed-off-by: Michael Wang 

Getting rid of list_for_each_continue_rcu() would indeed be a good thing!

Reviewed-by: Paul E. McKenney 

> ---
>  drivers/md/bitmap.c |9 +++--
>  1 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 15dbe03..b160828 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -163,20 +163,17 @@ static struct md_rdev *next_active_rdev(struct md_rdev 
> *rdev, struct mddev *mdde
>* As devices are only added or removed when raid_disk is < 0 and
>* nr_pending is 0 and In_sync is clear, the entries we return will
>* still be in the same position on the list when we re-enter
> -  * list_for_each_continue_rcu.
> +  * list_for_each_entry_continue_rcu.
>*/
> - struct list_head *pos;
>   rcu_read_lock();
>   if (rdev == NULL)
>   /* start at the beginning */
> - pos = >disks;
> + rdev = list_entry_rcu(>disks, struct md_rdev, same_set);
>   else {
>   /* release the previous rdev and start from there. */
>   rdev_dec_pending(rdev, mddev);
> - pos = >same_set;
>   }
> - list_for_each_continue_rcu(pos, >disks) {
> - rdev = list_entry(pos, struct md_rdev, same_set);
> + list_for_each_entry_continue_rcu(rdev, >disks, same_set) {
>   if (rdev->raid_disk >= 0 &&
>   !test_bit(Faulty, >flags)) {
>   /* this is a usable devices */
> -- 
> 1.7.4.1
> 
> 

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

[GIT PULL] PCI updates for v3.6

[Bjorn Helgaas]

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://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git for-linus

for you to fetch changes up to 9f6445a05b712663b8101a5d2c060a5c40a41fe4:

  Merge branch 'pci/rafael-3.6-fixes' into for-linus (2012-08-15 12:10:39 -0600)


Here are two patches from Rafael Wysocki.  One fixes an EHCI-related
hibernation crash on ASUS boxes.  We fixed a similar suspend issue in
v3.6-rc1, and this applies the same fix to the hibernate path.  The
other fixes D3/D3cold/D4 messages related to the D3cold support we
merged in v3.6-rc1.

We'd like both to be included in v3.6.



Bjorn Helgaas (1):
  Merge branch 'pci/rafael-3.6-fixes' into for-linus

Rafael J. Wysocki (2):
  PCI / PM: Fix D3/D3cold/D4 messages printed by acpi_pci_set_power_state()
  PCI: EHCI: Fix crash during hibernation on ASUS computers

 drivers/pci/pci-acpi.c   | 4 ++--
 drivers/pci/pci-driver.c | 7 +++
 2 files changed, 9 insertions(+), 2 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: [GIT PULL] x86, microcode, AMD: Per-family patches cache

[H. Peter Anvin]

On 08/17/2012 07:30 AM, Borislav Petkov wrote:

Hi guys,

please pull, thanks.

The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92:

   Linux 3.6-rc2 (2012-08-16 14:51:24 -0700)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git 
tags/microcode-updates-for-3.7

for you to fetch changes up to cd692919bed1d59a440ffaed585ebc3c9d8c3406:

   x86, microcode, AMD: Rewrite patch application procedure (2012-08-17 
14:17:42 +0200)



Hmmm... this isn't actually present on git.kernel.org, and 01/12 is 
missing from your "v0" patchset on LKML (nevermind that a "v0" 
designator screams "don't apply"...)


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

Re: regression with poll(2)

[Andrew Morton]

On Mon, 20 Aug 2012 11:30:59 +0200
Eric Dumazet  wrote:

> On Mon, 2012-08-20 at 10:04 +0100, Mel Gorman wrote:
> 
> > Can the following patch be tested please? It is reported to fix an fio
> > regression that may be similar to what you are experiencing but has not
> > been picked up yet.
> > 
> > -
> 
> This seems to help here.
> 
> Boot your machine with "mem=768M" or a bit less depending on your setup,
> and try a netperf.
> 
> -> before patch :
> 
> # netperf
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> localhost.localdomain () port 0 AF_INET
> Recv   SendSend  
> Socket Socket  Message  Elapsed  
> Size   SizeSize Time Throughput  
> bytes  bytes   bytessecs.10^6bits/sec  
> 
>  87380  16384  1638414.00   6.05   
> 
> -> after patch :
> 
> Recv   SendSend  
> Socket Socket  Message  Elapsed  
> Size   SizeSize Time Throughput  
> bytes  bytes   bytessecs.10^6bits/sec  
> 
>  87380  16384  1638410.0018509.73   

"seem to help"?  Was previous performance fully restored?
--
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: Bug report

[Alan Cox]

On Mon, 20 Aug 2012 15:43:35 -0700
Randy Dunlap  wrote:

> (cc-ing linux-ide mailing list)

Classic "no IRQ being delivered" - looks like a platform IRQ routing
problem
--
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: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver

[Randy Dunlap]

On 08/19/2012 10:22 PM, Dave Airlie wrote:

> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap  wrote:
>> On 08/17/12 15:55, Dave Airlie wrote:
>>
>>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie  wrote:
 On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap  wrote:
> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>
>> for , we have verified cases on inteldrmfb, radeondrmfb, and
>> cirrusdrmfb.
>>
>> This is the last message displayed before the system hangs.  This seems
>> to be hitting a large number of users in Fedora, though certainly not
>> everyone.  This started happening with the 3.5 updates, and is still an
>> issue.  It appears to be a race condition, because various things have
>> allowed boot to continue for some users, though there is no clear work
>> around. Has anyone else run across this?  Any ideas.  For more
>> background we have the following bugs:
>>
>> inteldrmfb:
>> https://bugzilla.redhat.com/show_bug.cgi?id=843826
>>
>> radeondrmfb:
>> https://bugzilla.redhat.com/show_bug.cgi?id=845745
>>
>> cirrusdrmfb :
>> https://bugzilla.redhat.com/show_bug.cgi?id=843860
>>
>> It should be noted that the conflicting fb hw usage message is not new,
>> it has been around for a while, but this is the last message seen before
>> the hang.
>
>
> Hi,  (adding dri-devel mailing list)
>
>
> I started seeing this problem on 3.5-rc6.
>
> AFAICT, the system is not actually hung, it's just that no output
> is showing up on the real (physical) output device (display) -- it's
> going somewhere else (or to the bit bucket).
>

 Can we bisect this at all?
>>
>> I guess I'll have to try again.  My first attempt did not
>> prove anything, I think because the conflict does not happen
>> 100% of the time (i.e., it feels like a timing problem).
>>
 I worry the intel one will bisect to where we moved the conflict
 resolution earlier, but I'd like to see if applying that patch earlier
 causes the issue, since radeon has it.
>>
>> Do you know of a specific commit that I could revert and test?
> 
> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5
> 
> might work, but it just changes the timing mostly.
> 
> also testing 3.4 with that on top would be good.


That commit doesn't apply cleanly to 3.4, but reverting
it on 3.5-rc6 (where I first saw the problem) allows me to boot
3.5-rc6 multiple times without a problem.

Maybe Justin can get more stable testing done also..

thanks,
-- 
~Randy
--
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: Bug report

[Randy Dunlap]

(cc-ing linux-ide mailing list)


On 08/20/2012 03:31 PM, mr.shroom wrote:

> SATA for kernel(s) 3.5+ has an issue with IRQ Balancing on AMD SB710
> with motherboard ASRock m3a770d3.
> 
> The problem started while using Arch linux, after going back to Debian
> it persisted.  I had tried to find problems with the bug but couldn't
> find any direct help online.  I had a break when finding similar bugs
> on other sites stating that IRQ Balancing might be the fault.  So I
> tried ACPI_IRQ_NOBALANCE in the kernel boot parameters and so far the
> issue has stopped.
> 
> Linux version 3.6.0-rc2 (mboy@debian) (gcc version 4.7.1 (Debian
> 4.7.1-6) ) #1 SMP Sat Aug 18 00:46:06 CDT 2012
> 
> Aug 20 12:32:08 debian kernel: [42238.075368] ata4.00: exception Emask
> 0x0 SAct 0x7f SErr 0x0 action 0x6 frozen
> Aug 20 12:32:08 debian kernel: [42238.075373] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075377] ata4.00: cmd
> 61/08:00:c8:0a:89/00:00:01:00:00/40 tag 0 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075377]  res
> 40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075379] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075381] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075384] ata4.00: cmd
> 61/08:08:f8:cb:8a/00:00:03:00:00/40 tag 1 ncq 4096 out
> Aug 20 12:32:08 debian kernel: [42238.075384]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075386] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075388] ata4.00: failed command:
> WRITE FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075391] ata4.00: cmd
> 61/10:10:80:95:86/00:00:08:00:00/40 tag 2 ncq 8192 out
> Aug 20 12:32:08 debian kernel: [42238.075391]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075393] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075394] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075397] ata4.00: cmd
> 60/60:18:60:71:62/00:00:00:00:00/40 tag 3 ncq 49152 in
> Aug 20 12:32:08 debian kernel: [42238.075397]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075399] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075401] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075404] ata4.00: cmd
> 60/08:20:c8:71:62/00:00:00:00:00/40 tag 4 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075404]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075406] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075407] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075410] ata4.00: cmd
> 60/18:28:d8:71:62/00:00:00:00:00/40 tag 5 ncq 12288 in
> Aug 20 12:32:08 debian kernel: [42238.075410]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075412] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075413] ata4.00: failed command:
> READ FPDMA QUEUED
> Aug 20 12:32:08 debian kernel: [42238.075417] ata4.00: cmd
> 60/08:30:f8:71:62/00:00:00:00:00/40 tag 6 ncq 4096 in
> Aug 20 12:32:08 debian kernel: [42238.075417]  res
> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Aug 20 12:32:08 debian kernel: [42238.075418] ata4.00: status: { DRDY }
> Aug 20 12:32:08 debian kernel: [42238.075422] ata4: hard resetting link
> 
> After it would reset, it would try SATA I, fail, then mount the drive
> as RO.  I'm running a Phenom II on Debian Wheezy with a bit of Sid,
> don't have the time at the moment to get a better grasp on what you
> need for a proper bug report but I hope this helps.
> --


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

Bug report

[mr.shroom]

SATA for kernel(s) 3.5+ has an issue with IRQ Balancing on AMD SB710
with motherboard ASRock m3a770d3.

The problem started while using Arch linux, after going back to Debian
it persisted.  I had tried to find problems with the bug but couldn't
find any direct help online.  I had a break when finding similar bugs
on other sites stating that IRQ Balancing might be the fault.  So I
tried ACPI_IRQ_NOBALANCE in the kernel boot parameters and so far the
issue has stopped.

Linux version 3.6.0-rc2 (mboy@debian) (gcc version 4.7.1 (Debian
4.7.1-6) ) #1 SMP Sat Aug 18 00:46:06 CDT 2012

Aug 20 12:32:08 debian kernel: [42238.075368] ata4.00: exception Emask
0x0 SAct 0x7f SErr 0x0 action 0x6 frozen
Aug 20 12:32:08 debian kernel: [42238.075373] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075377] ata4.00: cmd
61/08:00:c8:0a:89/00:00:01:00:00/40 tag 0 ncq 4096 out
Aug 20 12:32:08 debian kernel: [42238.075377]  res
40/00:00:00:4f:c2/00:00:00:4f:c2/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075379] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075381] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075384] ata4.00: cmd
61/08:08:f8:cb:8a/00:00:03:00:00/40 tag 1 ncq 4096 out
Aug 20 12:32:08 debian kernel: [42238.075384]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075386] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075388] ata4.00: failed command:
WRITE FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075391] ata4.00: cmd
61/10:10:80:95:86/00:00:08:00:00/40 tag 2 ncq 8192 out
Aug 20 12:32:08 debian kernel: [42238.075391]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075393] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075394] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075397] ata4.00: cmd
60/60:18:60:71:62/00:00:00:00:00/40 tag 3 ncq 49152 in
Aug 20 12:32:08 debian kernel: [42238.075397]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075399] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075401] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075404] ata4.00: cmd
60/08:20:c8:71:62/00:00:00:00:00/40 tag 4 ncq 4096 in
Aug 20 12:32:08 debian kernel: [42238.075404]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075406] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075407] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075410] ata4.00: cmd
60/18:28:d8:71:62/00:00:00:00:00/40 tag 5 ncq 12288 in
Aug 20 12:32:08 debian kernel: [42238.075410]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075412] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075413] ata4.00: failed command:
READ FPDMA QUEUED
Aug 20 12:32:08 debian kernel: [42238.075417] ata4.00: cmd
60/08:30:f8:71:62/00:00:00:00:00/40 tag 6 ncq 4096 in
Aug 20 12:32:08 debian kernel: [42238.075417]  res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 20 12:32:08 debian kernel: [42238.075418] ata4.00: status: { DRDY }
Aug 20 12:32:08 debian kernel: [42238.075422] ata4: hard resetting link

After it would reset, it would try SATA I, fail, then mount the drive
as RO.  I'm running a Phenom II on Debian Wheezy with a bit of Sid,
don't have the time at the moment to get a better grasp on what you
need for a proper bug report but I hope this helps.
--
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 3/9] rbtree: place easiest case first in rb_erase()

[Andrew Morton]

On Mon, 20 Aug 2012 15:05:25 -0700
Michel Lespinasse  wrote:

> In rb_erase, move the easy case (node to erase has no more than
> 1 child) first. I feel the code reads easier that way.

Well.  For efficiency we should put the commonest case first.  Is that
the case here?

> --- a/lib/rbtree.c
> +++ b/lib/rbtree.c
> @@ -368,17 +368,28 @@ static void __rb_erase_color(struct rb_node *node, 
> struct rb_node *parent,
>  
>  void rb_erase(struct rb_node *node, struct rb_root *root)
>  {
> - struct rb_node *child, *parent;
> + struct rb_node *child = node->rb_right, *tmp = node->rb_left;

Coding style nit: multiple-definitions-per-line makes it harder to
locate a particular definition, and from long experience I can assure
you that it makes management of subsequent overlapping patches quite a
lot harder.  Also, one-definition-per-line gives room for a nice little
comment, and we all like nice little comments.

Also, "tmp" is a rotten name.  Your choice of an identifier is your
opportunity to communicate something to the reader.  When you choose
"tmp", you threw away that opportunity.  Should it be called "left"?


--- a/lib/rbtree.c~rbtree-place-easiest-case-first-in-rb_erase-fix
+++ a/lib/rbtree.c
@@ -368,12 +368,13 @@ static void __rb_erase_color(struct rb_n
 
 void rb_erase(struct rb_node *node, struct rb_root *root)
 {
-   struct rb_node *child = node->rb_right, *tmp = node->rb_left;
+   struct rb_node *child = node->rb_right
+   struct rb_node *tmp = node->rb_left;
struct rb_node *parent;
int color;
 
if (!tmp) {
-   case1:
+case1:
/* Case 1: node to erase has no more than 1 child (easy!) */
 
parent = rb_parent(node);
_

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

the 3.4 kernel tree will be -longterm

[Greg KH]

As I'm getting a few questions about this, and I realized that I never
sent out an email about this, yes, the 3.4 kernel tree will be the next
-longterm kernel that I will be maintaining for at least 2 years.

Currently I'm maintaining the following stable kernel trees for the
following amount of time:
3.0 - for at least one more year
3.4 - for at least two years
3.5 - until 3.6.1 is out

Hope this helps clear up any rumors floating around.  If anyone has any
questions, please let me know.

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

Re: [RFC PATCH 1/1] fair.c: Add/Export find_idlest_perfer_cpu API

[Shirley Ma]

On Mon, 2012-08-20 at 14:00 +0200, Peter Zijlstra wrote:
> On Fri, 2012-08-17 at 12:46 -0700, Shirley Ma wrote:
> > Add/Export a new API for per-cpu thread model networking device
> driver
> > to choose a preferred idlest cpu within allowed cpumask.
> > 
> > The receiving CPUs of a networking device are not under cgroup
> controls.
> > Normally the receiving work will be scheduled on the cpu on which
> the
> > interrupts are received. When such a networking device uses per-cpu
> > thread model, the cpu which is chose to process the packets might
> not be
> > part of cgroup cpusets without using such an API here. 
> > 
> > On NUMA system, by using the preferred cpumask from the same NUMA
> node
> > would help to reduce expensive cross memory access to/from the other
> > NUMA node.
> > 
> > KVM per-cpu vhost will be the first one to use this API. Any other
> > device driver which uses per-cpu thread model and has cgroup cpuset
> > control will use this API later.
> 
> How often will this be called and how do you obtain the cpumasks
> provided to the function? 

It depends. It might be called pretty often if the user keeps changing
cgroups control cpuset. It might be less called if the cgroups control
cpuset is stable, and the host scheduler always schedules the work on
the same NUMA node.

The preferred cpumasks are obtained from local numa node. The allowed
cpumasks are obtained from caller's task allowed cpumasks (cgroups
control cpuset).

Thanks
Shirley

--
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/9] rbtree: add __rb_change_child() helper function

[Andrew Morton]

On Mon, 20 Aug 2012 15:05:24 -0700
Michel Lespinasse  wrote:

> Add __rb_change_child() as an inline helper function to replace code that
> would otherwise be duplicated 4 times in the source.
> 
> No changes to binary size or speed.
> 
> ...
>
> --- a/lib/rbtree.c
> +++ b/lib/rbtree.c
> @@ -66,6 +66,19 @@ static inline struct rb_node *rb_red_parent(struct rb_node 
> *red)
>   return (struct rb_node *)red->__rb_parent_color;
>  }
>  
> +static inline void
> +__rb_change_child(struct rb_node *old, struct rb_node *new,
> +   struct rb_node *parent, struct rb_root *root)
> +{
> + if (parent) {
> + if (parent->rb_left == old)
> + parent->rb_left = new;
> + else
> + parent->rb_right = new;
> + } else
> + root->rb_node = new;
> +}

I'm inclined to agree with Peter here - "inline" is now a vague,
pathetic and useless thing.  The problem is that the reader just
doesn't *know* whether or not the writer really wanted it to be
inlined.

If we have carefully made a decision to inline a function, we should
(now) use __always_inline.

If we have carefully made a decision to not inline a function, we
should use noinline.

If we don't care, we should omit all such markings.

This leaves no place for "inline"?


Marking it noinline shrinks the text by 60-odd bytes.  Given the number
of args, my gut feel is that this will be slower, despite the cache
benefit.  But that might be wrong.

--
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 Mon, Aug 20, 2012 at 10:10 AM, Bjorn Helgaas  wrote:

> So I'll try pulling your branch (I'll do something about the tsi721.c
> stuff myself).

I pulled this into
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
pci/jiang-pcie-cap with the following changes:

  - Dropped some "pci_" prefixes on internal functions in access.c
  - Minor restructure of pcie_capability_read_*()
  - Removed export of pcie_capability_reg_implemented()
  - Reworked reset_intel_82599_sfp_virtfn() to check for FLR bit in
DEVCAP rather than using pcie_capability_reg_implemented()
  - Split driver patches into one driver per patch
  - Fixed myri10ge_toggle_relaxed() -- previous code returned useful
value, but your patch made it always return zero
  - Use 16-bit, not 32-bit, accesses for DEVCTL, DEVCTL2 (tsi721)

I am still concerned about reset_intel_82599_sfp_virtfn().  It looks
wrong and possibly unnecessary.  It looks wrong because it sets
PCI_EXP_DEVCTL_BCR_FLR and blindly clears all other bits in
PCI_EXP_DEVCTL.  Most of the bits are probably cleared by the FLR
anyway, but Aux Power PM Enable is RWS ("sticky"), so it is *not*
modified by FLR.  Therefore, using reset_intel_82599_sfp_virtfn() has
the probably unintended side effect of clearing Aux Power PM Enable.

It looks possibly unnecessary because the generic pcie_flr() does
essentially the same thing, so it's not clear why we need a special
case for 82599.

Yu or Dexuan, can you comment on these 82599 questions?

The proposed new code is here:
http://git.kernel.org/?p=linux/kernel/git/helgaas/pci.git;a=blob;f=drivers/pci/quirks.c;h=9abbf56e93fe5c98364a7dfe2b0b724047dfa4a9;hb=ef529bf0cb5606ff5bd1422d2d2700a821d8218b#l3082

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: [RFC][PATCH v2 1/3] efivars: Disable external interrupt while holding efivars->lock

[Seiji Aguchi]

> -Original Message-
> From: Mike Waychison [mailto:mi...@google.com]
> Sent: Monday, August 20, 2012 3:17 PM
> To: Seiji Aguchi
> Cc: linux-kernel@vger.kernel.org; Luck, Tony (tony.l...@intel.com); Matthew 
> Garrett (m...@redhat.com); dzic...@redhat.com; dle-
> deve...@lists.sourceforge.net; Satoru Moriya
> Subject: Re: [RFC][PATCH v2 1/3] efivars: Disable external interrupt while 
> holding efivars->lock
> 
> Acked-by: Mike Waychison 
> 
> > @@ -1101,11 +1107,12 @@ out_free:
> >  void unregister_efivars(struct efivars *efivars)  {
> > struct efivar_entry *entry, *n;
> > +   unsigned long flags;
> >
> > list_for_each_entry_safe(entry, n, >list, list) {
> > -   spin_lock(>lock);
> > +   spin_lock_irqsave(>lock, flags);
> > list_del(>list);
> > -   spin_unlock(>lock);
> > +   spin_unlock_irqrestore(>lock, flags);
> > efivar_unregister(entry);
> > }
> > if (efivars->new_var)
> 
> Feel free to remove any other uses of flags where you know that you
> are being called from process context.

OK. I will remove the flags from unregister_efivars(), efivar_store_raw(), 
efivar_create() and efivar_delete().

If I'm missing something, please let me know.

Seiji


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

[PATCH v3 1/9] rbtree test: fix sparse warning about 64-bit constant

[Michel Lespinasse]

Just a small fix to make sparse happy.

Signed-off-by: Michel Lespinasse 
Reported-by: Fengguang Wu 
Acked-by: Rik van Riel 

---
 lib/rbtree_test.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 19dfca9ff7d7..fd09465d82ca 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -88,7 +88,7 @@ static int rbtree_test_init(void)
 
printk(KERN_ALERT "rbtree testing");
 
-   prandom32_seed(, 3141592653589793238);
+   prandom32_seed(, 3141592653589793238ULL);
init();
 
time1 = get_cycles();
-- 
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 v3 3/9] rbtree: place easiest case first in rb_erase()

[Michel Lespinasse]

In rb_erase, move the easy case (node to erase has no more than
1 child) first. I feel the code reads easier that way.

Signed-off-by: Michel Lespinasse 
Reviewed-by: Rik van Riel 

---
 lib/rbtree.c |   35 ++-
 1 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/lib/rbtree.c b/lib/rbtree.c
index de89a614b1ba..bde1b5c5fb33 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -368,17 +368,28 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
 
 void rb_erase(struct rb_node *node, struct rb_root *root)
 {
-   struct rb_node *child, *parent;
+   struct rb_node *child = node->rb_right, *tmp = node->rb_left;
+   struct rb_node *parent;
int color;
 
-   if (!node->rb_left)
-   child = node->rb_right;
-   else if (!node->rb_right)
-   child = node->rb_left;
-   else {
+   if (!tmp) {
+   case1:
+   /* Case 1: node to erase has no more than 1 child (easy!) */
+
+   parent = rb_parent(node);
+   color = rb_color(node);
+
+   if (child)
+   rb_set_parent(child, parent);
+   __rb_change_child(node, child, parent, root);
+   } else if (!child) {
+   /* Still case 1, but this time the child is node->rb_left */
+   child = tmp;
+   goto case1;
+   } else {
struct rb_node *old = node, *left;
 
-   node = node->rb_right;
+   node = child;
while ((left = node->rb_left) != NULL)
node = left;
 
@@ -402,18 +413,8 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
node->__rb_parent_color = old->__rb_parent_color;
node->rb_left = old->rb_left;
rb_set_parent(old->rb_left, node);
-
-   goto color;
}
 
-   parent = rb_parent(node);
-   color = rb_color(node);
-
-   if (child)
-   rb_set_parent(child, parent);
-   __rb_change_child(node, child, parent, root);
-
-color:
if (color == RB_BLACK)
__rb_erase_color(child, parent, root);
 }
-- 
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 v3 4/9] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

[Michel Lespinasse]

An interesting observation for rb_erase() is that when a node has
exactly one child, the node must be black and the child must be red.
An interesting consequence is that removing such a node can be done by
simply replacing it with its child and making the child black,
which we can do efficiently in rb_erase(). __rb_erase_color() then
only needs to handle the no-childs case and can be modified accordingly.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 

---
 lib/rbtree.c |  105 ++
 1 files changed, 62 insertions(+), 43 deletions(-)

diff --git a/lib/rbtree.c b/lib/rbtree.c
index bde1b5c5fb33..80b092538fa9 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -2,7 +2,8 @@
   Red Black Trees
   (C) 1999  Andrea Arcangeli 
   (C) 2002  David Woodhouse 
-  
+  (C) 2012  Michel Lespinasse 
+
   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 of the License, or
@@ -50,6 +51,11 @@
 #define rb_is_red(r)   (!rb_color(r))
 #define rb_is_black(r) rb_color(r)
 
+static inline void rb_set_black(struct rb_node *rb)
+{
+   rb->__rb_parent_color |= RB_BLACK;
+}
+
 static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
 {
rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
@@ -214,27 +220,18 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 }
 EXPORT_SYMBOL(rb_insert_color);
 
-static void __rb_erase_color(struct rb_node *node, struct rb_node *parent,
-struct rb_root *root)
+static void __rb_erase_color(struct rb_node *parent, struct rb_root *root)
 {
-   struct rb_node *sibling, *tmp1, *tmp2;
+   struct rb_node *node = NULL, *sibling, *tmp1, *tmp2;
 
while (true) {
/*
-* Loop invariant: all leaf paths going through node have a
-* black node count that is 1 lower than other leaf paths.
-*
-* If node is red, we can flip it to black to adjust.
-* If node is the root, all leaf paths go through it.
-* Otherwise, we need to adjust the tree through color flips
-* and tree rotations as per one of the 4 cases below.
+* Loop invariants:
+* - node is black (or NULL on first iteration)
+* - node is not the root (parent is not NULL)
+* - All leaf paths going through parent and node have a
+*   black node count that is 1 lower than other leaf paths.
 */
-   if (node && rb_is_red(node)) {
-   rb_set_parent_color(node, parent, RB_BLACK);
-   break;
-   } else if (!parent) {
-   break;
-   }
sibling = parent->rb_right;
if (node != sibling) {  /* node == parent->rb_left */
if (rb_is_red(sibling)) {
@@ -268,17 +265,22 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
 *  / \   / \
 * Sl  SrSl  Sr
 *
-* This leaves us violating 5), so
-* recurse at p. If p is red, the
-* recursion will just flip it to black
-* and exit. If coming from Case 1,
-* p is known to be red.
+* This leaves us violating 5) which
+* can be fixed by flipping p to black
+* if it was red, or by recursing at p.
+* p is red when coming from Case 1.
 */
rb_set_parent_color(sibling, parent,
RB_RED);
-   node = parent;
-   parent = rb_parent(node);
-   continue;
+   if (rb_is_red(parent))
+   rb_set_black(parent);
+   else {
+   node = parent;
+   parent = rb_parent(node);
+   if (parent)
+   continue;
+   }
+   break;
}

[PATCH v3 7/9] rbtree: faster augmented rbtree manipulation

[Michel Lespinasse]

Introduce new augmented rbtree APIs that allow minimal recalculation of
augmented node information.

A new callback is added to the rbtree insertion and erase rebalancing
functions, to be called on each tree rotations. Such rotations preserve
the subtree's root augmented value, but require recalculation of the one
child that was previously located at the subtree root.

In the insertion case, the handcoded search phase must be updated to
maintain the augmented information on insertion, and then the rbtree
coloring/rebalancing algorithms keep it up to date.

In the erase case, things are more complicated since it is library
code that manipulates the rbtree in order to remove internal nodes.
This requires a couple additional callbacks to copy a subtree's
augmented value when a new root is stitched in, and to recompute
augmented values down the ancestry path when a node is removed from
the tree.

In order to preserve maximum speed for the non-augmented case,
we provide two versions of each tree manipulation function.
rb_insert_augmented() is the augmented equivalent of rb_insert_color(),
and rb_erase_augmented() is the augmented equivalent of rb_erase().

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 

---
 Documentation/rbtree.txt |  190 ++
 include/linux/rbtree.h   |   19 +
 lib/rbtree.c |   83 ++--
 lib/rbtree_test.c|   58 +++
 4 files changed, 296 insertions(+), 54 deletions(-)

diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt
index 8d32d85a5234..0a0b6dce3e08 100644
--- a/Documentation/rbtree.txt
+++ b/Documentation/rbtree.txt
@@ -193,24 +193,42 @@ Example:
 Support for Augmented rbtrees
 -
 
-Augmented rbtree is an rbtree with "some" additional data stored in each node.
-This data can be used to augment some new functionality to rbtree.
-Augmented rbtree is an optional feature built on top of basic rbtree
-infrastructure. An rbtree user who wants this feature will have to call the
-augmentation functions with the user provided augmentation callback
-when inserting and erasing nodes.
+Augmented rbtree is an rbtree with "some" additional data stored in
+each node, where the additional data for node N must be a function of
+the contents of all nodes in the subtree rooted at N. This data can
+be used to augment some new functionality to rbtree. Augmented rbtree
+is an optional feature built on top of basic rbtree infrastructure.
+An rbtree user who wants this feature will have to call the augmentation
+functions with the user provided augmentation callback when inserting
+and erasing nodes.
 
-On insertion, the user must call rb_augment_insert() once the new node is in
-place. This will cause the augmentation function callback to be called for
-each node between the new node and the root which has been affected by the
-insertion.
+On insertion, the user must update the augmented information on the path
+leading to the inserted node, then call rb_link_node() as usual and
+rb_augment_inserted() instead of the usual rb_insert_color() call.
+If rb_augment_inserted() rebalances the rbtree, it will callback into
+a user provided function to update the augmented information on the
+affected subtrees.
 
-When erasing a node, the user must call rb_augment_erase_begin() first to
-retrieve the deepest node on the rebalance path. Then, after erasing the
-original node, the user must call rb_augment_erase_end() with the deepest
-node found earlier. This will cause the augmentation function to be called
-for each affected node between the deepest node and the root.
+When erasing a node, the user must call rb_erase_augmented() instead of
+rb_erase(). rb_erase_augmented() calls back into user provided functions
+to updated the augmented information on affected subtrees.
 
+In both cases, the callbacks are provided through struct rb_augment_callbacks.
+3 callbacks must be defined:
+
+- A propagation callback, which updates the augmented value for a given
+  node and its ancestors, up to a given stop point (or NULL to update
+  all the way to the root).
+
+- A copy callback, which copies the augmented value for a given subtree
+  to a newly assigned subtree root.
+
+- A tree rotation callback, which copies the augmented value for a given
+  subtree to a newly assigned subtree root AND recomputes the augmented
+  information for the former subtree root.
+
+
+Sample usage:
 
 Interval tree is an example of augmented rb tree. Reference -
 "Introduction to Algorithms" by Cormen, Leiserson, Rivest and Stein.
@@ -230,26 +248,132 @@ and its immediate children. And this will be used in 
O(log n) lookup
 for lowest match (lowest start address among all possible matches)
 with something like:
 
-find_lowest_match(lo, hi, node)
+struct interval_tree_node *
+interval_tree_first_match(struct rb_root *root,
+ unsigned long start, unsigned long last)
 {
-   

[PATCH v3 8/9] rbtree: remove prior augmented rbtree implementation

[Michel Lespinasse]

convert arch/x86/mm/pat_rbtree.c to the proposed augmented rbtree api
and remove the old augmented rbtree implementation.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 

---
 arch/x86/mm/pat_rbtree.c |   65 +
 include/linux/rbtree.h   |8 -
 lib/rbtree.c |   71 --
 3 files changed, 46 insertions(+), 98 deletions(-)

diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 8acaddd0fb21..7e1515bd4770 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -54,29 +54,57 @@ static u64 get_subtree_max_end(struct rb_node *node)
return ret;
 }
 
-/* Update 'subtree_max_end' for a node, based on node and its children */
-static void memtype_rb_augment_cb(struct rb_node *node, void *__unused)
+static u64 compute_subtree_max_end(struct memtype *data)
 {
-   struct memtype *data;
-   u64 max_end, child_max_end;
-
-   if (!node)
-   return;
-
-   data = container_of(node, struct memtype, rb);
-   max_end = data->end;
+   u64 max_end = data->end, child_max_end;
 
-   child_max_end = get_subtree_max_end(node->rb_right);
+   child_max_end = get_subtree_max_end(data->rb.rb_right);
if (child_max_end > max_end)
max_end = child_max_end;
 
-   child_max_end = get_subtree_max_end(node->rb_left);
+   child_max_end = get_subtree_max_end(data->rb.rb_left);
if (child_max_end > max_end)
max_end = child_max_end;
 
-   data->subtree_max_end = max_end;
+   return max_end;
+}
+
+/* Update 'subtree_max_end' for node and its parents */
+static void memtype_rb_propagate_cb(struct rb_node *node, struct rb_node *stop)
+{
+   while (node != stop) {
+   struct memtype *data = container_of(node, struct memtype, rb);
+   u64 subtree_max_end = compute_subtree_max_end(data);
+   if (data->subtree_max_end == subtree_max_end)
+   break;
+   data->subtree_max_end = subtree_max_end;
+   node = rb_parent(>rb);
+   }
+}
+
+static void memtype_rb_copy_cb(struct rb_node *old, struct rb_node *new)
+{
+   struct memtype *old_data = container_of(old, struct memtype, rb);
+   struct memtype *new_data = container_of(new, struct memtype, rb);
+
+   new_data->subtree_max_end = old_data->subtree_max_end;
 }
 
+/* Update 'subtree_max_end' after tree rotation. old and new are the
+ * former and current subtree roots */
+static void memtype_rb_rotate_cb(struct rb_node *old, struct rb_node *new)
+{
+   struct memtype *old_data = container_of(old, struct memtype, rb);
+   struct memtype *new_data = container_of(new, struct memtype, rb);
+
+   new_data->subtree_max_end = old_data->subtree_max_end;
+   old_data->subtree_max_end = compute_subtree_max_end(old_data);
+}
+
+static const struct rb_augment_callbacks memtype_rb_augment_cb = {
+   memtype_rb_propagate_cb, memtype_rb_copy_cb, memtype_rb_rotate_cb
+};
+
 /* Find the first (lowest start addr) overlapping range from rb tree */
 static struct memtype *memtype_rb_lowest_match(struct rb_root *root,
u64 start, u64 end)
@@ -179,15 +207,17 @@ static void memtype_rb_insert(struct rb_root *root, 
struct memtype *newdata)
struct memtype *data = container_of(*node, struct memtype, rb);
 
parent = *node;
+   if (data->subtree_max_end < newdata->end)
+   data->subtree_max_end = newdata->end;
if (newdata->start <= data->start)
node = &((*node)->rb_left);
else if (newdata->start > data->start)
node = &((*node)->rb_right);
}
 
+   newdata->subtree_max_end = newdata->end;
rb_link_node(>rb, parent, node);
-   rb_insert_color(>rb, root);
-   rb_augment_insert(>rb, memtype_rb_augment_cb, NULL);
+   rb_insert_augmented(>rb, root, _rb_augment_cb);
 }
 
 int rbt_memtype_check_insert(struct memtype *new, unsigned long *ret_type)
@@ -209,16 +239,13 @@ int rbt_memtype_check_insert(struct memtype *new, 
unsigned long *ret_type)
 
 struct memtype *rbt_memtype_erase(u64 start, u64 end)
 {
-   struct rb_node *deepest;
struct memtype *data;
 
data = memtype_rb_exact_match(_rbroot, start, end);
if (!data)
goto out;
 
-   deepest = rb_augment_erase_begin(>rb);
-   rb_erase(>rb, _rbroot);
-   rb_augment_erase_end(deepest, memtype_rb_augment_cb, NULL);
+   rb_erase_augmented(>rb, _rbroot, _rb_augment_cb);
 out:
return data;
 }
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index c902eb9d6506..4ace31b33380 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -80,14 +80,6 @@ rb_insert_augmented(struct rb_node *node, struct rb_root 
*root,
 }
 
 
-typedef void 

[PATCH v3 9/9] rbtree: add RB_DECLARE_CALLBACKS() macro

[Michel Lespinasse]

As proposed by Peter Zijlstra, this makes it easier to define the augmented
rbtree callbacks.

Signed-off-by: Michel Lespinasse 

---
 arch/x86/mm/pat_rbtree.c |   37 ++---
 include/linux/rbtree.h   |   30 ++
 lib/rbtree_test.c|   34 ++
 3 files changed, 34 insertions(+), 67 deletions(-)

diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
index 7e1515bd4770..4d116959075d 100644
--- a/arch/x86/mm/pat_rbtree.c
+++ b/arch/x86/mm/pat_rbtree.c
@@ -69,41 +69,8 @@ static u64 compute_subtree_max_end(struct memtype *data)
return max_end;
 }
 
-/* Update 'subtree_max_end' for node and its parents */
-static void memtype_rb_propagate_cb(struct rb_node *node, struct rb_node *stop)
-{
-   while (node != stop) {
-   struct memtype *data = container_of(node, struct memtype, rb);
-   u64 subtree_max_end = compute_subtree_max_end(data);
-   if (data->subtree_max_end == subtree_max_end)
-   break;
-   data->subtree_max_end = subtree_max_end;
-   node = rb_parent(>rb);
-   }
-}
-
-static void memtype_rb_copy_cb(struct rb_node *old, struct rb_node *new)
-{
-   struct memtype *old_data = container_of(old, struct memtype, rb);
-   struct memtype *new_data = container_of(new, struct memtype, rb);
-
-   new_data->subtree_max_end = old_data->subtree_max_end;
-}
-
-/* Update 'subtree_max_end' after tree rotation. old and new are the
- * former and current subtree roots */
-static void memtype_rb_rotate_cb(struct rb_node *old, struct rb_node *new)
-{
-   struct memtype *old_data = container_of(old, struct memtype, rb);
-   struct memtype *new_data = container_of(new, struct memtype, rb);
-
-   new_data->subtree_max_end = old_data->subtree_max_end;
-   old_data->subtree_max_end = compute_subtree_max_end(old_data);
-}
-
-static const struct rb_augment_callbacks memtype_rb_augment_cb = {
-   memtype_rb_propagate_cb, memtype_rb_copy_cb, memtype_rb_rotate_cb
-};
+RB_DECLARE_CALLBACKS(static, memtype_rb_augment_cb, struct memtype, rb,
+u64, subtree_max_end, compute_subtree_max_end)
 
 /* Find the first (lowest start addr) overlapping range from rb tree */
 static struct memtype *memtype_rb_lowest_match(struct rb_root *root,
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 4ace31b33380..8d1e83b1c87b 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -79,6 +79,36 @@ rb_insert_augmented(struct rb_node *node, struct rb_root 
*root,
__rb_insert_augmented(node, root, augment->rotate);
 }
 
+#define RB_DECLARE_CALLBACKS(rbstatic, rbname, rbstruct, rbfield,\
+rbtype, rbaugmented, rbcompute)  \
+static void rbname ## _propagate(struct rb_node *rb, struct rb_node *stop)\
+{\
+   while (rb != stop) {  \
+   rbstruct *node = rb_entry(rb, rbstruct, rbfield); \
+   rbtype augmented = rbcompute(node);   \
+   if (node->rbaugmented == augmented)   \
+   break;\
+   node->rbaugmented = augmented;\
+   rb = rb_parent(>rbfield);   \
+   } \
+}\
+static void rbname ## _copy(struct rb_node *rb_old, struct rb_node *rb_new)   \
+{\
+   rbstruct *old = rb_entry(rb_old, rbstruct, rbfield);  \
+   rbstruct *new = rb_entry(rb_new, rbstruct, rbfield);  \
+   new->rbaugmented = old->rbaugmented;  \
+}\
+static void rbname ## _rotate(struct rb_node *rb_old, struct rb_node *rb_new) \
+{\
+   rbstruct *old = rb_entry(rb_old, rbstruct, rbfield);  \
+   rbstruct *new = rb_entry(rb_new, rbstruct, rbfield);  \
+   new->rbaugmented = old->rbaugmented;  \
+   old->rbaugmented = rbcompute(old);\
+}\
+rbstatic const struct rb_augment_callbacks rbname = {\
+   rbname ## _propagate, rbname ## _copy, rbname ## _rotate  \
+};
+
 
 /* Find logical next and previous nodes in a tree */
 

[PATCH v3 6/9] rbtree: augmented rbtree test

[Michel Lespinasse]

Small test to measure the performance of augmented rbtrees.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 

---
 lib/rbtree_test.c |  103 +++-
 1 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index fd09465d82ca..66e41d4bfc39 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -10,6 +10,10 @@
 struct test_node {
struct rb_node rb;
u32 key;
+
+   /* following fields used for testing augmented rbtree functionality */
+   u32 val;
+   u32 augmented;
 };
 
 static struct rb_root root = RB_ROOT;
@@ -20,10 +24,11 @@ static struct rnd_state rnd;
 static void insert(struct test_node *node, struct rb_root *root)
 {
struct rb_node **new = >rb_node, *parent = NULL;
+   u32 key = node->key;
 
while (*new) {
parent = *new;
-   if (node->key < rb_entry(parent, struct test_node, rb)->key)
+   if (key < rb_entry(parent, struct test_node, rb)->key)
new = >rb_left;
else
new = >rb_right;
@@ -38,11 +43,62 @@ static inline void erase(struct test_node *node, struct 
rb_root *root)
rb_erase(>rb, root);
 }
 
+static inline u32 augment_recompute(struct test_node *node)
+{
+   u32 max = node->val, child_augmented;
+   if (node->rb.rb_left) {
+   child_augmented = rb_entry(node->rb.rb_left, struct test_node,
+  rb)->augmented;
+   if (max < child_augmented)
+   max = child_augmented;
+   }
+   if (node->rb.rb_right) {
+   child_augmented = rb_entry(node->rb.rb_right, struct test_node,
+  rb)->augmented;
+   if (max < child_augmented)
+   max = child_augmented;
+   }
+   return max;
+}
+
+static void augment_callback(struct rb_node *rb, void *unused)
+{
+   struct test_node *node = rb_entry(rb, struct test_node, rb);
+   node->augmented = augment_recompute(node);
+}
+
+static void insert_augmented(struct test_node *node, struct rb_root *root)
+{
+   struct rb_node **new = >rb_node, *parent = NULL;
+   u32 key = node->key;
+
+   while (*new) {
+   parent = *new;
+   if (key < rb_entry(parent, struct test_node, rb)->key)
+   new = >rb_left;
+   else
+   new = >rb_right;
+   }
+
+   rb_link_node(>rb, parent, new);
+   rb_insert_color(>rb, root);
+   rb_augment_insert(>rb, augment_callback, NULL);
+}
+
+static void erase_augmented(struct test_node *node, struct rb_root *root)
+{
+   struct rb_node *deepest = rb_augment_erase_begin(>rb);
+   rb_erase(>rb, root);
+   rb_augment_erase_end(deepest, augment_callback, NULL);
+}
+
 static void init(void)
 {
int i;
-   for (i = 0; i < NODES; i++)
+   for (i = 0; i < NODES; i++) {
nodes[i].key = prandom32();
+   nodes[i].val = prandom32();
+   }
 }
 
 static bool is_red(struct rb_node *rb)
@@ -81,6 +137,17 @@ static void check(int nr_nodes)
WARN_ON_ONCE(count != nr_nodes);
 }
 
+static void check_augmented(int nr_nodes)
+{
+   struct rb_node *rb;
+
+   check(nr_nodes);
+   for (rb = rb_first(); rb; rb = rb_next(rb)) {
+   struct test_node *node = rb_entry(rb, struct test_node, rb);
+   WARN_ON_ONCE(node->augmented != augment_recompute(node));
+   }
+}
+
 static int rbtree_test_init(void)
 {
int i, j;
@@ -119,6 +186,38 @@ static int rbtree_test_init(void)
check(0);
}
 
+   printk(KERN_ALERT "augmented rbtree testing");
+
+   init();
+
+   time1 = get_cycles();
+
+   for (i = 0; i < PERF_LOOPS; i++) {
+   for (j = 0; j < NODES; j++)
+   insert_augmented(nodes + j, );
+   for (j = 0; j < NODES; j++)
+   erase_augmented(nodes + j, );
+   }
+
+   time2 = get_cycles();
+   time = time2 - time1;
+
+   time = div_u64(time, PERF_LOOPS);
+   printk(" -> %llu cycles\n", (unsigned long long)time);
+
+   for (i = 0; i < CHECK_LOOPS; i++) {
+   init();
+   for (j = 0; j < NODES; j++) {
+   check_augmented(j);
+   insert_augmented(nodes + j, );
+   }
+   for (j = 0; j < NODES; j++) {
+   check_augmented(NODES - j);
+   erase_augmented(nodes + j, );
+   }
+   check_augmented(0);
+   }
+
return -EAGAIN; /* Fail will directly unload the module */
 }
 
-- 
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 v3 5/9] rbtree: low level optimizations in rb_erase()

[Michel Lespinasse]

Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
  and color information (possibly not in close sequence, as there might
  be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field from
  the erased node to the child instead of recomputing it from the desired
  parent and color
- When searching for the erased node's successor, differentiate between
  cases 2 and 3 based on whether any left links were followed. This avoids
  a condition later down.
- In case 3, keep a pointer to the erased node's right child so we don't
  have to refetch it later to adjust its parent.
- In the no-childs subcase of cases 2 and 3, place the rebalance assigment
  last so that the compiler can remove the following if(rebalance) test.

Also, added some comments to illustrate cases 2 and 3.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 

---
 lib/rbtree.c |   98 ++
 1 files changed, 64 insertions(+), 34 deletions(-)

diff --git a/lib/rbtree.c b/lib/rbtree.c
index 80b092538fa9..938061ecbe61 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -47,9 +47,14 @@
 #defineRB_RED  0
 #defineRB_BLACK1
 
-#define rb_color(r)   ((r)->__rb_parent_color & 1)
-#define rb_is_red(r)   (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
+#define __rb_parent(pc)((struct rb_node *)(pc & ~3))
+
+#define __rb_color(pc) ((pc) & 1)
+#define __rb_is_black(pc)  __rb_color(pc)
+#define __rb_is_red(pc)(!__rb_color(pc))
+#define rb_color(rb)   __rb_color((rb)->__rb_parent_color)
+#define rb_is_red(rb)  __rb_is_red((rb)->__rb_parent_color)
+#define rb_is_black(rb)__rb_is_black((rb)->__rb_parent_color)
 
 static inline void rb_set_black(struct rb_node *rb)
 {
@@ -378,6 +383,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 {
struct rb_node *child = node->rb_right, *tmp = node->rb_left;
struct rb_node *parent, *rebalance;
+   unsigned long pc;
 
if (!tmp) {
/*
@@ -387,51 +393,75 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 * and node must be black due to 4). We adjust colors locally
 * so as to bypass __rb_erase_color() later on.
 */
-
-   parent = rb_parent(node);
+   pc = node->__rb_parent_color;
+   parent = __rb_parent(pc);
__rb_change_child(node, child, parent, root);
if (child) {
-   rb_set_parent_color(child, parent, RB_BLACK);
+   child->__rb_parent_color = pc;
rebalance = NULL;
-   } else {
-   rebalance = rb_is_black(node) ? parent : NULL;
-   }
+   } else
+   rebalance = __rb_is_black(pc) ? parent : NULL;
} else if (!child) {
/* Still case 1, but this time the child is node->rb_left */
-   parent = rb_parent(node);
+   tmp->__rb_parent_color = pc = node->__rb_parent_color;
+   parent = __rb_parent(pc);
__rb_change_child(node, tmp, parent, root);
-   rb_set_parent_color(tmp, parent, RB_BLACK);
rebalance = NULL;
} else {
-   struct rb_node *old = node, *left;
-
-   node = child;
-   while ((left = node->rb_left) != NULL)
-   node = left;
-
-   __rb_change_child(old, node, rb_parent(old), root);
-
-   child = node->rb_right;
-   parent = rb_parent(node);
-
-   if (parent == old) {
-   parent = node;
+   struct rb_node *successor = child, *child2;
+   tmp = child->rb_left;
+   if (!tmp) {
+   /*
+* Case 2: node's successor is its right child
+*
+*(n)  (s)
+*/ \  / \
+*  (x) (s)  ->  (x) (c)
+*\
+*(c)
+*/
+   parent = child;
+   child2 = child->rb_right;
} else {
-   parent->rb_left = child;
-
-   node->rb_right = old->rb_right;
-   rb_set_parent(old->rb_right, node);
+   /*
+* Case 3: node's successor is leftmost under
+* node's right child subtree
+*
+*(n)  (s)
+*/ \  / \
+*  (x) (y)  ->  (x) (y)
+*  //
+*(p)  

[PATCH v3 2/9] rbtree: add __rb_change_child() helper function

[Michel Lespinasse]

Add __rb_change_child() as an inline helper function to replace code that
would otherwise be duplicated 4 times in the source.

No changes to binary size or speed.

Signed-off-by: Michel Lespinasse 
Reviewed-by: Rik van Riel 

---
 lib/rbtree.c |   46 +-
 1 files changed, 17 insertions(+), 29 deletions(-)

diff --git a/lib/rbtree.c b/lib/rbtree.c
index 61cdd0e3e538..de89a614b1ba 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -66,6 +66,19 @@ static inline struct rb_node *rb_red_parent(struct rb_node 
*red)
return (struct rb_node *)red->__rb_parent_color;
 }
 
+static inline void
+__rb_change_child(struct rb_node *old, struct rb_node *new,
+ struct rb_node *parent, struct rb_root *root)
+{
+   if (parent) {
+   if (parent->rb_left == old)
+   parent->rb_left = new;
+   else
+   parent->rb_right = new;
+   } else
+   root->rb_node = new;
+}
+
 /*
  * Helper function for rotations:
  * - old's parent and color get assigned to new
@@ -78,13 +91,7 @@ __rb_rotate_set_parents(struct rb_node *old, struct rb_node 
*new,
struct rb_node *parent = rb_parent(old);
new->__rb_parent_color = old->__rb_parent_color;
rb_set_parent_color(old, new, color);
-   if (parent) {
-   if (parent->rb_left == old)
-   parent->rb_left = new;
-   else
-   parent->rb_right = new;
-   } else
-   root->rb_node = new;
+   __rb_change_child(old, new, parent, root);
 }
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
@@ -375,13 +382,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
while ((left = node->rb_left) != NULL)
node = left;
 
-   if (rb_parent(old)) {
-   if (rb_parent(old)->rb_left == old)
-   rb_parent(old)->rb_left = node;
-   else
-   rb_parent(old)->rb_right = node;
-   } else
-   root->rb_node = node;
+   __rb_change_child(old, node, rb_parent(old), root);
 
child = node->rb_right;
parent = rb_parent(node);
@@ -410,13 +411,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 
if (child)
rb_set_parent(child, parent);
-   if (parent) {
-   if (parent->rb_left == node)
-   parent->rb_left = child;
-   else
-   parent->rb_right = child;
-   } else
-   root->rb_node = child;
+   __rb_change_child(node, child, parent, root);
 
 color:
if (color == RB_BLACK)
@@ -591,14 +586,7 @@ void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
struct rb_node *parent = rb_parent(victim);
 
/* Set the surrounding nodes to point to the replacement */
-   if (parent) {
-   if (victim == parent->rb_left)
-   parent->rb_left = new;
-   else
-   parent->rb_right = new;
-   } else {
-   root->rb_node = new;
-   }
+   __rb_change_child(victim, new, parent, root);
if (victim->rb_left)
rb_set_parent(victim->rb_left, new);
if (victim->rb_right)
-- 
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 v3 0/9] faster augmented rbtree interface

[Michel Lespinasse]

These are my proposed changes for a faster augmented rbtree interface.

Patches 1-8 are unchanged from my v2 send (in v2 they were called
patches 1 and 3-9 - patch 2 from v2 already got applied into
andrew's -mm tree). Patch 9 wasn't part of the original v2 send,
I had posted it later on as a reply to v2's patch 8/9 following a suggestion
from Peter Zijlstra. Anyway, Andrew asked me to apply the patches over
his current tree, gather the Acked-By and Reviewed-By lines from the previous
send, and resend publically, so here goes.

As noted in v2:

Patch 1 is a trivial fix for a sparse warning.

Patches 2-3 are small cleanups, mainly intended to make the code more readable.

Patches 4-5 are new (well they were in v2), based on something George
Spelvin observed in my previous RFC. It turns out that in rb_erase(),
recoloring is trivial for nodes that have exactly 1 child. We can
shave a few cycles by handling it locally, and changing
rb_erase_color() to only deal with the no-childs case.

Patch 6 adds a performance test for the augmented rbtree support.

Patch 7 introduces my proposed API for augmented rbtree support.
rb_insert_augmented() and rb_erase_augmented() are augmented versions of
rb_insert_color() and rb_erase(). They take an additional argument
(struct rb_augment_callbacks) to specify callbacks to be used to maintain
the augmented rbtree information. users have to specify 3 callbacks
through that structure. Non-augmented rbtree support is provided by
inlining dummy callbacks, so that the non-augmented case is not affected
(either in speed or in compiled size) by the new augmented rbtree API.
For augmented rbtree users, no inlining takes place at this point (I may
propose this later, but feel this shouldn't go with the initial proposal).

Patch 8 removes the old augmented rbtree interface and converts its
only user to the new interface.

Patch 9 adds an RB_DECLARE_CALLBACKS() macro so that people don't have to
write the 3 small callback functions for each augmented rbtree usage.


Overall, this series improves non-augmented rbtree speed by ~5%. For
augmented rbtree users, the new interface is ~2.5 times faster than the old.

Michel Lespinasse (9):
  rbtree test: fix sparse warning about 64-bit constant
  rbtree: add __rb_change_child() helper function
  rbtree: place easiest case first in rb_erase()
  rbtree: handle 1-child recoloring in rb_erase() instead of
rb_erase_color()
  rbtree: low level optimizations in rb_erase()
  rbtree: augmented rbtree test
  rbtree: faster augmented rbtree manipulation
  rbtree: remove prior augmented rbtree implementation
  rbtree: add RB_DECLARE_CALLBACKS() macro

 Documentation/rbtree.txt |  190 +-
 arch/x86/mm/pat_rbtree.c |   32 ++---
 include/linux/rbtree.h   |   53 ++-
 lib/rbtree.c |  352 +-
 lib/rbtree_test.c|  105 +-
 5 files changed, 513 insertions(+), 219 deletions(-)

-- 
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 3/3] staging: comedi: comedi_test: convert attach message to dev_info

[H Hartley Sweeten]

Convert the 'attach' message from a printk to a dev_info.

Signed-off-by: H Hartley Sweeten 
Cc: Ian Abbott 
Cc: Greg Kroah-Hartman 
---
 drivers/staging/comedi/drivers/comedi_test.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/comedi_test.c 
b/drivers/staging/comedi/drivers/comedi_test.c
index 6864716..8ea9202 100644
--- a/drivers/staging/comedi/drivers/comedi_test.c
+++ b/drivers/staging/comedi/drivers/comedi_test.c
@@ -489,10 +489,12 @@ static int waveform_attach(struct comedi_device *dev,
devpriv->timer.function = waveform_ai_interrupt;
devpriv->timer.data = (unsigned long)dev;
 
-   printk(KERN_INFO "comedi%d: comedi_test: "
-  "%i microvolt, %li microsecond waveform attached\n", dev->minor,
-  devpriv->uvolt_amplitude, devpriv->usec_period);
-   return 1;
+   dev_info(dev->class_dev,
+   "%s: %i microvolt, %li microsecond waveform attached\n",
+   dev->board_name,
+   devpriv->uvolt_amplitude, devpriv->usec_period);
+
+   return 0;
 }
 
 static void waveform_detach(struct comedi_device *dev)
-- 
1.7.11

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