[PATCH v2] checkpatch: Warn on unnecessary line continuations

[Joe Perches]

When the previous line is not a line continuation and the
current line has a line continuation but is not a #define,
emit a warning.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f18750e..d4f61a6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3013,6 +3013,15 @@ sub process {
  "Macros with complex values 
should be enclosed in parenthesis\n" . "$herectx");
}
}
+
+# check for line continuations outside of #defines
+
+   } else {
+   if ($prevline !~ /^..*\\$/ &&
+   $line =~ /^\+.*\\$/) {
+   WARN("LINE_CONTINUATIONS",
+"Avoid unnecessary line continuations\n" . 
$herecurr);
+   }
}
 
 # do {} while (0) macro tests:


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ext4: fix unjournaled inode bitmap modification

[Eric Sandeen]

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed
ext4_new_inode() such that the inode bitmap was being modified
outside a transaction, which could lead to corruption, and was
discovered when journal_checksum found a bad checksum in the
journal during log replay.

Nix ran into this when using the journal_async_commit mount
option, which enables journal checksumming.  The ensuing
journal replay failures due to the bad checksums led to
filesystem corruption reported as the now infamous
"Apparent serious progressive ext4 data corruption bug"

I've tested this by mounting with journal_checksum and
running fsstress then dropping power; I've also tested by
hacking DM to create snapshots w/o first quiescing, which
allows me to test journal replay repeatedly w/o actually
power-cycling the box.  Without the patch I hit a journal
checksum error every time.  With this fix it survives
many iterations.

Signed-off-by: Eric Sandeen 
cc: Nix 
---

A little more going on here to try to properly handle error
cases & moving to the next group; despite
ext4_handle_release_buffer being a no-op, I've tried
to sprinkle it in at the right places.  Double checking
on review is probably a fine idea ;)

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 4facdd2..1d18fba 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -706,10 +706,17 @@ got_group:
continue;
}
 
-   brelse(inode_bitmap_bh);
+   if (inode_bitmap_bh) {
+   ext4_handle_release_buffer(handle, inode_bitmap_bh);
+   brelse(inode_bitmap_bh);
+   }
inode_bitmap_bh = ext4_read_inode_bitmap(sb, group);
if (!inode_bitmap_bh)
goto fail;
+   BUFFER_TRACE(inode_bitmap_bh, "get_write_access");
+   err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
+   if (err)
+   goto fail;
 
 repeat_in_this_group:
ino = ext4_find_next_zero_bit((unsigned long *)
@@ -734,10 +741,16 @@ repeat_in_this_group:
if (ino < EXT4_INODES_PER_GROUP(sb))
goto repeat_in_this_group;
}
+   ext4_handle_release_buffer(handle, inode_bitmap_bh);
err = -ENOSPC;
goto out;
 
 got:
+   BUFFER_TRACE(inode_bitmap_bh, "call ext4_handle_dirty_metadata");
+   err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
+   if (err)
+   goto fail;
+
/* We may have to initialize the block bitmap if it isn't already */
if (ext4_has_group_desc_csum(sb) &&
gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
@@ -771,11 +784,6 @@ got:
goto fail;
}
 
-   BUFFER_TRACE(inode_bitmap_bh, "get_write_access");
-   err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
-   if (err)
-   goto fail;
-
BUFFER_TRACE(group_desc_bh, "get_write_access");
err = ext4_journal_get_write_access(handle, group_desc_bh);
if (err)
@@ -823,11 +831,6 @@ got:
}
ext4_unlock_group(sb, group);
 
-   BUFFER_TRACE(inode_bitmap_bh, "call ext4_handle_dirty_metadata");
-   err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
-   if (err)
-   goto fail;
-
BUFFER_TRACE(group_desc_bh, "call ext4_handle_dirty_metadata");
err = ext4_handle_dirty_metadata(handle, NULL, group_desc_bh);
if (err)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] exec: do not leave bprm->interp on stack

[Kees Cook]

On Sat, Oct 27, 2012 at 1:16 PM, P J P  wrote:
> +-- On Sat, 27 Oct 2012, Kees Cook wrote --+
> | Al showed a list of them earlier in the thread.
>
>   Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry.
> Do people still use - a.out - format? (considering ELF has been the default
> standard for so many years)

No one sane has CONFIG_BINFMT_AOUT any more. :)

> | I don't have any on the various distros I checked.
>
>   Same here, my F17 machine has no entries for binfmt- modules, in fact I
> don't even have the /etc/modprobe.d/aliases.conf file.
>
> Documentation/binfmt_misc.txt talks about executing Java, Python, DOSEMU and
> Windows programs which could be supported by loadable modules.

Right, but those are all registered from userspace and binfmt_misc
will catch them.

> | The problem I see here is that we only want to do module loading in the "no
> | match" case. But that means that either we need to restart with the original
> | bprm, or we need to keep bprm changes off the stack. Leading with a module
> | load is going to wreck performance.
>
>   I beg to *slightly* differ here. I agree we currently have a small overhead
> of find_module() -> request_module() only when binfmt_ module is already
> loaded, partly because find_module can not resolve aliases.

Al's point here is that non of the binfmts are named "binfmt-".
Those are only aliases, and those are only visible from userspace,
even after they're loaded, so the find_module() call in your example
will never match anything. Which means if there is a non-printable in
a binary, the kernel will exec modprobe even if there is already a
binfmt that will load it.

> I guess this small overhead is worth it if it helps to make things less
> confusing and easy to follow. Besides this overhead does not exist for regular
> executables ELFs and scripts alike.
>
> If the required module is missing, a call to request_module() will anyway
> happen and its cost remains the same whether it happens before or after the
> "match".

Well, we'll always do the modprobe call-out on a missing binfmt (so
for that reason I like the addition of the printk, though it should
probably be rate-limited), but we still need to only load modules at
fall-back time. Which means means we need to return from the recursive
loading attempt, which means we need to restart the bprm (slow) or we
need to do a heap alloc for the changed interp (less slow).

If we change binfmt_script to not make a recursive call, then we still
need to keep the interp change somewhere off the stack. I still think
my patchset is the least bad.

Al, do you have something else in mind?

-Kees

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

[PATCH]Documentation: Fixes a word in Documentation/arm64/memory.txt

[Tekkaman Ninja]

Fixes a term in Documentation/arm64/memory.txt
The modification is based on Catalin Marinas 's
suggestion:
"memory" in "ffc0  256GB memory"
should  be treated as "kernel logical memory map".

Signed-off-by: Fu Wei 

---
 Documentation/arm64/memory.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index dbbdcbb..2761652 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -41,7 +41,7 @@ ffbe  ffbffbff  ~8GB  
[guard, future vmmemap]
 
 ffbffc00   ffbf  64MB  modules
 
-ffc0    256GB  memory
+ffc0    256GB  kernel logical 
memory map
 
 
 Translation table lookup with 4KB pages:
-- 
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: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)

[Andi Kleen]

On Sun, Oct 28, 2012 at 04:17:00AM +0100, Wallak wrote:
> I've found where this issue come from. This behavior was introduced
> with the commit: 0cc15d03bcccdf95e2bd82e094e6064e61b54207.The
> description is available below. Removing this patch fix the drive
> order.

Hmm the patch should only affect the floppy. I don't see how it could 
affect anything else. Maybe it's just generic timing change
that disrupts your boot sequence (if that's the case something else
could have caused it too)

Maybe Arjan has an idea.

-Andi

> 
> 
> Best Regards,
> Wallak.
> 
> 
> commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207
> Author: Andi Kleen 
> Date:   Mon Jul 2 17:27:04 2012 -0700
> 
> floppy: Run floppy initialization asynchronous
> 
> floppy_init is quite slow, 3s on my test system to determine
> that there is no floppy. Run it asynchronous to the other
> init calls to improve boot time.
> 
> [jkos...@suse.cz: fix modular build]
> 
> Signed-off-by: Andi Kleen 
> Signed-off-by: Jiri Kosina 
> 
> 
> 
> 
> Wallak wrote:
> >Chris Friesen wrote:
> >>On 10/26/2012 01:43 PM, Wallak wrote:
> >>>Chris Friesen wrote:
> On 10/25/2012 04:49 PM, Wallak wrote:
> >I've a very annoying behavior with the linux-3.6.x kernels
> >release, and
> >a monolithic configuration. The USB 2.0 drives are mapped first with
> >/dev/sda, /dev/sdb... devices, and than the SATA AHCI
> >drives come after.
> >This is out of order with the BIOS configuration and breaks a program
> >like lilo. This is also annoying when we use a static
> >partition mapping.
> >
> >Linux-3.5 works fine. Where this bug come from ? Is this a
> >patch to get
> >the old, and classical behavior ?
> 
> As you have discovered it's fragile to rely on /dev/sd* names since a
> BIOS update, kernel update, or motherboard replacement could
> conceivably cause them to change.
> 
> Better to use something like partition labels that you control and
> that don't change.
> 
> Chris
> 
> >>>You are right, when we have a configuration with a lot of drvies and
> >>>adapters SATA, old SCSI,.. etc. the order may change. But having the
> >>>main SATA hard drive defined, as the BIOS boot device, behind external
> >>>and removable USB drives is in my opinion a bug.And may lead
> >>>to security
> >>>issues (drives with the same label, etc...).
> >>>
> >>>Using =LABEL, or =UUID with a bootloader like grub or lilo,
> >>>save the the
> >>>boot device mapped drive partition number , and so booting on an older
> >>>kernel like linux 3.5 will fail. If we remove the external USB drive,
> >>>the boot process will fail too...
> >>>
> >>>So such a bug have to be fix.
> >>
> >>If you specify "root=LABEL=" as part of the kernel boot
> >>args in grub does it not check the label at boot time?
> >
> >Using root=LABEL= or root=UUID= don't work on a plain kernel, this
> >feature may be handled by an initrd trick. Otherwise for all non
> >root partitions UUID= work fine.
> >Nevertheless not fixing this bug yields some other issues:  Using
> >lilo to launch a second OS (other= option) fail, the command try
> >to parse partitions available on /dev/sda, and miss the real main
> >HDD. Boot drive must be force with lilo options...
> >SATA drives have, most of the time, no reason to be behind USB
> >drives. If we want to get a reliable behavior: /dev/sda must be
> >mapped to the BIOS boot device. Using the same behavior as
> >linux-3.5 will be fine.
> >
> >Wallak.
> >
> >>
> >>Chris
> >>
> >
> 

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

Documentation: Fixes a term's translation in Documentation/zh_CN/arm64/memory.txt

[Tekkaman Ninja]

Fixes a term's translation in Documentation/zh_CN/arm64/memory.txt
The modification is based on Catalin Marinas 's
suggestion:
"memory" in "ffc0  256GB memory"
should  be treated as "kernel logical memory map",
so the translation should be "内核逻辑内存映射".

Signed-off-by: Fu Wei 

---
 Documentation/zh_CN/arm64/memory.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/zh_CN/arm64/memory.txt 
b/Documentation/zh_CN/arm64/memory.txt
index 83b5193..2a74499 100644
--- a/Documentation/zh_CN/arm64/memory.txt
+++ b/Documentation/zh_CN/arm64/memory.txt
@@ -61,7 +61,7 @@ ffbe  ffbffbff  ~8GB  
[防护页，未来用于 vmmemap]
 
 ffbffc00   ffbf  64MB  模块
 
-ffc0    256GB  内存空间
+ffc0    256GB  内核逻辑内存映射
 
 
 4KB 页大小的转换表查找：
-- 
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: Linix-3.6.3 sda, sdb drives in reverse order (with a USB 2.0 drives and a monolithic kernel configuration)

[Wallak]

I've found where this issue come from. This behavior was introduced with 
the commit: 0cc15d03bcccdf95e2bd82e094e6064e61b54207.The description is 
available below. Removing this patch fix the drive order.



Best Regards,
Wallak.


commit 0cc15d03bcccdf95e2bd82e094e6064e61b54207
Author: Andi Kleen 
Date:   Mon Jul 2 17:27:04 2012 -0700

floppy: Run floppy initialization asynchronous

floppy_init is quite slow, 3s on my test system to determine
that there is no floppy. Run it asynchronous to the other
init calls to improve boot time.

[jkos...@suse.cz: fix modular build]

Signed-off-by: Andi Kleen 
Signed-off-by: Jiri Kosina 




Wallak wrote:

Chris Friesen wrote:

On 10/26/2012 01:43 PM, Wallak wrote:

Chris Friesen wrote:

On 10/25/2012 04:49 PM, Wallak wrote:
I've a very annoying behavior with the linux-3.6.x kernels 
release, and

a monolithic configuration. The USB 2.0 drives are mapped first with
/dev/sda, /dev/sdb... devices, and than the SATA AHCI drives come 
after.

This is out of order with the BIOS configuration and breaks a program
like lilo. This is also annoying when we use a static partition 
mapping.


Linux-3.5 works fine. Where this bug come from ? Is this a patch 
to get

the old, and classical behavior ?


As you have discovered it's fragile to rely on /dev/sd* names since a
BIOS update, kernel update, or motherboard replacement could
conceivably cause them to change.

Better to use something like partition labels that you control and
that don't change.

Chris


You are right, when we have a configuration with a lot of drvies and
adapters SATA, old SCSI,.. etc. the order may change. But having the
main SATA hard drive defined, as the BIOS boot device, behind external
and removable USB drives is in my opinion a bug.And may lead to 
security

issues (drives with the same label, etc...).

Using =LABEL, or =UUID with a bootloader like grub or lilo, save the 
the

boot device mapped drive partition number , and so booting on an older
kernel like linux 3.5 will fail. If we remove the external USB drive,
the boot process will fail too...

So such a bug have to be fix.


If you specify "root=LABEL=" as part of the kernel boot args 
in grub does it not check the label at boot time?


Using root=LABEL= or root=UUID= don't work on a plain kernel, this 
feature may be handled by an initrd trick. Otherwise for all non root 
partitions UUID= work fine.
Nevertheless not fixing this bug yields some other issues:  Using lilo 
to launch a second OS (other= option) fail, the command try to parse 
partitions available on /dev/sda, and miss the real main HDD. Boot 
drive must be force with lilo options...
SATA drives have, most of the time, no reason to be behind USB drives. 
If we want to get a reliable behavior: /dev/sda must be mapped to the 
BIOS boot device. Using the same behavior as linux-3.5 will be fine.


Wallak.



Chris





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] r8169: Fix WoL on RTL8168d/8111d.

[Cyril Brulebois]

This regression was spotted between Debian squeeze and Debian wheezy
kernels (respectively based on 2.6.32 and 3.2). The fix was inspired
by , using
RTL_GIGA_MAC_VER_{25,26} for the RTL8168d/8111d chipset.

Probable regression from d4ed95d796e5126bba51466dc07e287cebc8bd19;
more chipsets are likely affected.

Tested on top of a 3.2.23 kernel.

Reported-by: Florent Fourcot 
Tested-by: Florent Fourcot 
Signed-off-by: Cyril Brulebois 
---
 drivers/net/ethernet/realtek/r8169.c |2 ++
 1 file changed, 2 insertions(+)


It looks like RTL_GIGA_MAC_VER_{25,26} are kinda supposed to go
together so I kept both. Florent's testing gave the following results:
 - RTL_GIGA_MAC_VER_25 only: FAIL.
 - RTL_GIGA_MAC_VER_26 only: SUCCESS.
 - RTL_GIGA_MAC_VER_25 + RTL_GIGA_MAC_VER_26: SUCCESS.


diff --git a/drivers/net/ethernet/realtek/r8169.c 
b/drivers/net/ethernet/realtek/r8169.c
index e7ff886..eb6a5e4 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3827,6 +3827,8 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private 
*tp)
void __iomem *ioaddr = tp->mmio_addr;
 
switch (tp->mac_version) {
+   case RTL_GIGA_MAC_VER_25:
+   case RTL_GIGA_MAC_VER_26:
case RTL_GIGA_MAC_VER_29:
case RTL_GIGA_MAC_VER_30:
case RTL_GIGA_MAC_VER_32:
-- 
1.7.10.4

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

Re: drm i915 hangs on heavy io load

[Norbert Preining]

Hi Chris,

I haven't answered due to several reboots necessary (sometimes 
I have to work on Win***) and no effect, but ..

On Mi, 24 Okt 2012, Chris Wilson wrote:
> > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile=0d5fed2de763b49bb1a90140758153481f043757
> > > is the missing ingredient.
> > 
> > I am compiling a kernel with this patch based on current git now.
> > Should I still use the above kernel cmd argument (i915...rc6=0)
> > or try without it?
> 
> Without any rc6 parameter would be best. But if rc6=0 wasn't the
> solution for you, then I may have identified the wrong w/a. Can I ask
> you try the patches in that branch until you find one (or more perhaps)
> that stabilise your system?

I pulled the whole branch into my compile branch, and removed everything
from kernel cmd line regarding rc6, and got the
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[drm:i915_reset] *ERROR* Failed to reset chip.
new i915_error_state.gz at the same place.

So it seems that the patches in the ilk-wa-pile branch do not help.

All the best

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

SCRONKEY (n.)
Something that hits the window as a result of a violent sneeze.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]Documentation:Chinese translation of Documentation/arm64/memory.txt

[Ninja Tekkaman]

Thanks for your answer!
So I will make a patch for it (in English and Chinese).
For English patch ,if you like it, please acked it.

2012/10/27 Catalin Marinas :
> On 27 October 2012 06:11, Ninja Tekkaman  wrote:
>> I have a question about the original document.
>> what is the exact meaning about the "memory" in
>> "ffc0    256GB  memory"
>> Can I treat it as "kernel logical address space" ? Or maybe It can be
>> modified to “kernel” ？
>
> It's the linear mapping of the RAM used by the kernel. So you could
> say "kernel logical memory map" (I wouldn't say address space as this
> is wider and it includes vmalloc, modules etc.)
>
> --
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V4 REPOST 2/2] kbuild: run the pre-processor on *.dts files

[Stephen Warren]

On 10/27/2012 07:06 PM, Rob Herring wrote:
> Mark Brown  wrote:
> 
> On Fri, Oct 26, 2012 at 02:57:50PM -0500, Rob Herring wrote:
> 
> Like I said previously, I think we first need guidelines on what
> is and
> isn't acceptable use of C preprocessor in dts files.
> 
> 
> Didn't we already say that it was just the same rules as for things tht
> get included in .S files?  Besides for plain .dts files (as opposed to
> .dtsi files) it seems like if people break things they get to keep all
> the pieces without disrupting other people too much.
> 
> 
> Yes, but can we document that. Also, I'd like others with more DT
> historical knowledge to weigh in.

OK. What's the appropriate file to document that in? I assume you're not
just looking for an explanation in the commit description?

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

Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code

[Andrey Smirnov]

On 10/27/2012 02:31 PM, Mark Brown wrote:
> On Thu, Oct 25, 2012 at 03:26:02PM -0700, Andrey Smirnov wrote:
>> On 10/25/2012 12:45 PM, Mark Brown wrote:
>>> This really makes little sense to me, why are you doing this?  Does the
>>> device *really* layer a byte stream on top of I2C for sending messages
>>> that look like marshalled register reads and writes?
>> The SI476x chips has a concept of a "property". Each property having
>> 16-bit address and 16-bit value. At least a portion of a chip
>> configuration is done by modifying those properties. In order to
> Right, that's what I remembered from previous code.  There's no way this
> should be a regmap bus - a bus is something that gets data serialised by
> the core into a byte stream, having the data rendered down into a byte
> stream and then reparsing it is a bit silly.  The device should be
> hooking in before the data gets marshalled which we can't currently do
> but it shouldn't be too hard to make it so that we can have register
> read and write functions supplied in the regmap config.

Oh, now I think I see what you mean. I have two agree with you, I don't
think I like what I am doing in my code.
I'll try to familiarize myself with 'regmap' code and come up with the
way to extend the framework.

And I just wanted to upstream my simple radio driver... :-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 163/193] net/dccp/ccids: remove CONFIG_EXPERIMENTAL

[Gerrit Renker]

On Tue, 23 Oct 2012 13:03:56 -0700
Kees Cook  wrote:

> From: Kees Cook 
> To: linux-kernel@vger.kernel.org
> Cc: Kees Cook , Gerrit Renker , 
> "David S. Miller" 
> Subject: [PATCH 163/193] net/dccp/ccids: remove CONFIG_EXPERIMENTAL
> Date: Tue, 23 Oct 2012 13:03:56 -0700
> X-Mailer: git-send-email 1.7.9.5
> 
> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
> 
> CC: Gerrit Renker 
> CC: "David S. Miller" 
> Signed-off-by: Kees Cook 
Acked-by: Gerrit Renker 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 162/193] net/dccp: remove CONFIG_EXPERIMENTAL

[Gerrit Renker]

> This config item has not carried much meaning for a while now and is
> almost always enabled by default. As agreed during the Linux kernel
> summit, remove it.
> 
> CC: Gerrit Renker 
> CC: "David S. Miller" 
> Signed-off-by: Kees Cook 

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

Re: [PATCH 2/3] ext4: introduce ext4_error_remove_page

[Naoya Horiguchi]

Hi Ted,

On Sat, Oct 27, 2012 at 06:16:26PM -0400, Theodore Ts'o wrote:
> On Fri, Oct 26, 2012 at 10:24:23PM +, Luck, Tony wrote:
> > > Well, we could set a new attribute bit on the file which indicates
> > > that the file has been corrupted, and this could cause any attempts to
> > > open the file to return some error until the bit has been cleared.
> > 
> > That sounds a lot better than renaming/moving the file.
> 
> What I would recommend is adding a 
> 
> #define FS_CORRUPTED_FL   0x0100 /* File is corrupted */
> 
> ... and which could be accessed and cleared via the lsattr and chattr
> programs.

Thank you for the info. This could help my next work.

> > > Application programs could also get very confused when any attempt to
> > > open or read from a file suddenly returned some new error code (EIO,
> > > or should we designate a new errno code for this purpose, so there is
> > > a better indication of what the heck was going on?)
> > 
> > EIO sounds wrong ... but it is perhaps the best of the existing codes. 
> > Adding
> > a new one is also challenging too.
> 
> I think we really need a different error code from EIO; it's already
> horribly overloaded already, and if this is new behavior when the
> customers get confused and call up the distribution help desk, they
> won't thank us if we further overload EIO.  This is abusing one of the
> System V stream errno's, but no one else is using it:
> 
> #define EADV   68  /* Advertise error */
> 
> I note that we've already added a new error code:
> 
> #define EHWPOISON 133   /* Memory page has hardware error */
> 
> ... although the glibc shipping with Debian testing hasn't been taught
> what it is, so strerror(EHWPOISON) returns "Unknown error 133".  We
> could simply allow open(2) and stat(2) return this error, although I
> wonder if we're just better off defining a new error code.

Whether we use EIO or EHWPOISON seems to be controversial. Andi likes
to use EIO because we can handle memory errors and legacy I/O errors in
the similar and integrated manner.
But personally, it's OK for me to use EHWPOISON. Obviously defining this
error code in glibc is a necessary step if we go in this direction.

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

[PATCH 5/5] fat: add mutex lock to fat_build_inode

[Namjae Jeon]

From: Namjae Jeon 

fat_nfs_get_inode does not hold i_mutex of parent directory.So add
lock to fat_build_inode.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/fat.h   |1 +
 fs/fat/inode.c |   15 +++
 2 files changed, 16 insertions(+)

diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 177e94e..811267c 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -75,6 +75,7 @@ struct msdos_sb_info {
unsigned long fsinfo_sector;  /* sector number of FAT32 fsinfo */
struct mutex fat_lock;
struct mutex s_lock;
+   struct mutex nfs_build_inode_lock;
unsigned int prev_free;  /* previously allocated cluster number */
unsigned int free_clusters;  /* -1 if undefined */
unsigned int free_clus_valid; /* is free_clusters valid? */
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 63e0883..a1650ef 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -443,12 +443,25 @@ static int fat_fill_inode(struct inode *inode, struct 
msdos_dir_entry *de)
return 0;
 }
 
+static inline void fat_lock_build_inode(struct msdos_sb_info *sbi)
+{
+   if (sbi->options.nfs == FAT_NFS_NOSTALE_RO)
+   mutex_lock(>nfs_build_inode_lock);
+}
+
+static inline void fat_unlock_build_inode(struct msdos_sb_info *sbi)
+{
+   if (sbi->options.nfs == FAT_NFS_NOSTALE_RO)
+   mutex_unlock(>nfs_build_inode_lock);
+}
+
 struct inode *fat_build_inode(struct super_block *sb,
struct msdos_dir_entry *de, loff_t i_pos)
 {
struct inode *inode;
int err;
 
+   fat_lock_build_inode(MSDOS_SB(sb));
inode = fat_iget(sb, i_pos);
if (inode)
goto out;
@@ -468,6 +481,7 @@ struct inode *fat_build_inode(struct super_block *sb,
fat_attach(inode, i_pos);
insert_inode_hash(inode);
 out:
+   fat_unlock_build_inode(MSDOS_SB(sb));
return inode;
 }
 
@@ -1173,6 +1187,7 @@ int fat_fill_super(struct super_block *sb, void *data, 
int silent, int isvfat,
sb->s_magic = MSDOS_SUPER_MAGIC;
sb->s_op = _sops;
sb->s_export_op = _export_ops;
+   mutex_init(>nfs_build_inode_lock);
ratelimit_state_init(>ratelimit, DEFAULT_RATELIMIT_INTERVAL,
 DEFAULT_RATELIMIT_BURST);
 
-- 
1.7.9.5

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

[PATCH 4/5] fat: (exportfs) move code to rebuild directory-inode to separate function

[Namjae Jeon]

From: Namjae Jeon 

Move the logic to rebuild directory inode (when mounted with nostale_ro)
to new function fat_rebuild_parent

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/nfs.c |   71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
index 0abfacf..6e6b233 100644
--- a/fs/fat/nfs.c
+++ b/fs/fat/nfs.c
@@ -312,6 +312,45 @@ static int fat_read_next_clus(struct super_block *sb, int 
search_clus)
 }
 
 /*
+ * Rebuild the parent for a directory that is not connected
+ * to the filesystem root
+ */
+static
+struct inode *fat_rebuild_parent(struct super_block *sb, int parent_logstart)
+{
+   int search_clus, clus_to_match;
+   struct msdos_dir_entry *de;
+   struct inode *parent;
+   struct msdos_sb_info *sbi = MSDOS_SB(sb);
+   sector_t blknr = fat_clus_to_blknr(sbi, parent_logstart);
+   struct buffer_head *parent_bh = sb_bread(sb, blknr);
+
+   if (!parent_bh) {
+   fat_msg(sb, KERN_ERR,
+   "NFS:unable to read cluster of parent directory");
+   return NULL;
+   }
+   de = (struct msdos_dir_entry *) parent_bh->b_data;
+   clus_to_match = fat_get_start(sbi, [0]);
+   search_clus = fat_get_start(sbi, [1]);
+   if (!search_clus)
+   search_clus = sbi->root_cluster;
+   brelse(parent_bh);
+   do {
+   parent =  fat_traverse_cluster(sb,
+   search_clus, clus_to_match);
+   if (IS_ERR(parent) || parent)
+   break;
+   search_clus = fat_read_next_clus(sb, search_clus);
+   if (search_clus < 0)
+   break;
+   } while (search_clus != FAT_ENT_EOF);
+
+   return parent;
+
+
+}
+/*
  * Find the parent for a directory that is not currently connected to
  * the filesystem root.
  *
@@ -320,44 +359,18 @@ static int fat_read_next_clus(struct super_block *sb, int 
search_clus)
 struct dentry *fat_get_parent(struct dentry *child_dir)
 {
struct super_block *sb = child_dir->d_sb;
-   struct buffer_head *dotdot_bh = NULL, *parent_bh = NULL;
+   struct buffer_head *dotdot_bh = NULL;
struct msdos_dir_entry *de;
struct inode *parent_inode = NULL;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
int parent_logstart;
-   int search_clus, clus_to_match;
-   sector_t blknr;
 
if (!fat_get_dotdot_entry(child_dir->d_inode, _bh, )) {
parent_logstart = fat_get_start(sbi, de);
parent_inode = fat_dget(sb, parent_logstart);
-   if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
-   goto out;
-   blknr = fat_clus_to_blknr(sbi, parent_logstart);
-   parent_bh = sb_bread(sb, blknr);
-   if (!parent_bh) {
-   fat_msg(sb, KERN_ERR,
-   "NFS:unable to read cluster of parent 
directory");
-   goto out;
-   }
-   de = (struct msdos_dir_entry *) parent_bh->b_data;
-   clus_to_match = fat_get_start(sbi, [0]);
-   search_clus = fat_get_start(sbi, [1]);
-   if (!search_clus)
-   search_clus = sbi->root_cluster;
-   brelse(parent_bh);
-   do {
-   parent_inode =  fat_traverse_cluster(sb,
-   search_clus, clus_to_match);
-   if (IS_ERR(parent_inode) || parent_inode)
-   break;
-   search_clus = fat_read_next_clus(sb,
-   search_clus);
-   if (search_clus < 0)
-   break;
-   } while (search_clus != FAT_ENT_EOF);
+   if (!parent_inode && sbi->options.nfs == FAT_NFS_NOSTALE_RO)
+   parent_inode = fat_rebuild_parent(sb, parent_logstart);
}
-out:
brelse(dotdot_bh);
 
return d_obtain_alias(parent_inode);
-- 
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 2/5] fat: restructure export operations

[Namjae Jeon]

From: Namjae Jeon 

Define two nfs export_operation structures,one for 'stale_rw' mounts and
the other for 'nostale_ro'.The former uses the generic
export_encode_fh function to encode file handle, while the latter uses
fat_encode_fh.

Since inode number is not needed for nostale_ro, remove it from struct
fat_fid and repack other needed info viz. i_pos and i_generation.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/fat.h   |2 +
 fs/fat/inode.c |   12 ++
 fs/fat/nfs.c   |  127 +++-
 3 files changed, 104 insertions(+), 37 deletions(-)

diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index febc1cca..65f9149 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -391,6 +391,8 @@ void fat_cache_destroy(void);
 
 /* fat/nfs.c */
 struct fid;
+extern const struct export_operations fat_export_ops;
+extern const struct export_operations fat_export_ops_nostale;
 extern int fat_encode_fh(struct inode *inode, __u32 *fh, int *lenp,
 struct inode *parent);
 extern struct dentry *fat_fh_to_dentry(struct super_block *sb, struct fid *fid,
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 80c6fdd..34253dc 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -703,13 +702,6 @@ static const struct super_operations fat_sops = {
.show_options   = fat_show_options,
 };
 
-static const struct export_operations fat_export_ops = {
-   .encode_fh  = fat_encode_fh,
-   .fh_to_dentry   = fat_fh_to_dentry,
-   .fh_to_parent   = fat_fh_to_parent,
-   .get_parent = fat_get_parent,
-};
-
 static int fat_show_options(struct seq_file *m, struct dentry *root)
 {
struct msdos_sb_info *sbi = MSDOS_SB(root->d_sb);
@@ -1118,8 +1110,10 @@ out:
opts->allow_utime = ~opts->fs_dmask & (S_IWGRP | S_IWOTH);
if (opts->unicode_xlate)
opts->utf8 = 0;
-   if (opts->nfs == FAT_NFS_NOSTALE_RO)
+   if (opts->nfs == FAT_NFS_NOSTALE_RO) {
sb->s_flags |= MS_RDONLY;
+   sb->s_export_op = _export_ops_nostale;
+   }
 
return 0;
 }
diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
index 671a75d..0abfacf 100644
--- a/fs/fat/nfs.c
+++ b/fs/fat/nfs.c
@@ -15,13 +15,17 @@
 #include "fat.h"
 
 struct fat_fid {
-   u32 ino;
-   u32 gen;
-   u64 i_pos;
-   u32 parent_ino;
-   u32 parent_gen;
+   u32 i_gen;
+   u32 i_pos_low;
+   u16 i_pos_hi;
+   u16 parent_i_pos_hi;
+   u32 parent_i_pos_low;
+   u32 parent_i_gen;
 } __packed;
 
+#define FILEID_FAT_WITHOUT_PARENT (offsetof(struct fat_fid, parent_i_pos_hi)/4)
+#define FILEID_FAT_WITH_PARENT (sizeof(struct fat_fid)/4)
+
 /**
  * Look up a directory inode given its starting cluster.
  */
@@ -47,15 +51,24 @@ static struct inode *fat_dget(struct super_block *sb, int 
i_logstart)
return inode;
 }
 
+static struct inode *fat_ilookup(struct super_block *sb, u64 ino, loff_t i_pos)
+{
+   if (MSDOS_SB(sb)->options.nfs == FAT_NFS_NOSTALE_RO)
+   return fat_iget(sb, i_pos);
+
+   else {
+   if ((ino < MSDOS_ROOT_INO) || (ino == MSDOS_FSINFO_INO))
+   return NULL;
+   return ilookup(sb, ino);
+   }
+}
+
 static struct inode *fat_nfs_get_inode(struct super_block *sb,
   u64 ino, u32 generation, loff_t i_pos)
 {
-   struct inode *inode;
 
-   if ((ino < MSDOS_ROOT_INO) || (ino == MSDOS_FSINFO_INO))
-   return NULL;
+   struct inode *inode = fat_ilookup(sb, ino, i_pos);
 
-   inode = ilookup(sb, ino);
if (inode && generation && (inode->i_generation != generation)) {
iput(inode);
inode = NULL;
@@ -89,7 +102,8 @@ static struct inode *fat_nfs_get_inode(struct super_block 
*sb,
 
 
 int
-fat_encode_fh(struct inode *inode, __u32 *fh, int *lenp, struct inode *parent)
+fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp,
+   struct inode *parent)
 {
int len = *lenp;
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
@@ -97,24 +111,26 @@ fat_encode_fh(struct inode *inode, __u32 *fh, int *lenp, 
struct inode *parent)
loff_t i_pos;
int type = FILEID_INO32_GEN;
 
-   if (parent && (len < 5)) {
-   *lenp = 5;
+   if (parent && (len < FILEID_FAT_WITH_PARENT)) {
+   *lenp = FILEID_FAT_WITH_PARENT;
return 255;
-   } else if (len < 3) {
-   *lenp = 3;
+   } else if (len < FILEID_FAT_WITHOUT_PARENT) {
+   *lenp = FILEID_FAT_WITHOUT_PARENT;
return 255;
}
 
i_pos = fat_i_pos_read(sbi, inode);
-   *lenp = 3;
-   fid->ino = inode->i_ino;
-   fid->gen = inode->i_generation;
-   fid->i_pos = i_pos;
+   

[PATCH 3/5] fat: move fat_i_pos_read to fat.h

[Namjae Jeon]

From: Namjae Jeon 

Originally, fat_i_pos_read was a static inline function in inode.c.
The static keyword was removed so that it could be accessed from other
files. However it is better to make it a static inline function in fat.h
as suggested by Ogawa.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/fat.h   |   14 ++
 fs/fat/inode.c |   14 --
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 65f9149..177e94e 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -222,6 +222,20 @@ static inline void fat_get_blknr_offset(struct 
msdos_sb_info *sbi,
*offset = i_pos & (sbi->dir_per_block - 1);
 }
 
+static inline loff_t fat_i_pos_read(struct msdos_sb_info *sbi,
+   struct inode *inode)
+{
+   loff_t i_pos;
+#if BITS_PER_LONG == 32
+   spin_lock(>inode_hash_lock);
+#endif
+   i_pos = MSDOS_I(inode)->i_pos;
+#if BITS_PER_LONG == 32
+   spin_unlock(>inode_hash_lock);
+#endif
+   return i_pos;
+}
+
 static inline void fat16_towchar(wchar_t *dst, const __u8 *src, size_t len)
 {
 #ifdef __BIG_ENDIAN
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 34253dc..63e0883 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -595,20 +595,6 @@ static int fat_statfs(struct dentry *dentry, struct 
kstatfs *buf)
return 0;
 }
 
-loff_t fat_i_pos_read(struct msdos_sb_info *sbi,
-   struct inode *inode)
-{
-   loff_t i_pos;
-#if BITS_PER_LONG == 32
-   spin_lock(>inode_hash_lock);
-#endif
-   i_pos = MSDOS_I(inode)->i_pos;
-#if BITS_PER_LONG == 32
-   spin_unlock(>inode_hash_lock);
-#endif
-   return i_pos;
-}
-
 static int __fat_write_inode(struct inode *inode, int wait)
 {
struct super_block *sb = inode->i_sb;
-- 
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 1/5] fat: remove parent_logstart check in fat_get_parent

[Namjae Jeon]

From: Namjae Jeon 

The root directory inode is added to the directory hash table in
fat_attach when mounted with nfs option. Since root dentry never
expires until umount, fat_dget never fails to return the root inode
for subdirectories of root inode.i.e., parent_logstart cannot be zero.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ravishankar N 
Signed-off-by: Amit Sahrawat 
---
 fs/fat/nfs.c |   51 ++-
 1 file changed, 22 insertions(+), 29 deletions(-)

diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c
index a4e6ac7..671a75d 100644
--- a/fs/fat/nfs.c
+++ b/fs/fat/nfs.c
@@ -274,36 +274,29 @@ struct dentry *fat_get_parent(struct dentry *child_dir)
parent_inode = fat_dget(sb, parent_logstart);
if (parent_inode || sbi->options.nfs != FAT_NFS_NOSTALE_RO)
goto out;
-   if (!parent_logstart)
-   /*logstart of dotdot entry is zero if
-   * if the directory's parent is root
-   */
-   parent_inode = sb->s_root->d_inode;
-   else {
-   blknr = fat_clus_to_blknr(sbi, parent_logstart);
-   parent_bh = sb_bread(sb, blknr);
-   if (!parent_bh) {
-   fat_msg(sb, KERN_ERR,
-   "NFS:unable to read cluster of parent 
directory");
-   goto out;
-   }
-   de = (struct msdos_dir_entry *) parent_bh->b_data;
-   clus_to_match = fat_get_start(sbi, [0]);
-   search_clus = fat_get_start(sbi, [1]);
-   if (!search_clus)
-   search_clus = sbi->root_cluster;
-   brelse(parent_bh);
-   do {
-   parent_inode =  fat_traverse_cluster(sb,
-   search_clus, clus_to_match);
-   if (IS_ERR(parent_inode) || parent_inode)
-   break;
-   search_clus = fat_read_next_clus(sb,
-   search_clus);
-   if (search_clus < 0)
-   break;
-   } while (search_clus != FAT_ENT_EOF);
+   blknr = fat_clus_to_blknr(sbi, parent_logstart);
+   parent_bh = sb_bread(sb, blknr);
+   if (!parent_bh) {
+   fat_msg(sb, KERN_ERR,
+   "NFS:unable to read cluster of parent 
directory");
+   goto out;
}
+   de = (struct msdos_dir_entry *) parent_bh->b_data;
+   clus_to_match = fat_get_start(sbi, [0]);
+   search_clus = fat_get_start(sbi, [1]);
+   if (!search_clus)
+   search_clus = sbi->root_cluster;
+   brelse(parent_bh);
+   do {
+   parent_inode =  fat_traverse_cluster(sb,
+   search_clus, clus_to_match);
+   if (IS_ERR(parent_inode) || parent_inode)
+   break;
+   search_clus = fat_read_next_clus(sb,
+   search_clus);
+   if (search_clus < 0)
+   break;
+   } while (search_clus != FAT_ENT_EOF);
}
 out:
brelse(dotdot_bh);
-- 
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: ipc, msgqueue: NULL ptr deref in msgrcv

[Sasha Levin]

On 10/25/2012 08:43 PM, Sasha Levin wrote:
> Hi all,
> 
> While fuzzing with trinity inside a KVM tools (lkvm) guest running latest 
> -next,
> I've stumbled on the follwing:
> 
> [   80.110944] NULL pointer dereference at 0011
> [   80.110944] IP: [] testmsg.isra.5+0x40/0x70
> [   80.110944] PGD 23812067 PUD 23811067 PMD 0
> [   80.110944] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [   80.110944] Dumping ftrace buffer:
> [   80.110944](ftrace buffer empty)
> [   80.110944] CPU 1
> [   80.110944] Pid: 6452, comm: trinity-child84 Tainted: GW
> 3.7.0-rc2-next-20121025-sasha-1-g673f98e-dirty #77
> [   80.110944] RIP: 0010:[]  [] 
> testmsg.isra.5+0x40/0x70
> [   80.110944] RSP: 0018:88004dda9e78  EFLAGS: 00010246
> [   80.110944] RAX:  RBX: 0002 RCX: 
> 000f
> [   80.110944] RDX: 0002 RSI: 282c796a RDI: 
> 0011
> [   80.110944] RBP: 88004dda9e78 R08:  R09: 
> 
> [   80.110944] R10: 0001 R11: 0001 R12: 
> 282c796a
> [   80.110944] R13: 8800621ab7c0 R14: 0001 R15: 
> 8800621ab710
> [   80.110944] FS:  7f777fd4d700() GS:88002780() 
> knlGS:
> [   80.110944] CS:  0010 DS:  ES:  CR0: 80050033
> [   80.110944] CR2: 0011 CR3: 24bf9000 CR4: 
> 000406e0
> [   80.110944] DR0:  DR1:  DR2: 
> 
> [   80.110944] DR3:  DR6: 0ff0 DR7: 
> 0400
> [   80.110944] Process trinity-child84 (pid: 6452, threadinfo 
> 88004dda8000, task 88004dd9b000)
> [   80.110944] Stack:
> [   80.110944]  88004dda9f68 8190e2ce 001d7840 
> 88004dd9b000
> [   80.110944]  88004dd9b000 88004dd9b000  
> 8190cda0
> [   80.110944]   854e3160  
> 
> [   80.110944] Call Trace:
> [   80.110944]  [] do_msgrcv+0x1ae/0x640
> [   80.110944]  [] ? load_msg+0x190/0x190
> [   80.110944]  [] ? syscall_trace_enter+0x20/0x2e0
> [   80.110944]  [] sys_msgrcv+0x10/0x20
> [   80.110944]  [] tracesys+0xe1/0xe6
> [   80.110944] Code: eb 51 66 0f 1f 84 00 00 00 00 00 83 fa 03 74 2b 83 fa 04 
> 75 2e 48 39 37 b8 01 00 00 00 7f 24 eb 32 66 2e 0f
> 1f 84 00 00 00 00 00 <48> 3b 37 75 13 eb 19 66 0f 1f 84 00 00 00 00 00 48 3b 
> 37 75 0b
> [   80.110944] RIP  [] testmsg.isra.5+0x40/0x70
> [   80.110944]  RSP 
> [   80.110944] CR2: 0011
> [   80.246961] ---[ end trace 1d24d488413d3159 ]---
> 
>   case SEARCH_EQUAL:
>   if (msg->m_type == type) <--- here
>   return 1;
> 
> My guess is that we managed to get testmsg() called without INIT_LIST_HEAD() 
> somehow,
> but I'm still not sure why.
> 
> 
> Thanks,
> Sasha
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

My auto-bisect script just finished running. Looks like it's caused by:

e32811fe04c759faf63c93b470e787b2328ceb04 is the first bad commit
commit e32811fe04c759faf63c93b470e787b2328ceb04
Author: Stanislav Kinsbursky 
Date:   Thu Oct 25 12:15:18 2012 +1100

ipc: message queue copy feature introduced


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

Re: [PATCH v2 1/1] freezer: change ptrace_stop/do_signal_stop to use freezable_schedule()

[Rafael J. Wysocki]

On Friday, October 26, 2012 02:29:09 PM Tejun Heo wrote:
> Hello,
> 
> On Fri, Oct 26, 2012 at 11:29:56PM +0200, Rafael J. Wysocki wrote:
> > Actually, what tree is it supposed to apply to?
> > 
> > The change in kernel/cgroup_freezer.c doesn't look like anything in
> > the current Linus' tree to me.
> 
> Ooh, right.  This depends on the earlier cgroup_freezer changes.
> Sorry about the confusion.  I'll apply it to the following branch (the
> same one used for the previous cgroup_freezer updates).
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git cgroup-freezer

OK

I haven't merged it yet, so I'll get this fix along with the rest.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] perf parser: does not support arbitrary new sysfs events

[Jiri Olsa]

On Sun, Oct 28, 2012 at 01:13:59AM +0200, Stephane Eranian wrote:
> On Sat, Oct 27, 2012 at 10:34 PM, Jiri Olsa  wrote:
> > On Fri, Oct 26, 2012 at 10:23:09PM +0200, Stephane Eranian wrote:
> >> Hi,
> >>
> >> The latest round of perf parser changes broke my PEBS-LL patch series
> >> (at the last minute). For PEBS-LL, I need to add to generic events but I 
> >> want
> >> to keep them PMU specific. As such, they need to live in the sysfs events
> >> subdir: /sys/devices/cpu/events/mem-loads, 
> >> sys/devices/cpu/events/mem-stores.
> >>
> >> Given your latest rounds of sysfs event changes, I had to modify my kernel
> >> patches to fit those two new events within your perf_pmu_events_attr 
> >> tables.
> >>
> >> But now, when I try to do:
> >>
> >> $ perf record -e cpu/mem-loads/ 
> >
> > I can try this only on on uncore events and hw events aliases and that 
> > seems to work
> >
> I know it works there. I don't understand why it does not work with cpu/.
> 
> Just add an encoding that has no hardcoded equivalent. I bet you will
> reproduce the problem.
> 
> In my patch set, I have extended your perf_pmu_events_attr struct to
> also accept an already preformed event_str. I can send you that extension
> if you want.

that would be great

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf parser: does not support arbitrary new sysfs events

[Stephane Eranian]

On Sat, Oct 27, 2012 at 10:34 PM, Jiri Olsa  wrote:
> On Fri, Oct 26, 2012 at 10:23:09PM +0200, Stephane Eranian wrote:
>> Hi,
>>
>> The latest round of perf parser changes broke my PEBS-LL patch series
>> (at the last minute). For PEBS-LL, I need to add to generic events but I want
>> to keep them PMU specific. As such, they need to live in the sysfs events
>> subdir: /sys/devices/cpu/events/mem-loads, sys/devices/cpu/events/mem-stores.
>>
>> Given your latest rounds of sysfs event changes, I had to modify my kernel
>> patches to fit those two new events within your perf_pmu_events_attr tables.
>>
>> But now, when I try to do:
>>
>> $ perf record -e cpu/mem-loads/ 
>
> I can try this only on on uncore events and hw events aliases and that seems 
> to work
>
I know it works there. I don't understand why it does not work with cpu/.

Just add an encoding that has no hardcoded equivalent. I bet you will
reproduce the problem.

In my patch set, I have extended your perf_pmu_events_attr struct to
also accept an already preformed event_str. I can send you that extension
if you want.


>>
>> I get unsupported event. Looks at the syscall trace, it seems perf does not 
>> even
>> look into the sysfs subdir to find a possible match. I don't
>> understand that. What's
>> the point of sysfs event list if it is not used or cannot be extended?
>>
>> Note that when I explicitly pass the content of the sysfs file to perf
>> record, it
>> works:
>>
>> $ perf record -e cpu/event=0xcd,umask=0x1,ldlat=3/ ..
>>
>> So this is clearly a problem with the lookup in sysfs.
>>
>> Also if you have the mappings exposed now in sysfs, why keep the hardcoded
>> generic events as well? Or why have those events hardcoded in the parser as
>> well.
>
> having perf work on old kernels
>
>>
>> I don't understand all this parser code. I  get the feeling it is
>> getting a bit out of
>> hands already. But now, I am stuck. So could you fix my parser problem ASAP?
>
> yep, but need more details.. related patches would help
>
> jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 108/147] ALSA: hda - Fix internal mic for Lenovo Ideapad U300s

[Ben Hutchings]

On Thu, 2012-10-18 at 15:50 -0300, Herton Ronaldo Krzesinski wrote:
> On Sun, Oct 14, 2012 at 03:37:21PM +0100, Ben Hutchings wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: David Henningsson 
> > 
> > commit 18dcd3044e4c4b3ab6341c98e8d0e81e0d58d5e3 upstream.
> > 
> > The internal mic input is phase inverted on one channel.
> > To avoid people in userspace summing the channels together
> > and get zero result, use a separate mixer control for the
> > inverted channel.
> > 
> > BugLink: https://bugs.launchpad.net/bugs/903853
> > Signed-off-by: David Henningsson 
> > Signed-off-by: Takashi Iwai 
> > [bwh: Backported to 3.2:
> >  - Adjust context
> >  - Change both invocations of apply_pin_fixup()]
> > Signed-off-by: Ben Hutchings 
> 
> I noted today that a follow up fix for this is needed to avoid an oops
> in apply_fixup, please consider adding to the next 3.2 stable this:
> 
> commit 83b0c6ba999643ee8ad6329f26e1cdc870e1a920
> ALSA: hda - Fix oops caused by recent commit "Fix internal mic for Lenovo 
> Ideapad U300s"
[...]

Added to the queue, thanks.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

[Eric Sandeen]

On 10/27/12 4:19 PM, Eric Sandeen wrote:
> On 10/27/12 1:47 PM, Nix wrote:
>> On 27 Oct 2012, Theodore Ts'o said:
>>
>>> On Sat, Oct 27, 2012 at 01:45:25PM +0100, Nix wrote:
 Ah! it's turned on by journal_async_commit. OK, that alone argues
 against use of journal_async_commit, tested or not, and I'd not have
 turned it on if I'd noticed that.

 (So, the combinations I'll be trying for effect on this bug are:

  journal_async_commit (as now)
  journal_checksum
  none
>>>
>>> Can you also check and see whether the presence or absence of
>>> "nobarrier" makes a difference?
>>
>> Done. (Also checked the effect of your patches posted earlier this week:
>> no effect, I'm afraid, certainly not under the fails-even-on-3.6.1 test
>> I was carrying out, umount -l'ing /var as the very last thing I did
>> before /sbin/reboot -f.)
>>
>> nobarrier makes a difference that I, at least, did not expect:
>>
>> [no options]No corruption
>>
>> nobarrier   No corruption
>>
>>   journal_checksum  Corruption
>> Corrupted transaction, journal aborted
>> 
>> nobarrier,journal_checksum  Corruption
>> Corrupted transaction, journal aborted
>>
>>   journal_async_commit  Corruption
>> Corrupted transaction, journal aborted
>>
>> nobarrier,journal_async_commit  Corruption
>> No corrupted transaction or aborted journal
> 
> That's what we needed.  Woulda been great a few days ago ;)
> 
> In my testing journal_checksum is broken, and my bisection seems to
> implicate
> 
> commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31
> Author: Theodore Ts'o 
> Date:   Mon Feb 6 20:12:03 2012 -0500
> 
> ext4: fold ext4_claim_inode into ext4_new_inode
> 
> as the culprit.  I haven't had time to look into why, yet.

It looks like the inode_bitmap_bh is being modified outside a transaction:

ret2 = ext4_test_and_set_bit(ino, inode_bitmap_bh->b_data);

It needs a get_write_access / handle_dirty_metadata pair around it.

A hacky patch like this seems to work but it was done 5mins before I have
to be out the door to dinner so it probably needs cleanup or at least
scrutiny.

[PATCH] ext4: fix unjournaled inode bitmap modification

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 modified this function
such that the inode bitmap was being modified outside a transaction,
which could lead to corruption, and was discovered when journal_checksum
found a bad checksum in the journal.

Signed-off-by: Eric Sandeen 
---

--- ialloc.c.reverted2  2012-10-27 17:31:20.351537073 -0500
+++ ialloc.c2012-10-27 17:40:18.643553576 -0500
@@ -669,6 +669,10 @@
inode_bitmap_bh = ext4_read_inode_bitmap(sb, group);
if (!inode_bitmap_bh)
goto fail;
+   BUFFER_TRACE(inode_bitmap_bh, "get_write_access");
+   err = ext4_journal_get_write_access(handle, inode_bitmap_bh);
+   if (err)
+   goto fail;
 
 repeat_in_this_group:
ino = ext4_find_next_zero_bit((unsigned long *)
@@ -690,6 +694,10 @@
ino++;  /* the inode bitmap is zero-based */
if (!ret2)
goto got; /* we grabbed the inode! */
+   BUFFER_TRACE(inode_bitmap_bh, "call 
ext4_handle_dirty_metadata");
+   err = ext4_handle_dirty_metadata(handle, NULL, inode_bitmap_bh);
+   if (err)
+   goto fail;
if (ino < EXT4_INODES_PER_GROUP(sb))
goto repeat_in_this_group;
}




> -Eric
> 
>> I didn't expect the last case at all, and it adequately explains why you
>> are mostly seeing corrupted journal messages in your tests but I was
>> not. It also explains why when I saw this for the first time I was able
>> to mount the resulting corrupted filesystem read-write and corrupt it
>> further before I noticed that anything was wrong.
>>
>> It is also clear that journal_checksum and all that relies on it is
>> worse than useless right now, as Eric reported while I was testing this.
>> It should probably be marked CONFIG_BROKEN in future 3.[346].* stable
>> kernels, if CONFIG_BROKEN existed anymore, which it doesn't.
>>
>> It's a shame journal_async_commit depends on a broken feature: it might
>> be notionally unsafe but on some of my systems (without nobarrier or
>> flashy caching controllers) it was associated with a noticeable speedup
>> of metadata-heavy workloads -- though that was way back in 2009...
>> however, "safety first" definitely applies in this case.
>>
> 

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

Re: [PATCH 2/3] ext4: introduce ext4_error_remove_page

[Theodore Ts'o]

On Fri, Oct 26, 2012 at 10:24:23PM +, Luck, Tony wrote:
> > Well, we could set a new attribute bit on the file which indicates
> > that the file has been corrupted, and this could cause any attempts to
> > open the file to return some error until the bit has been cleared.
> 
> That sounds a lot better than renaming/moving the file.

What I would recommend is adding a 

#define FS_CORRUPTED_FL 0x0100 /* File is corrupted */

... and which could be accessed and cleared via the lsattr and chattr
programs.

> > Application programs could also get very confused when any attempt to
> > open or read from a file suddenly returned some new error code (EIO,
> > or should we designate a new errno code for this purpose, so there is
> > a better indication of what the heck was going on?)
> 
> EIO sounds wrong ... but it is perhaps the best of the existing codes. Adding
> a new one is also challenging too.

I think we really need a different error code from EIO; it's already
horribly overloaded already, and if this is new behavior when the
customers get confused and call up the distribution help desk, they
won't thank us if we further overload EIO.  This is abusing one of the
System V stream errno's, but no one else is using it:

#define EADV 68  /* Advertise error */

I note that we've already added a new error code:

#define EHWPOISON 133 /* Memory page has hardware error */

... although the glibc shipping with Debian testing hasn't been taught
what it is, so strerror(EHWPOISON) returns "Unknown error 133".  We
could simply allow open(2) and stat(2) return this error, although I
wonder if we're just better off defining a new error code.

> 18 years ago Intel rather famously attempted to sell users on the
> idea that a rare divide error that sometimes gave the wrong answer
> could be ignored. Before my time at Intel, but it is still burned
> into the corporate psyche that customers really don't like to get
> the wrong answers from their computers.

... and yet, people are generally not willing to pay the few extra
dollars for ECC memory, such that even if I want ECC for a laptop or a
desktop machine, it's generally not available without paying  for
a server-class motherboard.  :-(

The lesson I'd take from that incident is that customers really hate
it when it's trivial to reproduce the error, especially using the
something as simple and universal as the Windows Calculator
application.

Anyway, that's neither here nor there.  Perhaps it's enough to simply
log an error with a sufficient level of severity that it gets saved in
log files, at least for now.

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

[PATCH] firmware: use noinline_for_stack

[Cesar Eduardo Barros]

The comment above fw_file_size() suggests it is noinline for stack size
reasons. Use noinline_for_stack to make this more clear.

Cc: Ming Lei 
Cc: Greg Kroah-Hartman 
Cc: Linus Torvalds 
Signed-off-by: Cesar Eduardo Barros 
---
 drivers/base/firmware_class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..620b876 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -275,7 +275,7 @@ static const char *fw_path[] = {
 };
 
 /* Don't inline this: 'struct kstat' is biggish */
-static noinline long fw_file_size(struct file *file)
+static noinline_for_stack long fw_file_size(struct file *file)
 {
struct kstat st;
if (vfs_getattr(file->f_path.mnt, file->f_path.dentry, ))
-- 
1.7.11.7

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

[Q] .readable_reg() not verified during read?

[Guennadi Liakhovetski]

Hi Mark

Looking at regmap.c it looks like the .readable_reg() callback is not 
consulted when performing a register read, e.g. in _regmap_raw_read(). Is 
this intentional? If yes - why?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: remove dummy long from EFI stub

[Cesar Eduardo Barros]

Commit 2e064b1 (x86, efi: Fix issue of overlapping .reloc section for
EFI_STUB) removed a dummy reloc added by commit 291f363 (x86, efi: EFI
boot stub support), but forgot to remove the dummy long used by that
reloc.

Cc: Jordan Justen 
Cc: Matt Fleming 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Signed-off-by: Cesar Eduardo Barros 
---
 arch/x86/boot/header.S | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 2a01744..8c132a6 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -476,6 +476,3 @@ die:
 setup_corrupt:
.byte   7
.string "No setup signature found...\n"
-
-   .data
-dummy: .long   0
-- 
1.7.11.7

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

[PATCH] x86: fix comment for set_real_mode_permissions

[Cesar Eduardo Barros]

The function which gets called very early is setup_real_mode(). The
set_real_mode_permissions() function is the arch_initcall.

Cc: Jarkko Sakkinen 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Signed-off-by: Cesar Eduardo Barros 
---
 arch/x86/realmode/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index cbca565..b4c92c5 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -84,7 +84,7 @@ void __init setup_real_mode(void)
 }
 
 /*
- * set_real_mode_permissions() gets called very early, to guarantee the
+ * setup_real_mode() gets called very early, to guarantee the
  * availability of low memory.  This is before the proper kernel page
  * tables are set up, so we cannot set page permissions in that
  * function.  Thus, we use an arch_initcall instead.
-- 
1.7.11.7

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

Re: [PATCH v2 1/1] freezer: change ptrace_stop/do_signal_stop to use freezable_schedule()

[Ben Hutchings]

On Fri, 2012-10-26 at 19:46 +0200, Oleg Nesterov wrote:
> try_to_freeze_tasks() and cgroup_freezer rely on scheduler locks
> to ensure that a task doing STOPPED/TRACED -> RUNNING transition
> can't escape freezing. This mostly works, but ptrace_stop() does
> not necessarily call schedule(), it can change task->state back to
> RUNNING and check freezing() without any lock/barrier in between.
> 
> We could add the necessary barrier, but this patch changes
> ptrace_stop() and do_signal_stop() to use freezable_schedule().
> This fixes the race, freezer_count() and freezer_should_skip()
> carefully avoid the race.
> 
> And this simplifies the code, try_to_freeze_tasks/update_if_frozen
> no longer need to use task_is_stopped_or_traced() checks with the
> non trivial assumptions. We can rely on the mechanism which was
> specially designed to mark the sleeping task as "frozen enough".
> 
> v2: As Tejun pointed out, we can also change get_signal_to_deliver()
> and move try_to_freeze() up before 'relock' label.
> 
> Signed-off-by: Oleg Nesterov 
[...]

This is not the correct way to submit a change to stable.  Please see
Documentation/stable_kernel_rules.txt

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

Re: [PATCH V4 REPOST 2/2] kbuild: run the pre-processor on *.dts files

[Mark Brown]

On Fri, Oct 26, 2012 at 02:57:50PM -0500, Rob Herring wrote:

> Like I said previously, I think we first need guidelines on what is and
> isn't acceptable use of C preprocessor in dts files.

Didn't we already say that it was just the same rules as for things tht
get included in .S files?  Besides for plain .dts files (as opposed to
.dtsi files) it seems like if people break things they get to keep all
the pieces without disrupting other people too much.


signature.asc
Description: Digital signature

Re: [Patch v3 2/7] Regulator: DA9055 Regulator driver

[Mark Brown]

On Thu, Oct 11, 2012 at 03:39:24PM +0530, Ashish Jangam wrote:

> This is the Regulator patch for the DA9055 PMIC and has got dependency on
> the DA9055 MFD core.

Always submit patches with subject lines appropriate for the subsystem,
this helps get your patch noticed.  People do things like search their
mailboxes for subsystem prefixes when looking for things they need to
review.

> This patch support all of the DA9055 regulators. The output voltages are
> fully programmable through I2C interface only. The platform data with 
> regulation
> constraints is passed down from the board to the regulator.
> 
> + switch (mode) {
> + case REGULATOR_MODE_FAST:
> + val = DA9055_BUCK_MODE_SYNC << info->mode.shift;
> + break;
> + case REGULATOR_MODE_NORMAL:
> + val = DA9055_BUCK_MODE_AUTO << info->mode.shift;
> + break;
> + case REGULATOR_MODE_IDLE:
> + case REGULATOR_MODE_STANDBY:
> + val = DA9055_BUCK_MODE_SLEEP << info->mode.shift;
> + break;

_IDLE and _STANDBY should have different effects if they're both
implemented; pick one.  From the rest of the code it looks like it
should be _STANDBY.

> + switch (mode) {
> + case REGULATOR_MODE_NORMAL:
> + case REGULATOR_MODE_FAST:
> + val = DA9055_LDO_MODE_SYNC;
> + break;
> + case REGULATOR_MODE_IDLE:
> + case REGULATOR_MODE_STANDBY:
> + val = DA9055_LDO_MODE_SLEEP;
> + }

Similarly here.  You're also missing a break;

> + /* Get the voltage for the activer register set A/B */
> + if (ret == DA9055_REGUALTOR_SET_A)
> + ret = da9055_reg_read(regulator->da9055, volt.reg_a);
> + else
> + ret = da9055_reg_read(regulator->da9055, volt.reg_b);
> +
> + if (ret < 0)
> + return ret;
> +
> + sel = ((ret & volt.v_mask) - volt.v_offset);

Why not just use the register values directly and refuse to write ones
That are too low?  This would simplify things a little as you'd only
need to check 

> + /* Set the voltage */
> + if (ret == DA9055_REGUALTOR_SET_A)
> + return da9055_regulator_set_voltage_bits(rdev, info->volt.reg_a,
> +  selector);
> +
> + return da9055_regulator_set_voltage_bits(rdev, info->volt.reg_b,
> +  selector);

This is confusingly written - it should be either a switch or an if/else
really.

> + /* Select register set B for suspend voltage ramping. */
> + ret = da9055_reg_update(regulator->da9055, info->conf.reg,
> + info->conf.sel_mask, DA9055_SEL_REG_B);
> + if (ret < 0)
> + return ret;

This doesn't seem like it plays nicely with the GPIO selection in normal
set_voltage() - does it need to check to see if register set B might be
used in normal operation and refuse to run if it could?

> + for (i = 0; i < ARRAY_SIZE(da9055_regulator_info); i++) {
> + info = _regulator_info[i];
> + if (info->reg_desc.id == id)
> + return info;
> + }
> +

The indentation here is *very* messed up.  I'd suggest not omitting any
braces.


signature.asc
Description: Digital signature

[PATCH 2/2] staging/comedi: Use dev_ printks in drivers/quatech_daqp_cs.c

[YAMANE Toshiaki]

fixed below checkpatch warnings.
- WARNING: printk() should include KERN_ facility level

Signed-off-by: YAMANE Toshiaki 
---
 drivers/staging/comedi/drivers/quatech_daqp_cs.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c 
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index 806523c..ee9158b 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -300,7 +300,7 @@ static enum irqreturn daqp_interrupt(int irq, void *dev_id)
if (status & DAQP_STATUS_DATA_LOST) {
s->async->events |=
COMEDI_CB_EOA | COMEDI_CB_OVERFLOW;
-   printk("daqp: data lost\n");
+   dev_warn(dev->class_dev, "data lost\n");
daqp_ai_cancel(dev, s);
break;
}
@@ -398,7 +398,8 @@ static int daqp_ai_insn_read(struct comedi_device *dev,
   && (inb(dev->iobase + DAQP_STATUS) & DAQP_STATUS_EVENTS))
;
if (!counter) {
-   printk("daqp: couldn't clear interrupts in status register\n");
+   dev_err(dev->class_dev,
+   "couldn't clear interrupts in status register\n");
return -1;
}
 
@@ -824,8 +825,8 @@ static int daqp_attach(struct comedi_device *dev, struct 
comedi_devconfig *it)
struct comedi_subdevice *s;
 
if (it->options[0] < 0 || it->options[0] >= MAX_DEV || !local) {
-   printk("comedi%d: No such daqp device %d\n",
-  dev->minor, it->options[0]);
+   dev_err(dev->class_dev, "No such daqp device %d\n",
+   it->options[0]);
return -EIO;
}
 
-- 
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 1/2] staging/comedi: Fix trailing statements should be on next line in drivers/quatech_daqp_cs.c

[YAMANE Toshiaki]

fixed below checkpatch errors.
- ERROR: trailing statements should be on next line

Signed-off-by: YAMANE Toshiaki 
---
 drivers/staging/comedi/drivers/quatech_daqp_cs.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c 
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index d15bd8a..806523c 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -395,7 +395,8 @@ static int daqp_ai_insn_read(struct comedi_device *dev,
 */
 
while (--counter
-  && (inb(dev->iobase + DAQP_STATUS) & DAQP_STATUS_EVENTS)) ;
+  && (inb(dev->iobase + DAQP_STATUS) & DAQP_STATUS_EVENTS))
+   ;
if (!counter) {
printk("daqp: couldn't clear interrupts in status register\n");
return -1;
@@ -732,7 +733,8 @@ static int daqp_ai_cmd(struct comedi_device *dev, struct 
comedi_subdevice *s)
 */
counter = 100;
while (--counter
-  && (inb(dev->iobase + DAQP_STATUS) & DAQP_STATUS_EVENTS)) ;
+  && (inb(dev->iobase + DAQP_STATUS) & DAQP_STATUS_EVENTS))
+   ;
if (!counter) {
dev_err(dev->class_dev,
"couldn't clear interrupts in status register\n");
-- 
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.7-rc1] omap zoom2.c: Fix compile error by including correct header files

[Mark Brown]

On Wed, Oct 03, 2012 at 09:31:02AM -0700, Tony Lindgren wrote:

> Actually we can also drop "#include " too,
> it's now empty for mach-omap2. I've updated Tim's patch below
> for you guys to queue via the ASoC fixes. It's against the
> current linux next.

Applied.  Tim, you should send patches using subject lines appropriate
for the subsystem you're submitting against *especially* if the patch is
to be deferred for some future time as it makes it harder to search for
the patch.  If your changelog looks different to the other changelogs
for the thing you're patching that should be a warning.


signature.asc
Description: Digital signature

Re: [PATCH] gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios

[Mark Brown]

On Fri, Oct 26, 2012 at 09:26:33AM +0200, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 1:03 PM, Mathias Nyman

> > gpios requested with invalid numbers, or gpios requested from userspace via 
> > sysfs
> > should not try to be deferred on failure.

> Very good catch. I applied this to my fixes branch and also
> put the stable tag on this thing, it goes way back to the introduction
> of deffered probe.

> Mark: OK with this?

The invalid numbers thing I'm a bit meh on.  It came up before and I
personally wasn't sure if the issue wasn't with gpio_is_valid() only
checking for "this number could possibly ever be a GPIO" and not doing
any checking against the GPIOs that have actually been registered.  If
it's the former then ideally at some point in the future we'll remove
the big table and gpio_is_valid() will always be true.


signature.asc
Description: Digital signature

Re: [PATCH v2 2/4] gpio: add viperboard gpio driver

[Mark Brown]

On Sat, Oct 27, 2012 at 06:14:16PM +0200, Linus Walleij wrote:

> I think you've done an honest effort (more than most would do for sure)
> to explore the ways of the regmap. If it doesn't fit, it doesn't fit and
> that's it.

The bus stuff is needed by a bunch of other drivers - there's a similar
thing with SI476x for example.  We should have support for providing I/O
functions as part of the regmap config for drivers that don't need the
data formatting down into a byte stream.


signature.asc
Description: Digital signature

Re: [PATCH v3 2/6] Add the main bulk of core driver for SI476x code

[Mark Brown]

On Thu, Oct 25, 2012 at 03:26:02PM -0700, Andrey Smirnov wrote:
> On 10/25/2012 12:45 PM, Mark Brown wrote:

> > This really makes little sense to me, why are you doing this?  Does the
> > device *really* layer a byte stream on top of I2C for sending messages
> > that look like marshalled register reads and writes?

> The SI476x chips has a concept of a "property". Each property having
> 16-bit address and 16-bit value. At least a portion of a chip
> configuration is done by modifying those properties. In order to

Right, that's what I remembered from previous code.  There's no way this
should be a regmap bus - a bus is something that gets data serialised by
the core into a byte stream, having the data rendered down into a byte
stream and then reparsing it is a bit silly.  The device should be
hooking in before the data gets marshalled which we can't currently do
but it shouldn't be too hard to make it so that we can have register
read and write functions supplied in the regmap config.

> Also due to the way the driver uses the chip it is only powered up when
> the corresponding file in devfs(e.g. /dev/radio0) is opened at least by
> one user which means that unless there is a user who opened the file all
> the SET/GET_PROPERTY commands sent to it will be lost. The codec driver
> for that chip does not have any say in the power management policy(while
> all the audio configuration is done via "properties") if the chip is not
> powered up the driver has to cache the configuration values it has so
> that they can be applied later.

This is very normal, indeed modern CODEC drivers can leave the chip
powered down whenever it's not performing some function.

> So, since I have to implement a caching functionality in the driver, in
> order to avoid reinventing the wheel I opted for using 'regmap' API for
> this.

> Of course, It is possible that I misunderstood the purpose and
> capabilities of the 'regmap' framework, which would make my code look
> very silly indeed. If that is the case I'll just re-implement it using
> some sort of ad-hoc version of caching.

No, what you're doing is totally sensible.  It needs a bit of extension
to the framework before you can do it though.


signature.asc
Description: Digital signature

[PATCH 0/2] mm: do not call frontswap_init() during swapoff

[Cesar Eduardo Barros]

The call to frontswap_init() was added in a place where it is called not
only from sys_swapon, but also from sys_swapoff. This pair of patches
fixes that.

The first patch moves the acquisition of swap_lock from enable_swap_info
to two separate helpers, one for sys_swapon and one for sys_swapoff. As
a bonus, it also makes the code for sys_swapoff less subtle.

The second patch moves the call to frontswap_init() from the common code
to the helper used only by sys_swapon.

Compile-tested only, but should be safe.

Cesar Eduardo Barros (2):
  mm: refactor reinsert of swap_info in sys_swapoff
  mm: do not call frontswap_init() during swapoff

 mm/swapfile.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

-- 
1.7.11.7

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

[PATCH 1/2] mm: refactor reinsert of swap_info in sys_swapoff

[Cesar Eduardo Barros]

The block within sys_swapoff which re-inserts the swap_info into the
swap_list in case of failure of try_to_unuse() reads a few values outside
the swap_lock. While this is safe at that point, it is subtle code.

Simplify the code by moving the reading of these values to a separate
function, refactoring it a bit so they are read from within the
swap_lock. This is easier to understand, and matches better the way it
worked before I unified the insertion of the swap_info from both
sys_swapon and sys_swapoff.

This change should make no functional difference. The only real change
is moving the read of two or three structure fields to within the lock
(frontswap_map_get() is nothing more than a read of p->frontswap_map).

Signed-off-by: Cesar Eduardo Barros 
---
 mm/swapfile.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 71cd288..886db96 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1443,13 +1443,12 @@ static int setup_swap_extents(struct swap_info_struct 
*sis, sector_t *span)
return generic_swapfile_activate(sis, swap_file, span);
 }
 
-static void enable_swap_info(struct swap_info_struct *p, int prio,
+static void _enable_swap_info(struct swap_info_struct *p, int prio,
unsigned char *swap_map,
unsigned long *frontswap_map)
 {
int i, prev;
 
-   spin_lock(_lock);
if (prio >= 0)
p->prio = prio;
else
@@ -1473,6 +1472,21 @@ static void enable_swap_info(struct swap_info_struct *p, 
int prio,
else
swap_info[prev]->next = p->type;
frontswap_init(p->type);
+}
+
+static void enable_swap_info(struct swap_info_struct *p, int prio,
+   unsigned char *swap_map,
+   unsigned long *frontswap_map)
+{
+   spin_lock(_lock);
+   _enable_swap_info(p, prio, swap_map, frontswap_map);
+   spin_unlock(_lock);
+}
+
+static void reinsert_swap_info(struct swap_info_struct *p)
+{
+   spin_lock(_lock);
+   _enable_swap_info(p, p->prio, p->swap_map, frontswap_map_get(p));
spin_unlock(_lock);
 }
 
@@ -1549,14 +1563,8 @@ SYSCALL_DEFINE1(swapoff, const char __user *, 
specialfile)
compare_swap_oom_score_adj(OOM_SCORE_ADJ_MAX, oom_score_adj);
 
if (err) {
-   /*
-* reading p->prio and p->swap_map outside the lock is
-* safe here because only sys_swapon and sys_swapoff
-* change them, and there can be no other sys_swapon or
-* sys_swapoff for this swap_info_struct at this point.
-*/
/* re-insert swap space back into swap_list */
-   enable_swap_info(p, p->prio, p->swap_map, frontswap_map_get(p));
+   reinsert_swap_info(p);
goto out_dput;
}
 
-- 
1.7.11.7

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

[GIT PULL] MXS SPI fixes for v3.7

[Mark Brown]

The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git tags/spi-mxs

for you to fetch changes up to 44968466cfb969f960dbe422bbc785117f497729:

  spi: mxs: Terminate DMA in case of DMA timeout (2012-10-17 16:11:09 +0900)


spi: Some minor MXS fixes

These fixes are both pretty minor ones and are driver local.


Marek Vasut (2):
  spi: mxs: Assign message status after transfer finished
  spi: mxs: Terminate DMA in case of DMA timeout

 drivers/spi/spi-mxs.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


signature.asc
Description: Digital signature

[PATCH 2/2] mm: do not call frontswap_init() during swapoff

[Cesar Eduardo Barros]

The call to frontswap_init() was added within enable_swap_info(), which
was called not only during sys_swapon, but also to reinsert the
swap_info into the swap_list in case of failure of try_to_unuse() within
sys_swapoff. This means that frontswap_init() might be called more than
once for the same swap area.

While as far as I could see no frontswap implementation has any problem
with it (and in fact, all the ones I found ignore the parameter passed
to frontswap_init), this could change in the future.

To prevent future problems, move the call to frontswap_init() to outside
the code shared between sys_swapon and sys_swapoff.

Cc: Konrad Rzeszutek Wilk 
Cc: Dan Magenheimer 
Signed-off-by: Cesar Eduardo Barros 
---
 mm/swapfile.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 886db96..088daf4 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1471,7 +1471,6 @@ static void _enable_swap_info(struct swap_info_struct *p, 
int prio,
swap_list.head = swap_list.next = p->type;
else
swap_info[prev]->next = p->type;
-   frontswap_init(p->type);
 }
 
 static void enable_swap_info(struct swap_info_struct *p, int prio,
@@ -1480,6 +1479,7 @@ static void enable_swap_info(struct swap_info_struct *p, 
int prio,
 {
spin_lock(_lock);
_enable_swap_info(p, prio, swap_map, frontswap_map);
+   frontswap_init(p->type);
spin_unlock(_lock);
 }
 
-- 
1.7.11.7

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

[PATCH 4/5] perf tool: Move strxfrchar into string object

[Jiri Olsa]

Moving strxfrchar function into string object.

Signed-off-by: Jiri Olsa 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/util/string.c | 18 ++
 tools/perf/util/symbol.c | 10 --
 tools/perf/util/symbol.h |  2 --
 tools/perf/util/util.h   |  1 +
 4 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index 3217059..346707d 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -314,6 +314,24 @@ int strtailcmp(const char *s1, const char *s2)
 }
 
 /**
+ * strxfrchar - Locate and replace character in @s
+ * @s:The string to be searched/changed.
+ * @from: Source character to be replaced.
+ * @to:   Destination character.
+ *
+ * Return pointer to the changed string.
+ */
+char *strxfrchar(char *s, char from, char to)
+{
+   char *p = s;
+
+   while ((p = strchr(p, from)) != NULL)
+   *p++ = to;
+
+   return s;
+}
+
+/**
  * rtrim - Removes trailing whitespace from @s.
  * @s: The string to be stripped.
  *
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 08b8257..d3b1ecc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2050,16 +2050,6 @@ int machines__create_kernel_maps(struct rb_root 
*machines, pid_t pid)
return machine__create_kernel_maps(machine);
 }
 
-char *strxfrchar(char *s, char from, char to)
-{
-   char *p = s;
-
-   while ((p = strchr(p, from)) != NULL)
-   *p++ = to;
-
-   return s;
-}
-
 int machines__create_guest_kernel_maps(struct rb_root *machines)
 {
int ret = 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index bc34dc1..45d3df8 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -40,8 +40,6 @@ static inline char *bfd_demangle(void __maybe_unused *v,
 #endif
 #endif
 
-char *strxfrchar(char *s, char from, char to);
-
 /*
  * libelf 0.8.x and earlier do not support ELF_C_READ_MMAP;
  * for newer versions we can use mmap to reduce memory usage:
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index d6c22c5..c233091 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -240,6 +240,7 @@ void argv_free(char **argv);
 bool strglobmatch(const char *str, const char *pat);
 bool strlazymatch(const char *str, const char *pat);
 int strtailcmp(const char *s1, const char *s2);
+char *strxfrchar(char *s, char from, char to);
 unsigned long convert_unit(unsigned long value, char *unit);
 int readn(int fd, void *buf, size_t size);
 
-- 
1.7.11.7

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

Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

[Eric Sandeen]

On 10/27/12 1:47 PM, Nix wrote:
> On 27 Oct 2012, Theodore Ts'o said:
> 
>> On Sat, Oct 27, 2012 at 01:45:25PM +0100, Nix wrote:
>>> Ah! it's turned on by journal_async_commit. OK, that alone argues
>>> against use of journal_async_commit, tested or not, and I'd not have
>>> turned it on if I'd noticed that.
>>>
>>> (So, the combinations I'll be trying for effect on this bug are:
>>>
>>>  journal_async_commit (as now)
>>>  journal_checksum
>>>  none
>>
>> Can you also check and see whether the presence or absence of
>> "nobarrier" makes a difference?
> 
> Done. (Also checked the effect of your patches posted earlier this week:
> no effect, I'm afraid, certainly not under the fails-even-on-3.6.1 test
> I was carrying out, umount -l'ing /var as the very last thing I did
> before /sbin/reboot -f.)
> 
> nobarrier makes a difference that I, at least, did not expect:
> 
> [no options]No corruption
> 
> nobarrier   No corruption
> 
>   journal_checksum  Corruption
> Corrupted transaction, journal aborted
> 
> nobarrier,journal_checksum  Corruption
> Corrupted transaction, journal aborted
> 
>   journal_async_commit  Corruption
> Corrupted transaction, journal aborted
> 
> nobarrier,journal_async_commit  Corruption
> No corrupted transaction or aborted journal

That's what we needed.  Woulda been great a few days ago ;)

In my testing journal_checksum is broken, and my bisection seems to
implicate

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31
Author: Theodore Ts'o 
Date:   Mon Feb 6 20:12:03 2012 -0500

ext4: fold ext4_claim_inode into ext4_new_inode

as the culprit.  I haven't had time to look into why, yet.

-Eric

> I didn't expect the last case at all, and it adequately explains why you
> are mostly seeing corrupted journal messages in your tests but I was
> not. It also explains why when I saw this for the first time I was able
> to mount the resulting corrupted filesystem read-write and corrupt it
> further before I noticed that anything was wrong.
> 
> It is also clear that journal_checksum and all that relies on it is
> worse than useless right now, as Eric reported while I was testing this.
> It should probably be marked CONFIG_BROKEN in future 3.[346].* stable
> kernels, if CONFIG_BROKEN existed anymore, which it doesn't.
> 
> It's a shame journal_async_commit depends on a broken feature: it might
> be notionally unsafe but on some of my systems (without nobarrier or
> flashy caching controllers) it was associated with a noticeable speedup
> of metadata-heavy workloads -- though that was way back in 2009...
> however, "safety first" definitely applies in this case.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf dso: Separate dso symbols to separate object

[Jiri Olsa]

hi,
separating dso related stuff into dso object plus some other symbol
object cleanup. It's just a code moving, no actual change was done.

Attached patches:
  1/5 perf tool: Move build_id__sprintf into build-id object
  2/5 perf tool: Move BUILD_ID_SIZE into build-id object
  3/5 perf tool: Move hex2u64 into util object
  4/5 perf tool: Move strxfrchar into string object
  5/5 perf tool: Move dso_* related functions into dso object

Also available in:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/linux.git
perf/dso1

thanks,
jirka

Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile|   2 +
 tools/perf/builtin-buildid-cache.c |   1 +
 tools/perf/util/annotate.c |   1 +
 tools/perf/util/build-id.c |  15 ++
 tools/perf/util/build-id.h |   7 +-
 tools/perf/util/dso.c  | 594 

 tools/perf/util/dso.h  | 148 +++
 tools/perf/util/event.h|   3 +-
 tools/perf/util/header.c   |   1 +
 tools/perf/util/map.c  |   1 +
 tools/perf/util/string.c   |  18 ++
 tools/perf/util/symbol.c   | 657 
+--
 tools/perf/util/symbol.h   | 141 +--
 tools/perf/util/util.c |  33 
 tools/perf/util/util.h |   2 +
 15 files changed, 831 insertions(+), 793 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/

[PATCH 3/5] perf tool: Move hex2u64 into util object

[Jiri Olsa]

Moving hex2u64 function into util object.

Signed-off-by: Jiri Olsa 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/util/symbol.c | 33 -
 tools/perf/util/symbol.h |  1 -
 tools/perf/util/util.c   | 33 +
 tools/perf/util/util.h   |  1 +
 4 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e36e8c2..08b8257 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -2050,39 +2050,6 @@ int machines__create_kernel_maps(struct rb_root 
*machines, pid_t pid)
return machine__create_kernel_maps(machine);
 }
 
-static int hex(char ch)
-{
-   if ((ch >= '0') && (ch <= '9'))
-   return ch - '0';
-   if ((ch >= 'a') && (ch <= 'f'))
-   return ch - 'a' + 10;
-   if ((ch >= 'A') && (ch <= 'F'))
-   return ch - 'A' + 10;
-   return -1;
-}
-
-/*
- * While we find nice hex chars, build a long_val.
- * Return number of chars processed.
- */
-int hex2u64(const char *ptr, u64 *long_val)
-{
-   const char *p = ptr;
-   *long_val = 0;
-
-   while (*p) {
-   const int hex_val = hex(*p);
-
-   if (hex_val < 0)
-   break;
-
-   *long_val = (*long_val << 4) | hex_val;
-   p++;
-   }
-
-   return p - ptr;
-}
-
 char *strxfrchar(char *s, char from, char to)
 {
char *p = s;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 6eb7d3b..bc34dc1 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -40,7 +40,6 @@ static inline char *bfd_demangle(void __maybe_unused *v,
 #endif
 #endif
 
-int hex2u64(const char *ptr, u64 *val);
 char *strxfrchar(char *s, char from, char to);
 
 /*
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 637b5cc..5906e84 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -166,6 +166,39 @@ size_t hex_width(u64 v)
return n;
 }
 
+static int hex(char ch)
+{
+   if ((ch >= '0') && (ch <= '9'))
+   return ch - '0';
+   if ((ch >= 'a') && (ch <= 'f'))
+   return ch - 'a' + 10;
+   if ((ch >= 'A') && (ch <= 'F'))
+   return ch - 'A' + 10;
+   return -1;
+}
+
+/*
+ * While we find nice hex chars, build a long_val.
+ * Return number of chars processed.
+ */
+int hex2u64(const char *ptr, u64 *long_val)
+{
+   const char *p = ptr;
+   *long_val = 0;
+
+   while (*p) {
+   const int hex_val = hex(*p);
+
+   if (hex_val < 0)
+   break;
+
+   *long_val = (*long_val << 4) | hex_val;
+   p++;
+   }
+
+   return p - ptr;
+}
+
 /* Obtain a backtrace and print it to stdout. */
 #ifdef BACKTRACE_SUPPORT
 void dump_stack(void)
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index 0d85209..d6c22c5 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -262,6 +262,7 @@ bool is_power_of_2(unsigned long n)
 }
 
 size_t hex_width(u64 v);
+int hex2u64(const char *ptr, u64 *val);
 
 char *rtrim(char *s);
 
-- 
1.7.11.7

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

[PATCH 1/5] perf tool: Move build_id__sprintf into build-id object

[Jiri Olsa]

Moving build_id__sprintf function into build-id object.

Signed-off-by: Jiri Olsa 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-buildid-cache.c |  2 +-
 tools/perf/util/build-id.c | 15 +++
 tools/perf/util/build-id.h |  1 +
 tools/perf/util/header.c   |  1 +
 tools/perf/util/map.c  |  1 +
 tools/perf/util/symbol.c   | 15 ---
 tools/perf/util/symbol.h   |  1 -
 7 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/tools/perf/builtin-buildid-cache.c 
b/tools/perf/builtin-buildid-cache.c
index d37e077..edb26ea 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -13,7 +13,7 @@
 #include "util/header.h"
 #include "util/parse-options.h"
 #include "util/strlist.h"
-#include "util/symbol.h"
+#include "util/build-id.h"
 
 static int build_id_cache__add_file(const char *filename, const char *debugdir)
 {
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index 94ca117..5295625 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -70,6 +70,21 @@ struct perf_tool build_id__mark_dso_hit_ops = {
.build_id= perf_event__process_build_id,
 };
 
+int build_id__sprintf(const u8 *build_id, int len, char *bf)
+{
+   char *bid = bf;
+   const u8 *raw = build_id;
+   int i;
+
+   for (i = 0; i < len; ++i) {
+   sprintf(bid, "%02x", *raw);
+   ++raw;
+   bid += 2;
+   }
+
+   return raw - build_id;
+}
+
 char *dso__build_id_filename(struct dso *self, char *bf, size_t size)
 {
char build_id_hex[BUILD_ID_SIZE * 2 + 1];
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 45c500b..f6d9ff9 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -5,6 +5,7 @@
 
 extern struct perf_tool build_id__mark_dso_hit_ops;
 
+int build_id__sprintf(const u8 *build_id, int len, char *bf);
 char *dso__build_id_filename(struct dso *self, char *bf, size_t size);
 
 int build_id__mark_dso_hit(struct perf_tool *tool, union perf_event *event,
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 7daad23..514ed1b 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -23,6 +23,7 @@
 #include "pmu.h"
 #include "vdso.h"
 #include "strbuf.h"
+#include "build-id.h"
 
 static bool no_buildid_cache = false;
 
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 6109fa4..9b40c44 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -10,6 +10,7 @@
 #include "thread.h"
 #include "strlist.h"
 #include "vdso.h"
+#include "build-id.h"
 
 const char *map_type__name[MAP__NR_TYPES] = {
[MAP__FUNCTION] = "Functions",
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e2e8c69..e36e8c2 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -504,21 +504,6 @@ void dso__sort_by_name(struct dso *dso, enum map_type type)
 >symbols[type]);
 }
 
-int build_id__sprintf(const u8 *build_id, int len, char *bf)
-{
-   char *bid = bf;
-   const u8 *raw = build_id;
-   int i;
-
-   for (i = 0; i < len; ++i) {
-   sprintf(bid, "%02x", *raw);
-   ++raw;
-   bid += 2;
-   }
-
-   return raw - build_id;
-}
-
 size_t dso__fprintf_buildid(struct dso *dso, FILE *fp)
 {
char sbuild_id[BUILD_ID_SIZE * 2 + 1];
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 8b6ef7f..d70f676 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -338,7 +338,6 @@ struct symbol *dso__find_symbol_by_name(struct dso *dso, 
enum map_type type,
 int filename__read_build_id(const char *filename, void *bf, size_t size);
 int sysfs__read_build_id(const char *filename, void *bf, size_t size);
 bool __dsos__read_build_ids(struct list_head *head, bool with_hits);
-int build_id__sprintf(const u8 *build_id, int len, char *bf);
 int kallsyms__parse(const char *filename, void *arg,
int (*process_symbol)(void *arg, const char *name,
  char type, u64 start));
-- 
1.7.11.7

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

[PATCH 5/5] perf tool: Move dso_* related functions into dso object

[Jiri Olsa]

Moving dso_* related functions into dso object.

Keeping symbol loading related functions still in the symbol
object as it seems more convenient.

Signed-off-by: Jiri Olsa 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile  |   2 +
 tools/perf/util/dso.c| 594 ++
 tools/perf/util/dso.h| 148 
 tools/perf/util/symbol.c | 599 +--
 tools/perf/util/symbol.h | 134 +--
 5 files changed, 751 insertions(+), 726 deletions(-)
 create mode 100644 tools/perf/util/dso.c
 create mode 100644 tools/perf/util/dso.h

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 629fc6a..ec63d53 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -327,6 +327,7 @@ LIB_H += util/svghelper.h
 LIB_H += util/tool.h
 LIB_H += util/run-command.h
 LIB_H += util/sigchain.h
+LIB_H += util/dso.h
 LIB_H += util/symbol.h
 LIB_H += util/color.h
 LIB_H += util/values.h
@@ -385,6 +386,7 @@ LIB_OBJS += $(OUTPUT)util/top.o
 LIB_OBJS += $(OUTPUT)util/usage.o
 LIB_OBJS += $(OUTPUT)util/wrapper.o
 LIB_OBJS += $(OUTPUT)util/sigchain.o
+LIB_OBJS += $(OUTPUT)util/dso.o
 LIB_OBJS += $(OUTPUT)util/symbol.o
 LIB_OBJS += $(OUTPUT)util/symbol-elf.o
 LIB_OBJS += $(OUTPUT)util/dso-test-data.o
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
new file mode 100644
index 000..bec91fd
--- /dev/null
+++ b/tools/perf/util/dso.c
@@ -0,0 +1,594 @@
+#include 
+#include "dso.h"
+#include "util.h"
+#include "debug.h"
+
+char dso__symtab_origin(const struct dso *dso)
+{
+   static const char origin[] = {
+   [DSO_BINARY_TYPE__KALLSYMS] = 'k',
+   [DSO_BINARY_TYPE__VMLINUX]  = 'v',
+   [DSO_BINARY_TYPE__JAVA_JIT] = 'j',
+   [DSO_BINARY_TYPE__DEBUGLINK]= 'l',
+   [DSO_BINARY_TYPE__BUILD_ID_CACHE]   = 'B',
+   [DSO_BINARY_TYPE__FEDORA_DEBUGINFO] = 'f',
+   [DSO_BINARY_TYPE__UBUNTU_DEBUGINFO] = 'u',
+   [DSO_BINARY_TYPE__BUILDID_DEBUGINFO]= 'b',
+   [DSO_BINARY_TYPE__SYSTEM_PATH_DSO]  = 'd',
+   [DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE]  = 'K',
+   [DSO_BINARY_TYPE__GUEST_KALLSYMS]   = 'g',
+   [DSO_BINARY_TYPE__GUEST_KMODULE]= 'G',
+   [DSO_BINARY_TYPE__GUEST_VMLINUX]= 'V',
+   };
+
+   if (dso == NULL || dso->symtab_type == DSO_BINARY_TYPE__NOT_FOUND)
+   return '!';
+   return origin[dso->symtab_type];
+}
+
+int dso__binary_type_file(struct dso *dso, enum dso_binary_type type,
+ char *root_dir, char *file, size_t size)
+{
+   char build_id_hex[BUILD_ID_SIZE * 2 + 1];
+   int ret = 0;
+
+   switch (type) {
+   case DSO_BINARY_TYPE__DEBUGLINK: {
+   char *debuglink;
+
+   strncpy(file, dso->long_name, size);
+   debuglink = file + dso->long_name_len;
+   while (debuglink != file && *debuglink != '/')
+   debuglink--;
+   if (*debuglink == '/')
+   debuglink++;
+   filename__read_debuglink(dso->long_name, debuglink,
+size - (debuglink - file));
+   }
+   break;
+   case DSO_BINARY_TYPE__BUILD_ID_CACHE:
+   /* skip the locally configured cache if a symfs is given */
+   if (symbol_conf.symfs[0] ||
+   (dso__build_id_filename(dso, file, size) == NULL))
+   ret = -1;
+   break;
+
+   case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
+   snprintf(file, size, "%s/usr/lib/debug%s.debug",
+symbol_conf.symfs, dso->long_name);
+   break;
+
+   case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
+   snprintf(file, size, "%s/usr/lib/debug%s",
+symbol_conf.symfs, dso->long_name);
+   break;
+
+   case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
+   if (!dso->has_build_id) {
+   ret = -1;
+   break;
+   }
+
+   build_id__sprintf(dso->build_id,
+ sizeof(dso->build_id),
+ build_id_hex);
+   snprintf(file, size,
+"%s/usr/lib/debug/.build-id/%.2s/%s.debug",
+symbol_conf.symfs, build_id_hex, build_id_hex + 2);
+   break;
+
+   case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
+   snprintf(file, size, "%s%s",
+symbol_conf.symfs, dso->long_name);
+   break;
+
+   case DSO_BINARY_TYPE__GUEST_KMODULE:
+   snprintf(file, size, "%s%s%s", 

[PATCH 2/5] perf tool: Move BUILD_ID_SIZE into build-id object

[Jiri Olsa]

Moving BUILD_ID_SIZE define into build-id object,
plus include related changes.

Signed-off-by: Jiri Olsa 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-buildid-cache.c | 1 +
 tools/perf/util/annotate.c | 1 +
 tools/perf/util/build-id.h | 6 +-
 tools/perf/util/event.h| 3 +--
 tools/perf/util/symbol.h   | 3 +--
 5 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-buildid-cache.c 
b/tools/perf/builtin-buildid-cache.c
index edb26ea..fae8b25 100644
--- a/tools/perf/builtin-buildid-cache.c
+++ b/tools/perf/builtin-buildid-cache.c
@@ -14,6 +14,7 @@
 #include "util/parse-options.h"
 #include "util/strlist.h"
 #include "util/build-id.h"
+#include "util/symbol.h"
 
 static int build_id_cache__add_file(const char *filename, const char *debugdir)
 {
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index f0a9103..7a34dd1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -15,6 +15,7 @@
 #include "debug.h"
 #include "annotate.h"
 #include 
+#include 
 
 const char *disassembler_style;
 const char *objdump_path;
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index f6d9ff9..a811f5c 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -1,9 +1,13 @@
 #ifndef PERF_BUILD_ID_H_
 #define PERF_BUILD_ID_H_ 1
 
-#include "session.h"
+#define BUILD_ID_SIZE 20
+
+#include "tool.h"
+#include "types.h"
 
 extern struct perf_tool build_id__mark_dso_hit_ops;
+struct dso;
 
 int build_id__sprintf(const u8 *build_id, int len, char *bf);
 char *dso__build_id_filename(struct dso *self, char *bf, size_t size);
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index da97aff..0d573ff 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -6,6 +6,7 @@
 
 #include "../perf.h"
 #include "map.h"
+#include "build-id.h"
 
 /*
  * PERF_SAMPLE_IP | PERF_SAMPLE_TID | *
@@ -96,8 +97,6 @@ struct perf_sample {
struct stack_dump user_stack;
 };
 
-#define BUILD_ID_SIZE 20
-
 struct build_id_event {
struct perf_event_header header;
pid_tpid;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d70f676..6eb7d3b 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include "build-id.h"
 
 #ifdef LIBELF_SUPPORT
 #include 
@@ -57,8 +58,6 @@ char *strxfrchar(char *s, char from, char to);
 #define DMGL_ANSI(1 << 1)   /* Include const, volatile, etc */
 #endif
 
-#define BUILD_ID_SIZE 20
-
 /** struct symbol - symtab entry
  *
  * @ignore - resolvable but tools ignore it (e.g. idle routines)
-- 
1.7.11.7

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

Re: [PATCH] regmap: Fix printing of size_t variable

[Mark Brown]

On Thu, Oct 25, 2012 at 03:52:32PM -0700, Randy Dunlap wrote:

> Acked-by: Randy Dunlap 

There's not much point in doing this after a patch has been applied...

> http://marc.info/?l=linux-kernel=135041943424273=2

So, the difference between Fabio's patch and your patch is that he sent
the patch in the normal fashion and didn't do the random extra stuff I
keep mentioning when I apply your patches.  The things you do like the
random recipient lists and CCs in the text of the mail get in the way
and mean that for things like minor warning fixes the patch is likely to
get deferred for a big mailbox cleanup or (like this time) superceeded
by a version that's easier to deal with.


signature.asc
Description: Digital signature

Re: [ 60/85] xtensa: add missing system calls to the syscall table

[Chris Zankel]

Hi Ben,


On 10/27/2012 11:26 AM, Ben Hutchings wrote:
> On Thu, 2012-10-25 at 17:06 -0700, Greg Kroah-Hartman wrote:
> [...]
>>  #define __NR_available287   287
>> -__SYSCALL(287, sys_faccessat, 0)
>> +__SYSCALL(287, sys_ni_syscall, 0)
> [...]
>
> Why was this one un-plumbed rather than properly numbered (#define
> __NR_faccessat)?
I can only speculate, that this was probably a copy/paste error that has been 
there for a long time. __NR_faccessat is (and was) defined as number 301. Given 
that 287 was never defined, it's save to
fix the table entry and set it to sys_ni_syscall.

unistd.h:
[...]
#define __NR_faccessat  301
__SYSCALL(301, sys_faccessat, 4)
[...]

Thanks,
-Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf parser: does not support arbitrary new sysfs events

[Jiri Olsa]

On Fri, Oct 26, 2012 at 10:23:09PM +0200, Stephane Eranian wrote:
> Hi,
> 
> The latest round of perf parser changes broke my PEBS-LL patch series
> (at the last minute). For PEBS-LL, I need to add to generic events but I want
> to keep them PMU specific. As such, they need to live in the sysfs events
> subdir: /sys/devices/cpu/events/mem-loads, sys/devices/cpu/events/mem-stores.
> 
> Given your latest rounds of sysfs event changes, I had to modify my kernel
> patches to fit those two new events within your perf_pmu_events_attr tables.
> 
> But now, when I try to do:
> 
> $ perf record -e cpu/mem-loads/ 

I can try this only on on uncore events and hw events aliases and that seems to 
work

> 
> I get unsupported event. Looks at the syscall trace, it seems perf does not 
> even
> look into the sysfs subdir to find a possible match. I don't
> understand that. What's
> the point of sysfs event list if it is not used or cannot be extended?
> 
> Note that when I explicitly pass the content of the sysfs file to perf
> record, it
> works:
> 
> $ perf record -e cpu/event=0xcd,umask=0x1,ldlat=3/ ..
> 
> So this is clearly a problem with the lookup in sysfs.
> 
> Also if you have the mappings exposed now in sysfs, why keep the hardcoded
> generic events as well? Or why have those events hardcoded in the parser as
> well.

having perf work on old kernels

> 
> I don't understand all this parser code. I  get the feeling it is
> getting a bit out of
> hands already. But now, I am stuck. So could you fix my parser problem ASAP?

yep, but need more details.. related patches would help

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 33/33] perf, tools: List kernel supplied event aliases in perf list v2

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:15PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> List the kernel supplied pmu event aliases in perf list
> 
> It's better when the users can actually see them.

with the HW events being part of PMU 'events' dir
we get single HW events listed twice

  branch-instructions OR cpu/branch-instructions/[Kernel PMU event]
  branch-misses OR cpu/branch-misses/[Kernel PMU event]
  bus-cycles OR cpu/bus-cycles/  [Kernel PMU event]
  cache-misses OR cpu/cache-misses/  [Kernel PMU event]
  cache-references OR cpu/cache-references/  [Kernel PMU event]
  cpu-cycles OR cpu/cpu-cycles/  [Kernel PMU event]
  instructions OR cpu/instructions/  [Kernel PMU event]
  ref-cycles OR cpu/ref-cycles/  [Kernel PMU event]
  stalled-cycles-backend OR cpu/stalled-cycles-backend/ [Kernel PMU event]
  stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]
  uncore_cbox_0/clockticks/  [Kernel PMU event]
  uncore_cbox_1/clockticks/  [Kernel PMU event]
  uncore_cbox_2/clockticks/  [Kernel PMU event]
  uncore_cbox_3/clockticks/  [Kernel PMU event]


jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] exec: do not leave bprm->interp on stack

[P J P]

+-- On Sat, 27 Oct 2012, Kees Cook wrote --+
| Al showed a list of them earlier in the thread.

  Yeah, the list Al showed and I came across mostly has - binfmt_aout - entry. 
Do people still use - a.out - format? (considering ELF has been the default 
standard for so many years)

| I don't have any on the various distros I checked.

  Same here, my F17 machine has no entries for binfmt- modules, in fact I 
don't even have the /etc/modprobe.d/aliases.conf file.

Documentation/binfmt_misc.txt talks about executing Java, Python, DOSEMU and 
Windows programs which could be supported by loadable modules.

| The problem I see here is that we only want to do module loading in the "no 
| match" case. But that means that either we need to restart with the original 
| bprm, or we need to keep bprm changes off the stack. Leading with a module 
| load is going to wreck performance.  

  I beg to *slightly* differ here. I agree we currently have a small overhead 
of find_module() -> request_module() only when binfmt_ module is already 
loaded, partly because find_module can not resolve aliases.

I guess this small overhead is worth it if it helps to make things less 
confusing and easy to follow. Besides this overhead does not exist for regular 
executables ELFs and scripts alike.

If the required module is missing, a call to request_module() will anyway 
happen and its cost remains the same whether it happens before or after the 
"match".

Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB  C939 D048 7860 3655 602B
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 32/33] perf, tools: Default to cpu// for events v2

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:14PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> When an event fails to parse and it's not in a new style format,
> try to parse it again as a cpu event.
> 
> This allows to use sysfs exported events directly without //, so I can use
> 
> perf record -e tx-aborts ...

hum, seems usefull and hacky ;)

would not work for modifier stuff like:

  tx-aborts:u (not sure if 'u' makes sense for 'tx-aborts'..)

but nevermind, seems like usefull shortcut

> 
> instead of
> 
> perf record -e cpu/tx-aborts/
> 
> v2: Handle multiple events
> Signed-off-by: Andi Kleen 
> ---
>  tools/perf/util/parse-events.c |   37 +
>  1 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index f800765..ee6a73c 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -768,6 +768,23 @@ int parse_events_name(struct list_head *list, char *name)
>   return 0;
>  }
>  
> +static void str_append(char **s, int *len, const char *a)
> +{
> + int olen = *s ? strlen(*s) : 0;
> + int nlen = olen + strlen(a) + 1;
> + if (*len < nlen) { 
> + *len = *len * 2;
> + if (*len < nlen)
> + *len = nlen;
> + *s = realloc(*s, *len);
> + if (!*s) 

trailing whitespace

> + exit(ENOMEM);
> + if (olen == 0)
> + **s = 0;
> + }
> + strcat(*s, a);
> +}
> +
>  static int parse_events__scanner(const char *str, void *data, int 
> start_token)
>  {
>   YY_BUFFER_STATE buffer;
> @@ -788,6 +805,26 @@ static int parse_events__scanner(const char *str, void 
> *data, int start_token)
>   parse_events__flush_buffer(buffer, scanner);
>   parse_events__delete_buffer(buffer, scanner);
>   parse_events_lex_destroy(scanner);
> +
> + if (ret && !strchr(str, '/')) {
> + char *o = strdup(str);
> + char *s = NULL;
> + char *t = o;
> + char *p;
> + int len = 0;
> +
> + if (!o)
> + return ret;
> + while ((p = strsep(, ",")) != NULL) {
> + if (s)
> + str_append(, , ",");
> + str_append(, , "cpu/");
> + str_append(, , p);
> + str_append(, , "/");
> + }
> + free(o);
> + ret = parse_events__scanner(s, data, start_token);

any chance above could be in separated function?

> + }
>   return ret;
>  }
>  
> -- 
> 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 2/2] MAINTAINERS: add pinctrl atmel at91 entry

[Jean-Christophe PLAGNIOL-VILLARD]

Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
---
 MAINTAINERS |6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 027ec2b..cb97031 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5624,6 +5624,12 @@ S:   Maintained
 F: drivers/pinctrl/
 F: include/linux/pinctrl/
 
+PIN CONTROLLER - ATMEL AT91
+M: Jean-Christophe Plagniol-Villard 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/pinctrl/pinctrl-at91.c
+
 PIN CONTROLLER - ST SPEAR
 M: Viresh Kumar 
 L: spear-de...@list.st.com
-- 
1.7.10.4

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

Re: [PATCH 31/33] perf, tools: Support generic events as pmu event names v2

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:13PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Extend the parser/lexer to allow generic event names like
> "instructions" as a sysfs supplied PMU event name.
> 
> This resolves the problem that cpu/instructions/ gives a parse
> error, even when the kernel supplies a "instructions" event
> 
> This is useful to add sysfs specified qualifiers to these
> events, for example cpu/instructions,intx=1/ and needed
> for the TSX events
> 
> Simply extend the grammar to handle this case. The lexer
> needs minor changes to save the original string.

ops, I think you need to check recent changes:

3f3a206 perf test: Add automated tests for pmu sysfs translated events
1d33d6d perf tools: Add support to specify hw event as PMU event term
3fded96 perf tools: Fix PMU object alias initialization
20550a4 perf/x86: Add hardware events translations for Intel P6 cpus
0bf79d4 perf/x86: Add hardware events translations for AMD cpus
43c032f perf/x86: Add hardware events translations for Intel cpus
8300daa perf/x86: Filter out undefined events from sysfs events attribute
a474739 perf/x86: Make hardware event translations available in sysfs

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 27/33] tools, perf: Add a precise event qualifier

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:09PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Add a precise qualifier, like cpu/event=0x3c,precise=1/
hm, I think this works already via 'p' modifier like:
   cpu/event=0x3c/p

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 25/33] perf, tools: Support events with - in the name

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:07PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> - looks nicer than _, so allow - in the event names. Used for various
> of the arch perfmon and Haswell events.
> 
> Signed-off-by: Andi Kleen 
> ---
>  tools/perf/util/parse-events.l |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
> index c87efc1..ef602f0 100644
> --- a/tools/perf/util/parse-events.l
> +++ b/tools/perf/util/parse-events.l
> @@ -80,7 +80,7 @@ event   [^,{}/]+
>  num_dec  [0-9]+
>  num_hex  0x[a-fA-F0-9]+
>  num_raw_hex  [a-fA-F0-9]+
> -name [a-zA-Z_*?][a-zA-Z0-9_*?]*
> +name [a-zA-Z_*?][a-zA-Z0-9\-_*?]*

this breaks cache events parsing since they are '-' separated
and having '-' in 'name' patern will endup with PE_NAME
being matched instead of  PE_NAME_CACHE_* terms

I guess you want '-' being used within 'cpu/..t=v../' terms right?
That could be done via start conditions '%x'

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

[ANNOUNCE] 3.6.3-rt8

[Thomas Gleixner]

Dear RT Folks,

I'm pleased to announce the 3.6.3-rt8 release.

Changes since 3.6.3-rt7:

   * Fix the SLUB fallout on NUMA machines

 I missed to fixup the smp function calls which can result in a
 deadlock on RT.

   * Fix a mainline issue with cpufreq/powernow-k8 (Same patch is
 queued upstream, but one of Carstens test systems stumbled over
 it so I carry that until it hits 3.6.stable)

The delta patch against 3.6.3-rt7 is appended below and can be found
here:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/incr/patch-3.6.3-rt7-rt8.patch.xz

The RT patch against 3.6.3 can be found here:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patch-3.6.3-rt8.patch.xz

The split quilt queue is available at:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/patches-3.6.3-rt8.tar.xz

Enjoy,

tglx

-->
Index: linux-stable/localversion-rt
===
--- linux-stable.orig/localversion-rt
+++ linux-stable/localversion-rt
@@ -1 +1 @@
--rt7
+-rt8
Index: linux-stable/mm/slub.c
===
--- linux-stable.orig/mm/slub.c
+++ linux-stable/mm/slub.c
@@ -1874,10 +1874,10 @@ redo:
  *
  * This function must be called with interrupt disabled.
  */
-static void unfreeze_partials(struct kmem_cache *s)
+static void unfreeze_partials(struct kmem_cache *s, unsigned int cpu)
 {
struct kmem_cache_node *n = NULL, *n2 = NULL;
-   struct kmem_cache_cpu *c = this_cpu_ptr(s->cpu_slab);
+   struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
struct page *page, *discard_page = NULL;
 
while ((page = c->partial)) {
@@ -1963,7 +1963,7 @@ int put_cpu_partial(struct kmem_cache *s
 * set to the per node partial list.
 */
local_lock_irqsave(slub_lock, flags);
-   unfreeze_partials(s);
+   unfreeze_partials(s, smp_processor_id());
local_unlock_irqrestore(slub_lock, flags);
pobjects = 0;
pages = 0;
@@ -2005,17 +2005,10 @@ static inline void __flush_cpu_slab(stru
if (c->page)
flush_slab(s, c);
 
-   unfreeze_partials(s);
+   unfreeze_partials(s, cpu);
}
 }
 
-static void flush_cpu_slab(void *d)
-{
-   struct kmem_cache *s = d;
-
-   __flush_cpu_slab(s, smp_processor_id());
-}
-
 static bool has_cpu_slab(int cpu, void *info)
 {
struct kmem_cache *s = info;
@@ -2024,10 +2017,29 @@ static bool has_cpu_slab(int cpu, void *
return c->page || c->partial;
 }
 
+#ifndef CONFIG_PREEMPT_RT_FULL
+static void flush_cpu_slab(void *d)
+{
+   struct kmem_cache *s = d;
+
+   __flush_cpu_slab(s, smp_processor_id());
+}
+
 static void flush_all(struct kmem_cache *s)
 {
on_each_cpu_cond(has_cpu_slab, flush_cpu_slab, s, 1, GFP_ATOMIC);
 }
+#else
+static void flush_all(struct kmem_cache *s)
+{
+   int cpu;
+
+   for_each_online_cpu(cpu) {
+   if (has_cpu_slab(cpu, s))
+   __flush_cpu_slab(s, cpu);
+   }
+}
+#endif
 
 /*
  * Check if the objects in a per cpu structure fit numa
Index: linux-stable/drivers/cpufreq/powernow-k8.c
===
--- linux-stable.orig/drivers/cpufreq/powernow-k8.c
+++ linux-stable/drivers/cpufreq/powernow-k8.c
@@ -1224,13 +1224,12 @@ static int powernowk8_target(struct cpuf
 .relation = relation };
 
/*
-* Must run on @pol->cpu.  cpufreq core is responsible for ensuring
-* that we're bound to the current CPU and pol->cpu stays online.
+* Must run on @pol->cpu. We queue it on the target cpu even
+* if we are currently on the target cpu. This is preemptible
+* non cpu bound context, so we can't call the target function
+* directly.
 */
-   if (smp_processor_id() == pol->cpu)
-   return powernowk8_target_fn();
-   else
-   return work_on_cpu(pol->cpu, powernowk8_target_fn, );
+   return work_on_cpu(pol->cpu, powernowk8_target_fn, );
 }
 
 /* Driver entry point to verify the policy and range of frequencies */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: powernow-k8: Remove bogus smp_processor_id() usage

[Thomas Gleixner]

On Sat, 27 Oct 2012, Tejun Heo wrote:

> Hello, Thomas.
> 
> On Sat, Oct 27, 2012 at 07:29:25PM +0200, Thomas Gleixner wrote:
> > This is fully preemptible non cpu bound context though the comment in the
> > code says:
> > 
> >  * Must run on @pol->cpu.  cpufreq core is responsible for ensuring
> >  * that we're bound to the current CPU and pol->cpu stays online.
> > 
> > The core only guarantees that pol->cpu stays online, but it has no way
> > to bind the thread and this needs to be fully preemptible context as
> > powernowk8_target_fn() calls functions which might sleep.
> > 
> > So the correct solution is to always go through work_on_cpu().
> 
> Yeah, that was stupid.  Rafael already has a patch queued.
> 
>   
> http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commit;h=e4df1cbcc1f329e53a1fff7450b2229e0addff20
> 

Good. So more people noticed :)

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

Re: [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver

[Fabio Estevam]

Hi Samuel,

On Thu, Oct 4, 2012 at 10:51 AM, Samuel Ortiz  wrote:

>> I want to add mc34708 support to mx53qsb and need this series to be applied.
> I understand. I'll queue it to my for-next branch as soon as the merge window
> is closed.

Could you please queue this series? I still do not see it applied in
your 'for-next-merge' branch.

I will add mc34708 touchscreen support and need Uwe's series to be applied.

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] slub: Use the correct per cpu slab on CPU_DEAD

[Thomas Gleixner]

While making slub available for RT I noticed, that during CPU offline
for each kmem_cache __flush_cpu_slab() is called on a live CPU. This
correctly flushs the cpu_slab of the dead CPU via flush_slab. Though
unfreeze_partials which is called from __flush_cpu_slab() after that
looks at the cpu_slab of the cpu on which this is called. So we fail
to look at the partials of the dead cpu.

Correct this by extending the arguments of unfreeze_partials with the
target cpu number and use per_cpu_ptr instead of this_cpu_ptr.

Signed-off-by: Thomas Gleixner 
---
 mm/slub.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -1874,10 +1874,10 @@ redo:
  *
  * This function must be called with interrupt disabled.
  */
-static void unfreeze_partials(struct kmem_cache *s)
+static void unfreeze_partials(struct kmem_cache *s, unsigned int cpu)
 {
struct kmem_cache_node *n = NULL, *n2 = NULL;
-   struct kmem_cache_cpu *c = this_cpu_ptr(s->cpu_slab);
+   struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
struct page *page, *discard_page = NULL;
 
while ((page = c->partial)) {
@@ -1963,7 +1963,7 @@ static int put_cpu_partial(struct kmem_c
 * set to the per node partial list.
 */
local_irq_save(flags);
-   unfreeze_partials(s);
+   unfreeze_partials(s, smp_processor_id());
local_irq_restore(flags);
oldpage = NULL;
pobjects = 0;
@@ -2006,7 +2006,7 @@ static inline void __flush_cpu_slab(stru
if (c->page)
flush_slab(s, c);
 
-   unfreeze_partials(s);
+   unfreeze_partials(s, cpu);
}
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

[Justin P. Mattock]

On 10/27/2012 06:56 AM, Daniel Vetter wrote:

On Fri, Oct 26, 2012 at 10:57 PM, Justin P. Mattock
 wrote:


:~/drm> git clone git://people.freedesktop.org/~danvet/drm
Cloning into 'drm'...
remote: Counting objects: 2728390, done.
remote: Compressing objects: 100% (418606/418606), done.
remote: Total 2728390 (delta 2293727), reused 2717443 (delta 2282880)
Receiving objects: 100% (2728390/2728390), 637.95 MiB | 599 KiB/s, done.
Resolving deltas: 100% (2293727/2293727), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.


so now I have to go on a witch hunt for 600MB's in my system.


$ git checkout origin/ilk-wa-pile


cool thanks..(not so good at git over here).


... and you have the right branch checked out. No need for pitchforks
and witch hunts ;-)
-Daniel




alright.. putting the pitchfork away for now.

Justin P. Mattock

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: powernow-k8: Remove bogus smp_processor_id() usage

[Tejun Heo]

Hello, Thomas.

On Sat, Oct 27, 2012 at 07:29:25PM +0200, Thomas Gleixner wrote:
> This is fully preemptible non cpu bound context though the comment in the
> code says:
> 
>* Must run on @pol->cpu.  cpufreq core is responsible for ensuring
>* that we're bound to the current CPU and pol->cpu stays online.
> 
> The core only guarantees that pol->cpu stays online, but it has no way
> to bind the thread and this needs to be fully preemptible context as
> powernowk8_target_fn() calls functions which might sleep.
> 
> So the correct solution is to always go through work_on_cpu().

Yeah, that was stupid.  Rafael already has a patch queued.

  
http://git.kernel.org/?p=linux/kernel/git/rafael/linux-pm.git;a=commit;h=e4df1cbcc1f329e53a1fff7450b2229e0addff20

Thanks.

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

Re: [PATCH 24/33] perf, tools: Move parse_events error printing to parse_events_options

[Jiri Olsa]

On Fri, Oct 26, 2012 at 01:30:06PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> The callers of parse_events usually have their own error handling.
> Move the fprintf for a bad event to parse_events_options, which
> is the only one who should need it.
> 
> Signed-off-by: Andi Kleen 
> ---
>  tools/perf/util/parse-events.c |   10 +++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 75c7b0f..409da3e 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -827,8 +827,6 @@ int parse_events(struct perf_evlist *evlist, const char 
> *str,
>* Both call perf_evlist__delete in case of error, so we dont
>* need to bother.
>*/
> - fprintf(stderr, "invalid or unsupported event: '%s'\n", str);
> - fprintf(stderr, "Run 'perf list' for a list of valid events\n");
>   return ret;
>  }
>  
> @@ -836,7 +834,13 @@ int parse_events_option(const struct option *opt, const 
> char *str,
>   int unset __maybe_unused)
>  {
>   struct perf_evlist *evlist = *(struct perf_evlist **)opt->value;
> - return parse_events(evlist, str, unset);
> + int ret = parse_events(evlist, str, unset);
> +
> + if (ret) {
> + fprintf(stderr, "invalid or unsupported event: '%s'\n", str);
> + fprintf(stderr, "Run 'perf list' for a list of valid events\n");
> + }
> + return ret;
>  }
>  
>  int parse_filter(const struct option *opt, const char *str,
> -- 
> 1.7.7.6
> 

Acked-by: Jiri Olsa 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add FDT support to Pandaboard initialization

[Constantine Shulyupin]

From: Constantine Shulyupin 

Problem:
- FDT is supported only by generic OMAP board initialization in 
arch/arm/mach-omap2/board-generic.c and lacks some configurations, which are 
not yet configured in FDT (USB for example).
Solution:
- arch/arm/mach-omap2/board-omap4panda.c supports initialization with FDT and 
without it.

Signed-off-by: Constantine Shulyupin 
---
 arch/arm/mach-omap2/board-omap4panda.c |   33 
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..fea7a83 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -526,3 +527,35 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
.timer  = _timer,
.restart= omap_prcm_restart,
 MACHINE_END
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+   { .compatible = "simple-bus", },
+   { .compatible = "ti,omap-infra", },
+   { }
+};
+
+static void __init panda_dt_init(void)
+{
+   of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+   omap4_panda_init();
+}
+
+static const char *omap4_panda_compat[] __initdata = {
+   "ti,omap4-panda",
+   "ti,omap4",
+   NULL,
+};
+
+DT_MACHINE_START(OMAP4_PANDA_DT, "OMAP4 Pandaboard with FDT support")
+   .dt_compat  = omap4_panda_compat,
+   .reserve= omap_reserve,
+   .smp= smp_ops(omap4_smp_ops),
+   .map_io = omap4_map_io,
+   .init_early = omap4430_init_early,
+   .init_irq   = omap_gic_of_init,
+   .handle_irq = gic_handle_irq,
+   .init_machine   = panda_dt_init,
+   .init_late  = omap4430_init_late,
+   .timer  = _timer,
+   .restart= omap_prcm_restart,
+MACHINE_END
-- 
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] Remove uninitialized_var()

[Andrew Morton]

On Sat, 27 Oct 2012 15:12:03 +0200 Ingo Molnar  wrote:

> There's 3 types of conversions done:
> 
>uninitialized_var(x)=>  x = 0   /* for scalar types */
>uninitialized_var(x)=>  x = NULL/* for pointers */
>uninitialized_var(x)=>  x = { } /* for structures, unions */

It's regrettable that we lose information.  uninitialized_var() says
"this isn't needed - it's just there for gcc".  The reader can of
course work out the reason with careful code inspection, but that's a
lot more time consuming.

We could go add "/* keep gcc quiet */" to every site, or add
self-documenting macros for the above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

[Nix]

On 27 Oct 2012, Theodore Ts'o said:

> On Sat, Oct 27, 2012 at 01:45:25PM +0100, Nix wrote:
>> Ah! it's turned on by journal_async_commit. OK, that alone argues
>> against use of journal_async_commit, tested or not, and I'd not have
>> turned it on if I'd noticed that.
>> 
>> (So, the combinations I'll be trying for effect on this bug are:
>> 
>>  journal_async_commit (as now)
>>  journal_checksum
>>  none
>
> Can you also check and see whether the presence or absence of
> "nobarrier" makes a difference?

Done. (Also checked the effect of your patches posted earlier this week:
no effect, I'm afraid, certainly not under the fails-even-on-3.6.1 test
I was carrying out, umount -l'ing /var as the very last thing I did
before /sbin/reboot -f.)

nobarrier makes a difference that I, at least, did not expect:

[no options]No corruption

nobarrier   No corruption

  journal_checksum  Corruption
Corrupted transaction, journal aborted

nobarrier,journal_checksum  Corruption
Corrupted transaction, journal aborted

  journal_async_commit  Corruption
Corrupted transaction, journal aborted

nobarrier,journal_async_commit  Corruption
No corrupted transaction or aborted journal

I didn't expect the last case at all, and it adequately explains why you
are mostly seeing corrupted journal messages in your tests but I was
not. It also explains why when I saw this for the first time I was able
to mount the resulting corrupted filesystem read-write and corrupt it
further before I noticed that anything was wrong.

It is also clear that journal_checksum and all that relies on it is
worse than useless right now, as Eric reported while I was testing this.
It should probably be marked CONFIG_BROKEN in future 3.[346].* stable
kernels, if CONFIG_BROKEN existed anymore, which it doesn't.

It's a shame journal_async_commit depends on a broken feature: it might
be notionally unsafe but on some of my systems (without nobarrier or
flashy caching controllers) it was associated with a noticeable speedup
of metadata-heavy workloads -- though that was way back in 2009...
however, "safety first" definitely applies in this case.

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

[PATCH 2/2] staging: csr: Remove struct CsrEvent

[SeongJae Park]

No one use struct CsrEvent. So it's unnecessary.

Signed-off-by: SeongJae Park 
---
 drivers/staging/csr/csr_framework_ext_types.h |   12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/staging/csr/csr_framework_ext_types.h 
b/drivers/staging/csr/csr_framework_ext_types.h
index 22340c2..7ad8720 100644
--- a/drivers/staging/csr/csr_framework_ext_types.h
+++ b/drivers/staging/csr/csr_framework_ext_types.h
@@ -24,22 +24,10 @@ extern "C" {
 
 #ifdef __KERNEL__
 
-struct CsrEvent {
-   /* wait_queue for waking the kernel thread */
-   wait_queue_head_t wakeup_q;
-   unsigned int  wakeup_flag;
-};
-
 typedef struct semaphore CsrMutexHandle;
 
 #else /* __KERNEL __ */
 
-struct CsrEvent {
-   pthread_cond_t  event;
-   pthread_mutex_t mutex;
-   u32   eventBits;
-};
-
 typedef pthread_mutex_t CsrMutexHandle;
 
 #endif /* __KERNEL__ */
-- 
1.7.9.5

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

[PATCH 1/2] staging: csr: Remove CsrEventHandle

[SeongJae Park]

No one use CsrEventHandle, No one call functions using it as parameter.
So those are not need to be here.

Signed-off-by: SeongJae Park 
---
 drivers/staging/csr/csr_framework_ext.h   |   61 -
 drivers/staging/csr/csr_framework_ext_types.h |2 -
 2 files changed, 63 deletions(-)

diff --git a/drivers/staging/csr/csr_framework_ext.h 
b/drivers/staging/csr/csr_framework_ext.h
index 16635a9..f1295a1 100644
--- a/drivers/staging/csr/csr_framework_ext.h
+++ b/drivers/staging/csr/csr_framework_ext.h
@@ -36,67 +36,6 @@ extern "C" {
 
 /**
  *  NAME
- *  CsrEventCreate
- *
- *  DESCRIPTION
- *  Creates an event and returns a handle to the created event.
- *
- *  RETURNS
- *  Possible values:
- *  CSR_RESULT_SUCCESS  in case of success
- *  CSR_FE_RESULT_NO_MORE_EVENTS   in case of out of event resources
- *  CSR_FE_RESULT_INVALID_POINTER  in case the eventHandle pointer is 
invalid
- *
- 
**/
-CsrResult CsrEventCreate(CsrEventHandle *eventHandle);
-
-/**
- *  NAME
- *  CsrEventWait
- *
- *  DESCRIPTION
- *  Wait fore one or more of the event bits to be set.
- *
- *  RETURNS
- *  Possible values:
- *  CSR_RESULT_SUCCESS  in case of success
- *  CSR_FE_RESULT_TIMEOUT  in case of timeout
- *  CSR_FE_RESULT_INVALID_HANDLE   in case the eventHandle is 
invalid
- *  CSR_FE_RESULT_INVALID_POINTER  in case the eventBits pointer 
is invalid
- *
- 
**/
-CsrResult CsrEventWait(CsrEventHandle *eventHandle, u16 timeoutInMs, u32 
*eventBits);
-
-/**
- *  NAME
- *  CsrEventSet
- *
- *  DESCRIPTION
- *  Set an event.
- *
- *  RETURNS
- *  Possible values:
- *  CSR_RESULT_SUCCESS  in case of success
- *  CSR_FE_RESULT_INVALID_HANDLE   in case the eventHandle is 
invalid
- *
- 
**/
-CsrResult CsrEventSet(CsrEventHandle *eventHandle, u32 eventBits);
-
-/**
- *  NAME
- *  CsrEventDestroy
- *
- *  DESCRIPTION
- *  Destroy the event associated.
- *
- *  RETURNS
- *  void
- *
- 
**/
-void CsrEventDestroy(CsrEventHandle *eventHandle);
-
-/**
- *  NAME
  *  CsrMutexCreate
  *
  *  DESCRIPTION
diff --git a/drivers/staging/csr/csr_framework_ext_types.h 
b/drivers/staging/csr/csr_framework_ext_types.h
index cd1f877..22340c2 100644
--- a/drivers/staging/csr/csr_framework_ext_types.h
+++ b/drivers/staging/csr/csr_framework_ext_types.h
@@ -30,7 +30,6 @@ struct CsrEvent {
unsigned int  wakeup_flag;
 };
 
-typedef struct CsrEvent CsrEventHandle;
 typedef struct semaphore CsrMutexHandle;
 
 #else /* __KERNEL __ */
@@ -41,7 +40,6 @@ struct CsrEvent {
u32   eventBits;
 };
 
-typedef struct CsrEvent CsrEventHandle;
 typedef pthread_mutex_t CsrMutexHandle;
 
 #endif /* __KERNEL__ */
-- 
1.7.9.5

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

Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

[Eric Sandeen]

On 10/27/12 7:45 AM, Nix wrote:
> [nfs people purged from Cc]
> 
> On 27 Oct 2012, Theodore Ts'o verbalised:
> 
>> Huh?  It's not turned on by default.  If you mount with no mount
>> options, journal checksums are *not* turned on.
> 
> ?! it's turned on for me, and though I use weird mount options I don't
> use that one:

journal_async_commit implies journal_checksum:

{Opt_journal_async_commit, (EXT4_MOUNT_JOURNAL_ASYNC_COMMIT |
EXT4_MOUNT_JOURNAL_CHECKSUM), MOPT_SET},

journal_checksum seems to have broken, at least for me, between 3.3 & 3.4, I 
think I've narrowed down the commit but not sure yet what the flaw is, will 
investigate & report back later.  Busy Saturday.

So anyway, turning on journal_async_commit (notionally unsafe) enables 
journal_checksum (apparently broken).

-Eric

> /dev/main/var   /varext4
> defaults,nobarrier,usrquota,grpquota,nosuid,nodev,relatime,journal_async_commit,commit=30,user_xattr,acl
>  1  2
> Default mount options:(none)
> /dev/mapper/main-var /var ext4 
> rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota,usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota
>  0 0
> 
> ...
> 
> Ah! it's turned on by journal_async_commit. OK, that alone argues
> against use of journal_async_commit, tested or not, and I'd not have
> turned it on if I'd noticed that.
> 
> (So, the combinations I'll be trying for effect on this bug are:
> 
>  journal_async_commit (as now)
>  journal_checksum
>  none
> 
> Technically to investigate all possibilities we should try
> journal_async_commit,no_journal_checksum, but this seems so unlikely to
> have ever been tested by anyone that it's not worth looking into...)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 60/85] xtensa: add missing system calls to the syscall table

[Ben Hutchings]

On Thu, 2012-10-25 at 17:06 -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Chris Zankel 
> 
> commit 7216cabfff5149670445cd65d415ed5db21314b4 upstream.
> 
> Add the following system calls to the syscall table:
[...]
>  #define __NR_available287287
> -__SYSCALL(287, sys_faccessat, 0)
> +__SYSCALL(287, sys_ni_syscall, 0)
[...]

Why was this one un-plumbed rather than properly numbered (#define
__NR_faccessat)?

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

[PATCH] sched, autogroup: fix crash on reboot when autogroup is disabled

[Mike Galbraith]

On Fri, 2012-10-26 at 13:29 -0700, Mike Galbraith wrote: 
> On Sat, 2012-10-20 at 08:38 -0400, Mike Galbraith wrote:
> 
> > So what I would do is either let the user decide once at boot, in which
> > case if off, creating groups would be stupid), or, just rip autogroup
> > completely out, since systemd is taking over the known universe anyway.
> 
> I'm traveling, but have somewhat functional connectivity ATM, so..
> 
> Peter: which would prefer.  Simple noautogroup -> autogroup one time
> only boottime enable, and autogroup lives on (I like it for my laptop)
> with backport for stable.

Like so, with bonus points for extra minus signs.

sched, autogroup: fix crash on reboot when autogroup is disabled

Between 8323f26ce and 800d4d30, autogroup is a wreck.  With both
applied, all you have to do to crash a box is disable autogroup
during boot up, then reboot.. boom, NULL pointer dereference due
to 800d4d30 not allowing autogroup to move things, and 8323f26ce
making that the only way to switch runqueues.

Remove all of the knobs, and make autogroup only go active if the
user provides 'autogroup' on the command line.  This allows distros
to offer it, once the user asks for it, it's on.  If the user then
fiddles with cgroups, tough, once tasks are moved, autogroup won't
mess with them again unless they call setsid().

No knobs, no glitz, nada, just a cute little thing folks can turn
on if they don't want to muck about with cgroups and/or systemd.

Signed-off-by: Mike Galbraith 
Cc: sta...@vger.kernel.org v3.6

---
 Documentation/kernel-parameters.txt |4 -
 fs/proc/base.c  |   78 
 include/linux/sched.h   |2 
 kernel/sched/auto_group.c   |   74 ++
 kernel/sched/auto_group.h   |9 
 kernel/sysctl.c |   11 -
 6 files changed, 17 insertions(+), 161 deletions(-)

--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -367,6 +367,8 @@ bytes respectively. Such letter suffixes
autoconf=   [IPV6]
See Documentation/networking/ipv6.txt.
 
+   autogroup   Enable scheduler automatic task group creation.
+
show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
Limit apic dumping. The parameter defines the maximal
number of local apics being dumped. Also it is possible
@@ -1810,8 +1812,6 @@ bytes respectively. Such letter suffixes
noapic  [SMP,APIC] Tells the kernel to not make use of any
IOAPICs that may be present in the system.
 
-   noautogroup Disable scheduler automatic task group creation.
-
nobats  [PPC] Do not use BATs for mapping kernel lowmem
on "Classic" PPC cores.
 
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1165,81 +1165,6 @@ static const struct file_operations proc
 
 #endif
 
-#ifdef CONFIG_SCHED_AUTOGROUP
-/*
- * Print out autogroup related information:
- */
-static int sched_autogroup_show(struct seq_file *m, void *v)
-{
-   struct inode *inode = m->private;
-   struct task_struct *p;
-
-   p = get_proc_task(inode);
-   if (!p)
-   return -ESRCH;
-   proc_sched_autogroup_show_task(p, m);
-
-   put_task_struct(p);
-
-   return 0;
-}
-
-static ssize_t
-sched_autogroup_write(struct file *file, const char __user *buf,
-   size_t count, loff_t *offset)
-{
-   struct inode *inode = file->f_path.dentry->d_inode;
-   struct task_struct *p;
-   char buffer[PROC_NUMBUF];
-   int nice;
-   int err;
-
-   memset(buffer, 0, sizeof(buffer));
-   if (count > sizeof(buffer) - 1)
-   count = sizeof(buffer) - 1;
-   if (copy_from_user(buffer, buf, count))
-   return -EFAULT;
-
-   err = kstrtoint(strstrip(buffer), 0, );
-   if (err < 0)
-   return err;
-
-   p = get_proc_task(inode);
-   if (!p)
-   return -ESRCH;
-
-   err = proc_sched_autogroup_set_nice(p, nice);
-   if (err)
-   count = err;
-
-   put_task_struct(p);
-
-   return count;
-}
-
-static int sched_autogroup_open(struct inode *inode, struct file *filp)
-{
-   int ret;
-
-   ret = single_open(filp, sched_autogroup_show, NULL);
-   if (!ret) {
-   struct seq_file *m = filp->private_data;
-
-   m->private = inode;
-   }
-   return ret;
-}
-
-static const struct file_operations proc_pid_sched_autogroup_operations = {
-   .open   = sched_autogroup_open,
-   .read   = seq_read,
-   .write  = sched_autogroup_write,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
-
-#endif /* CONFIG_SCHED_AUTOGROUP */
-
 static ssize_t comm_write(struct file *file, const char __user *buf,

[PATCH] PPC: ePAPR: Convert header to uapi

[Alexander Graf]

The new uapi framework splits kernel internal and user space exported
bits of header files more cleanly. Adjust the ePAPR header accordingly.

Signed-off-by: Alexander Graf 
---
 arch/powerpc/include/asm/Kbuild  |1 -
 arch/powerpc/include/asm/epapr_hcalls.h  |   56 +--
 arch/powerpc/include/uapi/asm/Kbuild |1 +
 arch/powerpc/include/uapi/asm/epapr_hcalls.h |   98 ++
 4 files changed, 100 insertions(+), 56 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/epapr_hcalls.h

diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
index 13d6b7b..7e313f1 100644
--- a/arch/powerpc/include/asm/Kbuild
+++ b/arch/powerpc/include/asm/Kbuild
@@ -34,6 +34,5 @@ header-y += termios.h
 header-y += types.h
 header-y += ucontext.h
 header-y += unistd.h
-header-y += epapr_hcalls.h
 
 generic-y += rwsem.h
diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
b/arch/powerpc/include/asm/epapr_hcalls.h
index b8d9445..22defe7 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -50,65 +50,11 @@
 #ifndef _EPAPR_HCALLS_H
 #define _EPAPR_HCALLS_H
 
-#define EV_BYTE_CHANNEL_SEND   1
-#define EV_BYTE_CHANNEL_RECEIVE2
-#define EV_BYTE_CHANNEL_POLL   3
-#define EV_INT_SET_CONFIG  4
-#define EV_INT_GET_CONFIG  5
-#define EV_INT_SET_MASK6
-#define EV_INT_GET_MASK7
-#define EV_INT_IACK9
-#define EV_INT_EOI 10
-#define EV_INT_SEND_IPI11
-#define EV_INT_SET_TASK_PRIORITY   12
-#define EV_INT_GET_TASK_PRIORITY   13
-#define EV_DOORBELL_SEND   14
-#define EV_MSGSND  15
-#define EV_IDLE16
-
-/* vendor ID: epapr */
-#define EV_LOCAL_VENDOR_ID 0   /* for private use */
-#define EV_EPAPR_VENDOR_ID 1
-#define EV_FSL_VENDOR_ID   2   /* Freescale Semiconductor */
-#define EV_IBM_VENDOR_ID   3   /* IBM */
-#define EV_GHS_VENDOR_ID   4   /* Green Hills Software */
-#define EV_ENEA_VENDOR_ID  5   /* Enea */
-#define EV_WR_VENDOR_ID6   /* Wind River Systems */
-#define EV_AMCC_VENDOR_ID  7   /* Applied Micro Circuits */
-#define EV_KVM_VENDOR_ID   42  /* KVM */
-
-/* The max number of bytes that a byte channel can send or receive per call */
-#define EV_BYTE_CHANNEL_MAX_BYTES  16
-
-
-#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
-#define EV_HCALL_TOKEN(hcall_num) _EV_HCALL_TOKEN(EV_EPAPR_VENDOR_ID, 
hcall_num)
-
-/* epapr return codes */
-#define EV_SUCCESS 0
-#define EV_EPERM   1   /* Operation not permitted */
-#define EV_ENOENT  2   /*  Entry Not Found */
-#define EV_EIO 3   /* I/O error occured */
-#define EV_EAGAIN  4   /* The operation had insufficient
-* resources to complete and should be
-* retried
-*/
-#define EV_ENOMEM  5   /* There was insufficient memory to
-* complete the operation */
-#define EV_EFAULT  6   /* Bad guest address */
-#define EV_ENODEV  7   /* No such device */
-#define EV_EINVAL  8   /* An argument supplied to the hcall
-  was out of range or invalid */
-#define EV_INTERNAL9   /* An internal error occured */
-#define EV_CONFIG  10  /* A configuration error was detected */
-#define EV_INVALID_STATE   11  /* The object is in an invalid state */
-#define EV_UNIMPLEMENTED   12  /* Unimplemented hypercall */
-#define EV_BUFFER_OVERFLOW 13  /* Caller-supplied buffer too small */
-
 #ifndef __ASSEMBLY__
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Hypercall register clobber list
diff --git a/arch/powerpc/include/uapi/asm/Kbuild 
b/arch/powerpc/include/uapi/asm/Kbuild
index baebb3d..e6b5be8 100644
--- a/arch/powerpc/include/uapi/asm/Kbuild
+++ b/arch/powerpc/include/uapi/asm/Kbuild
@@ -1,3 +1,4 @@
 # UAPI Header export list
 include include/uapi/asm-generic/Kbuild.asm
 
+header-y += epapr_hcalls.h
diff --git a/arch/powerpc/include/uapi/asm/epapr_hcalls.h 
b/arch/powerpc/include/uapi/asm/epapr_hcalls.h
new file mode 100644
index 000..046c793
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/epapr_hcalls.h
@@ -0,0 +1,98 @@
+/*
+ * ePAPR hcall interface
+ *
+ * Copyright 2008-2011 Freescale Semiconductor, Inc.
+ *
+ * Author: Timur Tabi 
+ *
+ * This file is provided under a dual BSD/GPL license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ 

Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)

[Theodore Ts'o]

On Sat, Oct 27, 2012 at 01:45:25PM +0100, Nix wrote:
> Ah! it's turned on by journal_async_commit. OK, that alone argues
> against use of journal_async_commit, tested or not, and I'd not have
> turned it on if I'd noticed that.
> 
> (So, the combinations I'll be trying for effect on this bug are:
> 
>  journal_async_commit (as now)
>  journal_checksum
>  none

Can you also check and see whether the presence or absence of
"nobarrier" makes a difference?

Thanks,

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

[PATCH] cpufreq: powernow-k8: Remove bogus smp_processor_id() usage

[Thomas Gleixner]

commit 6889125b (cpufreq/powernow-k8: workqueue user shouldn't migrate
the kworker to another CPU) has a broken optimization of calling
powernowk8_target_fn() directly from powernowk8_target() which
results in the following splat:

[   11.789468] BUG: using smp_processor_id() in preemptible [] code:
   modprobe/505
[   11.809594] caller is powernowk8_target+0x20/0x48 [powernow_k8]
[   12.001748] Pid: 505, comm: modprobe Not tainted 3.6.3 #3
[   12.016836] Call Trace:
[   12.025971]  [] debug_smp_processor_id+0xcc/0xe8
[   12.042518]  [] powernowk8_target+0x20/0x48 [powernow_k8]
[   12.060733]  [] __cpufreq_driver_target+0x82/0x8a
[   12.077550]  [] cpufreq_governor_userspace+0x265/0x2c0
[   12.120378]  [] ? __blocking_notifier_call_chain+0x56/0x60
[   12.138862]  [] __cpufreq_governor+0x8c/0xc9
[   12.155193]  [] __cpufreq_set_policy+0x212/0x21e
[   12.172148]  [] cpufreq_add_dev_interface+0x2a2/0x2bc
[   12.189855]  [] ? cpufreq_update_policy+0x124/0x124
[   12.207096]  [] cpufreq_add_dev+0x4a4/0x4b4
[   12.223161]  [] subsys_interface_register+0x95/0xc5
[   12.240386]  [] ? _raw_spin_lock_irqsave+0x24/0x46
[   12.257477]  [] cpufreq_register_driver+0xd2/0x1bf
[   12.274545]  [] powernowk8_init+0x193/0x1dc [powernow_k8]
[   12.292794]  [] ? powernowk8_cpu_init+0xc53/0xc53 
[powernow_k8]
[   12.312004]  [] do_one_initcall+0x7f/0x136
[   12.327594]  [] sys_init_module+0x17b0/0x197e
[   12.343718]  [] ? ddebug_proc_write+0xde/0xde
[   12.359767]  [] system_call_fastpath+0x16/0x1b

This is fully preemptible non cpu bound context though the comment in the
code says:

 * Must run on @pol->cpu.  cpufreq core is responsible for ensuring
 * that we're bound to the current CPU and pol->cpu stays online.

The core only guarantees that pol->cpu stays online, but it has no way
to bind the thread and this needs to be fully preemptible context as
powernowk8_target_fn() calls functions which might sleep.

So the correct solution is to always go through work_on_cpu().

Reported-and-tested-by: Carsten Emde 
Cc: Tejun Heo 
Cc: Rafael J. Wysocki 
Cc: Andreas Herrmann 
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner 
---
 drivers/cpufreq/powernow-k8.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: linux-2.6/drivers/cpufreq/powernow-k8.c
===
--- linux-2.6.orig/drivers/cpufreq/powernow-k8.c
+++ linux-2.6/drivers/cpufreq/powernow-k8.c
@@ -1053,13 +1053,12 @@ static int powernowk8_target(struct cpuf
 .relation = relation };
 
/*
-* Must run on @pol->cpu.  cpufreq core is responsible for ensuring
-* that we're bound to the current CPU and pol->cpu stays online.
+* Must run on @pol->cpu. We queue it on the target cpu even
+* if we are currently on the target cpu. This is preemptible
+* non cpu bound context, so we can't call the target function
+* directly.
 */
-   if (smp_processor_id() == pol->cpu)
-   return powernowk8_target_fn();
-   else
-   return work_on_cpu(pol->cpu, powernowk8_target_fn, );
+   return work_on_cpu(pol->cpu, powernowk8_target_fn, );
 }
 
 /* Driver entry point to verify the policy and range of frequencies */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 26/85] usb: host: xhci: New system added for Compliance Mode Patch on SN65LVPE502CP

[Ben Hutchings]

On Thu, 2012-10-25 at 17:05 -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: "Alexis R. Cortes" 
> 
> commit 470809741a28c3092279f4e1f3f432e534d46068 upstream.
> 
> This minor change adds a new system to which the "Fix Compliance Mode
> on SN65LVPE502CP Hardware" patch has to be applied also.
> 
> System added:
> Vendor: Hewlett-Packard. System Model: Z1
[...]
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -479,7 +479,8 @@ static bool compliance_mode_recovery_tim
>  
>   if (strstr(dmi_product_name, "Z420") ||
>   strstr(dmi_product_name, "Z620") ||
> - strstr(dmi_product_name, "Z820"))
> + strstr(dmi_product_name, "Z820") ||
> + strstr(dmi_product_name, "Z1"))

This will also match any future models with extra digits after the '1'.
It might be worth using a slightly stricter match.

Ben.

>   return true;
>  
>   return false;


-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

Re: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Thomas Petazzoni]

On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:
> This platform, available from Globalscale has an Armada 370. For now,
> only the serial port is supported. Support for network, USB and other
> peripherals will be added as drivers for them become available for
> Armada 370 in mainline.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/boot/dts/Makefile  |3 ++-
>  arch/arm/boot/dts/mbx001.dts|   37 
> +++
>  arch/arm/mach-mvebu/armada-370-xp.c |1 +
>  3 files changed, 40 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/mbx001.dts

With the rename mbx001.dts -> mbx0001.dts, this works fine for me on
the hardware platform, so:

Tested-by: Thomas Petazzoni 

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL 0/9] perf/core improvements and fixes

[stephane eranian]

On Fri, Oct 26, 2012 at 5:31 PM, Namhyung Kim  wrote:
> 2012-10-26 (금), 09:06 -0600, David Ahern:
>> On 10/26/12 8:54 AM, Ingo Molnar wrote:
>> >> perf/core improvements:
>> >>
>> >> . perf inject changes to allow showing where a task sleeps, from Andrew 
>> >> Vagin.
>> >>
>> >> . Makefile improvements from Namhyung Kim.
>> >
>> > These are really useful: there used to be a couple of seconds of
>> > wait time at the beginning of every perf build - these are now
>> > nicely explained with the various CHK entries.
>
> Kudos to Jiri who did the real work!
>
>>
>> PERF-VERSION-GEN and specifically the git commands are the cause of more
>> delay than the config checks, especially when doing the build in a VM
>> with the kernel source on an NFS mount.
>
> And I see a strange delay when compiling builtin-sched.o.  After
> building perf tools, I deleted builtin-{sched,test,script}.o to rebuild
> the only since they are largest ones.
>
Yes, I see that delay on copiling builtin-sched.c on my IVB system.
Don't know why it takes a significant number of seconds to compile
this file. It did not use to be like that a few revisions back. It takes
about 8 seconds on my OC'd IVB (> 4GHz).  I don't see much code
in that file.

>   namhyung@leonhard:perf$ ls -lS *.c | head -3
>   -rw-r--r-- 1 namhyung namhyung 45522 2012-10-27 00:20 builtin-sched.c
>   -rw-r--r-- 1 namhyung namhyung 36372 2012-10-27 00:20 builtin-test.c
>   -rw-r--r-- 1 namhyung namhyung 3 2012-10-27 00:20 builtin-script.c
>
>   namhyung@leonhard:perf$ rm builtin-{sched,test,script}.o
>
>
> And then building each file with time command shows this:
>
>   namhyung@leonhard:perf$ time make builtin-script.o &> /dev/null
>
>   real  0m4.577s
>   user  0m2.755s
>   sys   0m1.655s
>
>   namhyung@leonhard:perf$ time make builtin-test.o &> /dev/null
>
>   real  0m4.486s
>   user  0m2.707s
>   sys   0m1.658s
>
>   namhyung@leonhard:perf$ time make builtin-sched.o &> /dev/null
>
>   real  0m16.936s
>   user  0m15.157s
>   sys   0m1.635s
>
> You can see it easily when building perf without -j option. But I have
> no idea why it takes so long..
>
> 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: [PATCH] staging: csr: Fix typo in csr/netdev.c

[Mark Einon]

On 27 October 2012 15:53, Masanari Iida  wrote:
> Correct spelling typo in trace message.
>
> Signed-off-by: Masanari Iida 
> ---
>  drivers/staging/csr/netdev.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/csr/netdev.c b/drivers/staging/csr/netdev.c
> index 0e34020..878c3df 100644
> --- a/drivers/staging/csr/netdev.c
> +++ b/drivers/staging/csr/netdev.c
> @@ -100,7 +100,7 @@
>  #endif /* LINUX_VERSION_CODE */
>
>
> -/* Wext handler is suported only if CSR_SUPPORT_WEXT is defined */
> +/* Wext handler is supported only if CSR_SUPPORT_WEXT is defined */
>  #ifdef CSR_SUPPORT_WEXT
>  extern struct iw_handler_def unifi_iw_handler_def;
>  #endif /* CSR_SUPPORT_WEXT */
> @@ -146,7 +146,7 @@ typedef int (*tx_signal_handler)(unifi_priv_t *priv, 
> struct sk_buff *skb, const
>  /*
>   * The driver uses the qdisc interface to buffer and control all
>   * outgoing traffic. We create a root qdisc, register our qdisc operations
> - * and later we create two subsiduary pfifo queues for the uncontrolled
> + * and later we create two subsidiary pfifo queues for the uncontrolled
>   * and controlled ports.
>   *
>   * The network stack delivers all outgoing packets in our enqueue handler.
> @@ -1748,7 +1748,7 @@ send_ma_pkt_request(unifi_priv_t *priv, struct sk_buff 
> *skb, const struct ethhdr
>  return -1;
>  }
>
> -/* RA adrress must contain the immediate destination MAC address that is 
> similiar to
> +/* RA adrress must contain the immediate destination MAC address that is 
> similar to

Hi Masanari,

You've also missed the fact that 'address' is spelt incorrectly in
'RSA adrress' here.

Cheers,

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] exec: do not leave bprm->interp on stack

[Kees Cook]

On Sat, Oct 27, 2012 at 3:47 AM, P J P  wrote:
> +-- On Fri, 26 Oct 2012, Al Viro wrote --+
> | > not. Module alias could dodge this though, I guess.
> | "Could"?  Can you show a single module that would have name matching
> | binfmt-[0-9a-f]*?  In other words, are they ever loaded _not_ via an
> | alias?
>
>   I understand. I was wondering if alias information is accessible in the
> kernel via any routine, alike find_module().
>
> Just to get perspective about how many times request_module() would be called
> with the latest patch, in general installations(or distributions), how
> prevalent(in use) are binfmt- loadable modules?

Al showed a list of them earlier in the thread. I don't have any on
the various distros I checked.

The problem I see here is that we only want to do module loading in
the "no match" case. But that means that either we need to restart
with the original bprm, or we need to keep bprm changes off the stack.
Leading with a module load is going to wreck performance.

-Kees

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

Re: [ 16/85] use clamp_t in UNAME26 fix

[Fengguang Wu]

On Sat, Oct 27, 2012 at 05:11:58PM +0100, Ben Hutchings wrote:
> On Thu, 2012-10-25 at 17:05 -0700, Greg Kroah-Hartman wrote:
> > 3.6-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Kees Cook 
> > 
> > commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.
> > 
> > The min/max call needed to have explicit types on some architectures
> > (e.g. mn10300). Use clamp_t instead to avoid the warning:
> > 
> >   kernel/sys.c: In function 'override_release':
> >   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks 
> > a cast [enabled by default]
> 
> While this change makes the code more readable, I think the bug is
> really in the type definitions for those architectures:
> 
> [...]
> > -   copy = min(sizeof(buf), max_t(size_t, 1, len));
> > +   copy = clamp_t(size_t, len, 1, sizeof(buf));
> [...]
> 
> 1. sizeof(buf) yields a value of type size_t, by definition.
> 2. max_t(size_t, 1, len) yields a value of type size_t.
> 3. Therefore min(sizeof(buf), max_t(size_t, 1, len)) is valid.
> 
> The only way I see to get this warning is to define size_t wrongly, so
> that (1) is not true.

Agreed. mn10300 and cris seem to have problems with size_t.
Here is a related issue: 

Re: [next:akpm 155/157] drivers/char/random.c:827:3: warning: format '%zd' 
expects argument of type 'signed size_t', but argument 7 has type 'size_t'
https://lkml.org/lkml/2012/10/23/792

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: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Thomas Petazzoni]

On Sat, 27 Oct 2012 18:44:48 +0200, Andrew Lunn wrote:
> > diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
> > new file mode 100644
> > index 000..88a5a11
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mbx001.dts
> 
> Hi Gregory
> 
> Maybe it would be good to prefix this with armada-370. It then fits
> with armada-370-db.dts, and all the kirkwood files are kirkwood-*.dts.

So for OpenBlocks, I should rename armada-xp-openblocks-ax3-4.dts as
well, I guess. I agree with your comment: I think that a name such as
mbx001.dts is way too generic.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v4 5/5] zynq: move static peripheral mappings

[Michal Simek]

HI Josh and Nick,

look below.

> -Original Message-
> From: Josh Cartwright [mailto:josh.cartwri...@ni.com]
> Sent: Friday, October 26, 2012 3:03 AM
> To: Nick Bowler
> Cc: a...@kernel.org; Arnd Bergmann; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; John Linn; Michal Simek
> Subject: Re: [PATCH v4 5/5] zynq: move static peripheral mappings
> 
> On Thu, Oct 25, 2012 at 06:41:08PM -0400, Nick Bowler wrote:
> > On 2012-10-25 16:29 -0500, Josh Cartwright wrote:
> > > On Thu, Oct 25, 2012 at 04:17:01PM -0400, Nick Bowler wrote:
> > > > Did you test this on any real hardware?  I can't get the ZC702 to
> > > > work with the UART mapped at this address (this ends up being
> > > > mapped at 0xFEFFF000), although I can't for the life of me figure
> > > > out why the virtual address even matters.  Note that for the
> > > > ZC702, the physical address of the "main" UART is 0xE0001000.
> 
> Good news is you're not crazy; I was able to duplicate the problem here.
> 
> > If I were to guess, I would guess that, except for when it "Works",
> > the really really early printk stuff isn't actually hitting the uart
> > at all.  The "Fails" case would then be due to the stray writes
> > crashing the board, and the "Truncated" case due to the stray writes
> > being (ostensibly) benign.
> 
> If I'm not mistaken, this hypothesis is predicated on the early bootup code
> establishing a (linear?) mapping for addresses > VMALLOC_START; before the
> mdesc->map_io() is even handled.  That seems odd to me.
> 
> > But I really have no way right now to test this hypothesis, since I
> > can't print anything in the failing case.
> 
> Not sure if I'll be able to get anything meaningful out of it yet (I've not
> historically had good luck with Xilinx's debugging tools), but I did finally 
> get a
> JTAG debugger hooked up to the zc702.  I'll see if I can get any useful
> information tomorrow.

I have seen the same problem on zc702. I will debug it.
Josh: the best will be if you can send v5 for patches 1-3 (1 with small changes 
in dts - uart)  which I will apply
to arm-next. 

4/5 should go out of zynq subtree, it means directly to arm-soc or via Russel's 
tree. 

5/5 + Nick patch should be tested. 

Thanks,
Michal


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/5] zynq: remove use of CLKDEV_LOOKUP

[Michal Simek]

> -Original Message-
> From: Josh Cartwright [mailto:josh.cartwri...@ni.com]
> Sent: Wednesday, October 24, 2012 10:04 PM
> To: a...@kernel.org; Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; John
> Linn; Nick Bowler; Michal Simek
> Subject: [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP
>
> The Zynq support in mainline does not (yet) make use of any of the generic clk
> or clk lookup functionality.  Remove what is upstream for now, until the 
> out-of-
> tree implementation is in suitable form for merging.
>
> An important side effect of this patch is that it allows the building of a 
> Zynq
> kernel without running into unresolved symbol problems:
>
>drivers/built-in.o: In function `amba_get_enable_pclk':
>clkdev.c:(.text+0x444): undefined reference to `clk_enable'
>drivers/built-in.o: In function `amba_remove':
>clkdev.c:(.text+0x488): undefined reference to `clk_disable'
>drivers/built-in.o: In function `amba_probe':
>clkdev.c:(.text+0x540): undefined reference to `clk_disable'
>drivers/built-in.o: In function `amba_device_add':
>clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
>drivers/built-in.o: In function `enable_clock':
>clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
>drivers/built-in.o: In function `disable_clock':
>clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
>drivers/built-in.o: In function `__pm_clk_remove':
>clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
>drivers/built-in.o: In function `pm_clk_suspend':
>clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
>drivers/built-in.o: In function `pm_clk_resume':
>clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
>make[2]: *** [vmlinux] Error 1
>make[1]: *** [sub-make] Error 2
>make: *** [all] Error 2
>
> In addition, eliminate Zynq's "use" of the versatile platform, as it is no 
> longer
> needed.  As Nick Bowler points out:
>
>For the record, I think this was introduced by commit 56a34b03ff427
>("ARM: versatile: Make plat-versatile clock optional") which forgot to
>select PLAT_VERSATILE_CLOCK on Zynq.  This is not all that surprising,
>because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
>the Makefile.
>
>Nevertheless, the only feature from versatile that Zynq needed was the
>clock support, so this patch should *also* delete the secret use of
>plat-versatile by removing this line from arch/arm/Makefile:
>
>   plat-$(CONFIG_ARCH_ZYNQ)  += versatile
>
> Signed-off-by: Josh Cartwright 
> Cc: John Linn 
> Acked-by: Arnd Bergmann 
> ---
>  arch/arm/Kconfig |  1 -
>  arch/arm/Makefile|  1 -
>  arch/arm/mach-zynq/common.c  |  1 -
>  arch/arm/mach-zynq/include/mach/clkdev.h | 32 
> 
>  4 files changed, 35 deletions(-)
>  delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cce4f8d..de70d99 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -946,7 +946,6 @@ config ARCH_ZYNQ
>   bool "Xilinx Zynq ARM Cortex A9 Platform"
>   select ARM_AMBA
>   select ARM_GIC
> - select CLKDEV_LOOKUP
>   select CPU_V7
>   select GENERIC_CLOCKEVENTS
>   select ICST
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 451757d..8dbab2d
> 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -197,7 +197,6 @@ machine-$(CONFIG_ARCH_ZYNQ)   += zynq
>  # by CONFIG_* macro name.
>  plat-$(CONFIG_ARCH_OMAP) += omap
>  plat-$(CONFIG_ARCH_S3C64XX)  += samsung
> -plat-$(CONFIG_ARCH_ZYNQ) += versatile
>  plat-$(CONFIG_PLAT_IOP)  += iop
>  plat-$(CONFIG_PLAT_NOMADIK)  += nomadik
>  plat-$(CONFIG_PLAT_ORION)+= orion
> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
> index 056091a..ba48f06 100644
> --- a/arch/arm/mach-zynq/common.c
> +++ b/arch/arm/mach-zynq/common.c
> @@ -31,7 +31,6 @@
>  #include 
>
>  #include 
> -#include 
>  #include "common.h"
>
>  static struct of_device_id zynq_of_bus_ids[] __initdata = { diff --git
> a/arch/arm/mach-zynq/include/mach/clkdev.h b/arch/arm/mach-
> zynq/include/mach/clkdev.h
> deleted file mode 100644
> index c6e73d8..000
> --- a/arch/arm/mach-zynq/include/mach/clkdev.h
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -/*
> - * arch/arm/mach-zynq/include/mach/clkdev.h
> - *
> - *  Copyright (C) 2011 Xilinx, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * 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 

Re: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Andrew Lunn]

> diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
> new file mode 100644
> index 000..88a5a11
> --- /dev/null
> +++ b/arch/arm/boot/dts/mbx001.dts

Hi Gregory

Maybe it would be good to prefix this with armada-370. It then fits
with armada-370-db.dts, and all the kirkwood files are kirkwood-*.dts.

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

Re: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Sebastian Hesselbarth]

On 10/27/2012 06:33 PM, Thomas Petazzoni wrote:

On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:

This platform, available from Globalscale has an Armada 370. For now,
only the serial port is supported. Support for network, USB and other
peripherals will be added as drivers for them become available for
Armada 370 in mainline.


Great!


ACK!


+++ b/arch/arm/boot/dts/mbx001.dts


If you decided to name your platform with four zeros (1), then the
file should be mbx0001.dts here.


What is wrong with "globalscale,mirabox" ?

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

Re: [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Thomas Petazzoni]

Hello,

On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:
> This platform, available from Globalscale has an Armada 370. For now,
> only the serial port is supported. Support for network, USB and other
> peripherals will be added as drivers for them become available for
> Armada 370 in mainline.

Great!

> +++ b/arch/arm/boot/dts/mbx001.dts

If you decided to name your platform with four zeros (1), then the
file should be mbx0001.dts here.

> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
> b/arch/arm/mach-mvebu/armada-370-xp.c
> index 49d7915..e5269b4 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
>  static const char * const armada_370_xp_dt_board_dt_compat[] = {
>   "marvell,a370-db",
>   "marvell,axp-db",
> + "globalscale,mbx0001",
>   NULL,
>  };

As Andrew said, sorted entries would be nicer.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 18/85] x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.

[Ben Hutchings]

On Thu, 2012-10-25 at 17:05 -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Jacob Shin 
> 
> commit 1e779aabe1f0768c2bf8f8c0a5583679b54a upstream.
> 
> On systems with very large memory (1 TB in our case), BIOS may report a
> reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
> these from the direct mapping.
> 
> [ hpa: this should be done not just for > 4 GB but for everything above the 
> legacy
>   region (1 MB), at the very least.  That, however, turns out to require 
> significant
>   restructuring.  That work is well underway, but is not suitable for 
> rc/stable. ]
[...]
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -919,8 +919,21 @@ void __init setup_arch(char **cmdline_p)
>  
>  #ifdef CONFIG_X86_64
>   if (max_pfn > max_low_pfn) {
> - max_pfn_mapped = init_memory_mapping(1UL<<32,
> -  max_pfn< + int i;
> + for (i = 0; i < e820.nr_map; i++) {
> + struct e820entry *ei = [i];
> +
> + if (ei->addr + ei->size <= 1UL << 32)
> + continue;
> +
> + if (ei->type == E820_RESERVED)
> + continue;
> +
> + max_pfn_mapped = init_memory_mapping(
> + ei->addr < 1UL << 32 ? 1UL << 32 : ei->addr,
> + ei->addr + ei->size);

Is it safe to assume that the e820 entries are sorted?  If not, this
assignment needs to be conditional.

Ben.

> + }
> +
>   /* can we preseve max_low_pfn ?*/
>   max_low_pfn = max_pfn;
>   }

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

[PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

[Gregory CLEMENT]

This platform, available from Globalscale has an Armada 370. For now,
only the serial port is supported. Support for network, USB and other
peripherals will be added as drivers for them become available for
Armada 370 in mainline.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/Makefile  |3 ++-
 arch/arm/boot/dts/mbx001.dts|   37 +++
 arch/arm/mach-mvebu/armada-370-xp.c |1 +
 3 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mbx001.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..ee09963 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
-   armada-xp-db.dtb
+   armada-xp-db.dtb \
+   mbx0001.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
new file mode 100644
index 000..88a5a11
--- /dev/null
+++ b/arch/arm/boot/dts/mbx001.dts
@@ -0,0 +1,37 @@
+/*
+ * Device Tree file for Globalscale Mirabox MBX0001
+ *
+ * Gregory CLEMENT 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-370.dtsi"
+
+/ {
+   model = "Mirabox MBX0001";
+   compatible = "globalscale,mbx0001", "marvell,armada370", 
"marvell,armada-370-xp";
+
+   chosen {
+   bootargs = "console=ttyS0,115200 earlyprintk";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x2000>; /* 512 MB */
+   };
+
+   soc {
+   serial@d0012000 {
+   clock-frequency = <2>;
+   status = "okay";
+   };
+   timer@d0020300 {
+   clock-frequency = <6>;
+   status = "okay";
+   };
+   };
+};
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..e5269b4 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
 static const char * const armada_370_xp_dt_board_dt_compat[] = {
"marvell,a370-db",
"marvell,axp-db",
+   "globalscale,mbx0001",
NULL,
 };
 
-- 
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 5/5] debugfs: remove goto in debugfs_remount()

[Yan Hong]

2012/10/27 Greg KH :
> On Sat, Oct 27, 2012 at 04:05:29PM +0800, Yan Hong wrote:
>> Simple code clean to remove goto.
>
> There is nothing wrong with gotos on error paths, so this one should
> stay.
>
> greg k-h

I thought we use goto on error path because there is no other elegant
ways to do the things, but it sounds like goto is still welcome and preferable
when we are not in this case. Anyway, this is a simple clean, I do not insist
on it.

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

Re: [PATCH -next] GPIO: clps711x: use platform_device_unregister in gpio_clps711x_init()

[Linus Walleij]

On Fri, Oct 26, 2012 at 5:15 PM, Wei Yongjun  wrote:

> From: Wei Yongjun 
>
> platform_device_unregister() only calls platform_device_del() and
> platform_device_put(), thus use platform_device_unregister() to
> simplify the code.
>
> Also the documents in platform.c shows that platform_device_del
> and platform_device_put must _only_ be externally called in error
> cases.  All other usage is a bug.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun 

Thanks, patch applied.

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

Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

[Francesco Lavra]

On 10/27/2012 06:00 PM, Rajanikanth HV wrote:
> On 27 October 2012 20:37, Francesco Lavra  wrote:
>> On 10/25/2012 08:30 AM, Rajanikanth H.V wrote:
>>> From: "Rajanikanth H.V" 
>>> + bat_tech = of_get_property(np_bat_supply,
>>> + "stericsson,battery-type", NULL);
>>> + if (!bat_tech)
>>> + dev_warn(dev, "missing property battery-name/type\n");
>>> +
>>> + if (strncmp(bat_tech, "LION", 4) == 0) {
>>
>> What if bat_tech is NULL?
> It will be UNKNOWN

I wanted to draw your attention to the fact that if bat_tech is NULL you
are passing a NULL pointer to strncmp(), which is not good.
So you should assign a default value to bat_tech in case the battery
type property is not found in the DT, as below:

if (!bat_tech) {
dev_warn(dev, "missing property battery-name/type\n");
bat_tech = "UNKNOWN";
}

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

Re: [PATCH v2 2/4] gpio: add viperboard gpio driver

[Linus Walleij]

On Fri, Oct 26, 2012 at 11:16 AM, Lars Poeschel  wrote:

> I am a bit unsure what to do now. Since Linus said he would take my driver
> without regmap, this will be my way for the driver.

Please submit the code in the shape you want me to merge it.

I think you've done an honest effort (more than most would do for sure)
to explore the ways of the regmap. If it doesn't fit, it doesn't fit and
that's it.

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

Re: [ 16/85] use clamp_t in UNAME26 fix

[Ben Hutchings]

On Thu, 2012-10-25 at 17:05 -0700, Greg Kroah-Hartman wrote:
> 3.6-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Kees Cook 
> 
> commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.
> 
> The min/max call needed to have explicit types on some architectures
> (e.g. mn10300). Use clamp_t instead to avoid the warning:
> 
>   kernel/sys.c: In function 'override_release':
>   kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a 
> cast [enabled by default]

While this change makes the code more readable, I think the bug is
really in the type definitions for those architectures:

[...]
> - copy = min(sizeof(buf), max_t(size_t, 1, len));
> + copy = clamp_t(size_t, len, 1, sizeof(buf));
[...]

1. sizeof(buf) yields a value of type size_t, by definition.
2. max_t(size_t, 1, len) yields a value of type size_t.
3. Therefore min(sizeof(buf), max_t(size_t, 1, len)) is valid.

The only way I see to get this warning is to define size_t wrongly, so
that (1) is not true.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


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

[PATCH 2/2] zram: handle mem suffixes in disk size zram_sysfs parameter

[Sergey Senozhatsky]

  zram: handle mem suffixes in disk size zram_sysfs parameter

  Use memparse() to allow mem suffixes in disksize sysfs number.
  Examples:
   echo 256K > /sys/block/zram0/disksize
   echo 512M > /sys/block/zram0/disksize
   echo 1G > /sys/block/zram0/disksize

  Signed-off-by: Sergey Senozhatsky 

---

 drivers/staging/zram/zram_sysfs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/zram/zram_sysfs.c 
b/drivers/staging/zram/zram_sysfs.c
index edb0ed4..6be318e 100644
--- a/drivers/staging/zram/zram_sysfs.c
+++ b/drivers/staging/zram/zram_sysfs.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "zram_drv.h"
 
@@ -54,13 +55,12 @@ static ssize_t disksize_show(struct device *dev,
 static ssize_t disksize_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
 {
-   int ret;
u64 disksize;
struct zram *zram = dev_to_zram(dev);
 
-   ret = kstrtoull(buf, 10, );
-   if (ret)
-   return ret;
+   disksize = memparse(buf, NULL);
+   if (disksize < 1)
+   return -EINVAL;
 
down_write(>init_lock);
if (zram->init_done) {

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

[PATCH 1/2] zram: factor-out zram_decompress_page() function

[Sergey Senozhatsky]

  zram: factor-out zram_decompress_page() function

  zram_bvec_read() shared decompress functionality with 
zram_read_before_write() function.
  Factor-out and make commonly used zram_decompress_page() function, which also 
simplified
  error handling in zram_bvec_read().

  Signed-off-by: Sergey Senozhatsky 

---

 drivers/staging/zram/zram_drv.c | 115 +---
 1 file changed, 50 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 6edefde..7585467 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -183,62 +183,25 @@ static inline int is_partial_io(struct bio_vec *bvec)
return bvec->bv_len != PAGE_SIZE;
 }
 
-static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
- u32 index, int offset, struct bio *bio)
+static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
 {
-   int ret;
-   size_t clen;
-   struct page *page;
-   unsigned char *user_mem, *cmem, *uncmem = NULL;
-
-   page = bvec->bv_page;
-
-   if (zram_test_flag(zram, index, ZRAM_ZERO)) {
-   handle_zero_page(bvec);
-   return 0;
-   }
+   int ret = LZO_E_OK;
+   size_t clen = PAGE_SIZE;
+   unsigned char *cmem;
+   unsigned long handle = zram->table[index].handle;
 
-   /* Requested page is not present in compressed area */
-   if (unlikely(!zram->table[index].handle)) {
-   pr_debug("Read before write: sector=%lu, size=%u",
-(ulong)(bio->bi_sector), bio->bi_size);
-   handle_zero_page(bvec);
+   if (!handle || zram_test_flag(zram, index, ZRAM_ZERO)) {
+   memset(mem, 0, PAGE_SIZE);
return 0;
}
 
-   if (is_partial_io(bvec)) {
-   /* Use  a temporary buffer to decompress the page */
-   uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
-   if (!uncmem) {
-   pr_info("Error allocating temp memory!\n");
-   return -ENOMEM;
-   }
-   }
-
-   user_mem = kmap_atomic(page);
-   if (!is_partial_io(bvec))
-   uncmem = user_mem;
-   clen = PAGE_SIZE;
-
-   cmem = zs_map_object(zram->mem_pool, zram->table[index].handle,
-   ZS_MM_RO);
-
-   if (zram->table[index].size == PAGE_SIZE) {
-   memcpy(uncmem, cmem, PAGE_SIZE);
-   ret = LZO_E_OK;
-   } else {
+   cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
+   if (zram->table[index].size == PAGE_SIZE)
+   memcpy(mem, cmem, PAGE_SIZE);
+   else
ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
-   uncmem, );
-   }
-
-   if (is_partial_io(bvec)) {
-   memcpy(user_mem + bvec->bv_offset, uncmem + offset,
-  bvec->bv_len);
-   kfree(uncmem);
-   }
-
-   zs_unmap_object(zram->mem_pool, zram->table[index].handle);
-   kunmap_atomic(user_mem);
+   mem, );
+   zs_unmap_object(zram->mem_pool, handle);
 
/* Should NEVER happen. Return bio error if it does. */
if (unlikely(ret != LZO_E_OK)) {
@@ -247,36 +210,58 @@ static int zram_bvec_read(struct zram *zram, struct 
bio_vec *bvec,
return ret;
}
 
-   flush_dcache_page(page);
-
return 0;
 }
 
-static int zram_read_before_write(struct zram *zram, char *mem, u32 index)
+static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
+ u32 index, int offset, struct bio *bio)
 {
int ret;
-   size_t clen = PAGE_SIZE;
-   unsigned char *cmem;
-   unsigned long handle = zram->table[index].handle;
+   struct page *page;
+   unsigned char *user_mem, *uncmem = NULL;
 
-   if (zram_test_flag(zram, index, ZRAM_ZERO) || !handle) {
-   memset(mem, 0, PAGE_SIZE);
+   page = bvec->bv_page;
+
+   if (unlikely(!zram->table[index].handle) ||
+   zram_test_flag(zram, index, ZRAM_ZERO)) {
+   pr_debug("Read before write: sector=%lu, size=%u",
+(ulong)(bio->bi_sector), bio->bi_size);
+   handle_zero_page(bvec);
return 0;
}
 
-   cmem = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
-   ret = lzo1x_decompress_safe(cmem, zram->table[index].size,
-   mem, );
-   zs_unmap_object(zram->mem_pool, handle);
+   user_mem = kmap_atomic(page);
+   if (is_partial_io(bvec))
+   /* Use  a temporary buffer to decompress the page */
+   uncmem = kmalloc(PAGE_SIZE, GFP_KERNEL);
+   else
+   uncmem = user_mem;
 
+   if (!uncmem) {
+   pr_info("Unable to allocate