vprintk_emit prefix parsing should only be done for internal
kernel messages. This allows existing behavior to be kept
in all cases.
Signed-off-by: Joe Perches
---
kernel/printk.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/kernel/pr
Hello, Jeff
On 05/28/2012 09:41 PM, David Sterba wrote:
On Fri, May 25, 2012 at 11:10:21AM +0800, Asias He wrote:
1) This function is not used anywhere.
This was added in 49b25e0540904be0bf558b84475c69d72e4de66e adding a
transaction abort infrastructure. I'm not sure if Jeff had some
intenti
On Wed, 2012-06-06 at 03:10 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton
> wrote:
> > On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches wrote:
> >
> >> On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
> >> > On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton wrote:
> On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches wrote:
>
>> On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
>> > On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
>> >
>> > > On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches wrote:
> On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
> > On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
> >
> > > On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> > > > echo "\0014Hello Joe" > /dev/kmsg
> > >
> > > # e
On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
>
> > On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> > > echo "\0014Hello Joe" > /dev/kmsg
> >
> > # echo -e "\x014Hello Me" > /dev/kmsg
> > gives:
> > 12,778,4057982669;He
On Wed, 2012-06-06 at 02:28 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches wrote:
> > On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote:
> >> The question is what happens if you inject your new binary two-byte
> >> prefix, like:
> >> echo -e "\x01\x02Hello" > /dev/kms
On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches wrote:
> On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> > echo "\0014Hello Joe" > /dev/kmsg
>
> # echo -e "\x014Hello Me" > /dev/kmsg
> gives:
> 12,778,4057982669;Hello Me
That's changed behavior.
On Wed, 6 Jun 2012 02:28:39 +0200 Kay
On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches wrote:
> On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote:
>> The question is what happens if you inject your new binary two-byte
>> prefix, like:
>> echo -e "\x01\x02Hello" > /dev/kmsg
>
> It's not a 2 byte binary.
> It's a leading ascii SOH and a
On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote:
> The question is what happens if you inject your new binary two-byte
> prefix, like:
> echo -e "\x01\x02Hello" > /dev/kmsg
It's not a 2 byte binary.
It's a leading ascii SOH and a standard ascii char
'0' ... '7' or 'd'.
#define KERN_EMERG
On Wed, Jun 6, 2012 at 2:07 AM, Joe Perches wrote:
> On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
>> echo "\0014Hello Joe" > /dev/kmsg
>
> # echo -e "\x014Hello Me" > /dev/kmsg
> gives:
> 12,778,4057982669;Hello Me
>
> #echo -e "\x011Hello Me_2" > /dev/kmsg
> gives:
> 12,779,4140452093
On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:
> echo "\0014Hello Joe" > /dev/kmsg
# echo -e "\x014Hello Me" > /dev/kmsg
gives:
12,778,4057982669;Hello Me
#echo -e "\x011Hello Me_2" > /dev/kmsg
gives:
12,779,4140452093;Hello Me_2
I didn't change devkmsg_writev so the
original parsing s
On Tue, 05 Jun 2012 16:52:25 -0700
Joe Perches wrote:
> On Wed, 2012-06-06 at 01:48 +0200, Kay Sievers wrote:
> > On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches wrote:
> > > On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
> >
> > >> > # echo "\001Hello Andrew" > /dev/kmsg
> > >> > /dev/kmsg
On Wed, 2012-06-06 at 01:48 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches wrote:
> > On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
>
> >> > # echo "\001Hello Andrew" > /dev/kmsg
> >> > /dev/kmsg has
> >> > 12,774,2462339252;\001Hello Andrew
> >>
> >> Try "echo -e
On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches wrote:
> On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
>> > # echo "\001Hello Andrew" > /dev/kmsg
>> > /dev/kmsg has
>> > 12,774,2462339252;\001Hello Andrew
>>
>> Try "echo -e"? The stuff is copied verbatim otherwise.
>
> # echo -e "\001Hello Ka
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
> Try "echo -e"? The stuff is copied verbatim otherwise.
btw: I didn't change the devkmsg_writev function
which does the decoding of any "" prefix for
printk_emit.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote:
> On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches wrote:
> > On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
> >> What about writes starting with \001n? AFACIT, that will be stripped
> >> away and the printk level will be altered. This is
On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches wrote:
> On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
>> What about writes starting with \001n? AFACIT, that will be stripped
>> away and the printk level will be altered. This is new behavior.
>
> Nope.
>
> # echo "\001Hello Andrew" > /dev/
On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote:
> What about writes starting with \001n? AFACIT, that will be stripped
> away and the printk level will be altered. This is new behavior.
Nope.
# echo "\001Hello Andrew" > /dev/kmsg
/dev/kmsg has
12,774,2462339252;\001Hello Andrew
12 is 8
On Tue, 05 Jun 2012 15:49:32 -0700
Joe Perches wrote:
> On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote:
> > On Tue, 05 Jun 2012 15:11:43 -0700
> > Joe Perches wrote:
> >
> > > On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> > > > Unfortunately the thing is part of the kernel
On Wed, 06 Jun 2012 00:55:00 +0200
Kay Sievers wrote:
> On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
>
> > devkmsg_writev() does weird and wonderful things with
> > facilities/levels. That function incorrectly returns "success" when
> > copy_from_user() faults, btw.
>
> Oh. Better?
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> devkmsg_writev() does weird and wonderful things with
> facilities/levels. That function incorrectly returns "success" when
> copy_from_user() faults, btw.
Oh. Better?
Thanks,
Kay
From: Kay Sievers
Subject: kmsg: /dev/kmsg - properly
On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2012 15:11:43 -0700
> Joe Perches wrote:
>
> > On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> > > Unfortunately the thing is part of the kernel ABI:
> > >
> > > echo "<4>foo" > /dev/kmsg
> >
> > Which works t
On Tue, 05 Jun 2012 15:11:43 -0700
Joe Perches wrote:
> On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> > Unfortunately the thing is part of the kernel ABI:
> >
> > echo "<4>foo" > /dev/kmsg
>
> Which works the same way it did before.
I didn't say it didn't.
What I did say is t
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote:
> Unfortunately the thing is part of the kernel ABI:
>
> echo "<4>foo" > /dev/kmsg
Which works the same way it did before.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord.
On Tue, Jun 5, 2012 at 11:28 PM, Andrew Morton
wrote:
> On Tue, 5 Jun 2012 02:46:29 -0700
> Joe Perches wrote:
>
>> KERN_ currently takes up 3 bytes.
>> Shrink the kernel size by using an ASCII SOH and then the level byte.
>> Remove the need for KERN_CONT.
>> Convert directly embedded uses of <.
On Tue, 5 Jun 2012 02:46:29 -0700
Joe Perches wrote:
> KERN_ currently takes up 3 bytes.
> Shrink the kernel size by using an ASCII SOH and then the level byte.
> Remove the need for KERN_CONT.
> Convert directly embedded uses of <.> to KERN_
What an epic patchset. I guess that saving a byte p
On Tue, Jun 5, 2012 at 12:16 PM, Alexander Block
wrote:
> On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas
> wrote:
>>
>> Yes, I also noticed that sometimes transid gets bumped up, but there
>> is no actual change.
>>
>> So let's say you identify that a particular part of the tree is not
>> shared any
Hi Hugo,
On 06/05/2012 08:19 PM, Hugo Mills wrote:
> On Tue, Jun 05, 2012 at 07:26:34PM +0200, Goffredo Baroncelli
> wrote:
>> Hi Hugo,
>>
>> I was not able to reproduce your error with my repository: I
>> pulled it without problem.
>
> Well, I'd have normally written it off as a corrupt local r
rrow. As always, there's minimal testing involved here, but it
does at least compile on my system(*).
The branch is fetchable with git from:
http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
And viewable in human-readable form at:
http://git.darksatanic.
On Tue, Jun 05, 2012 at 07:26:34PM +0200, Goffredo Baroncelli wrote:
> Hi Hugo,
>
> I was not able to reproduce your error with my repository: I pulled it
> without problem.
Well, I'd have normally written it off as a corrupt local repo at
this end -- except that David Sterba said he'd also se
Because btrfs can remove the device that was mounted we need to have a
->show_devname so that in this case we can print out some other device in
the file system to /proc/mount. We keep track of what device we called
mount() with so that we can print out the correct one if it is still
available, bu
Al pointed out that we can just toss out the old name on a device and add a
new one arbitrarily, so anybody who uses device->name in printk could
possibly use free'd memory. Instead of adding locking around all of this he
suggested doing it with RCU, so I've introduced a struct rcu_string that
doe
Hallo, Hugo,
Du meintest am 05.06.12:
[...]
>> And you can't use the console from where you have started the
>> "balance" command. Therefore I wrap this command:
>>
>> echo 'btrfs filesystem balance /btrfs' | at now
>... or just put it into the background with "btrfs bal start
> /moun
Hi Hugo,
I was not able to reproduce your error with my repository: I pulled it
without problem.
However, enclosed you can find the patch (as attachment) with the Jan
suggestions about the spaces. You can pull the patch also from my repo (
same branch: fd-leaking). Moreover I inserted the patch a
On Mon, Jun 4, 2012 at 8:50 PM, Alexander E. Patrakov
wrote:
> 2012/6/5 Kok, Auke-jan H wrote on systemd-devel
> list:
>> It seems your system is taking well into 15+ seconds before btrfs is
>> actually *ready* on your system, which seems to be the main hiccup
>> (note, speculation here). I've p
On Tue, Jun 05, 2012 at 01:12:17PM -0400, Jim wrote:
> [sorry for the resend, signature again]
> I am waiting for a window (later tonight) when I can try mounting
> the btrfs export. Am I reading you guys correctly, that you think I
> should be deleting drives from the array? Or is this a just in
[sorry for the resend, signature again]
I am waiting for a window (later tonight) when I can try mounting the
btrfs export. Am I reading you guys correctly, that you think I should
be deleting drives from the array? Or is this a just in case? Thanks.
Jim Maloney
On 06/05/2012 01:04 PM, Hugo
On Tue, Jun 05, 2012 at 06:19:00PM +0200, Helmut Hullen wrote:
> Hallo, Jim,
>
> Du meintest am 05.06.12:
>
> > /dev/sda 11T 4.9T 6.0T 46% /btrfs
> > [root@advanced ~]# btrfs fi show
> > failed to read /dev/sr0
> > Label: none uuid: c21f1221-a224-4ba4-92e5-cdea0fa6d0f9
> >
Hallo, Jim,
Du meintest am 05.06.12:
> /dev/sda 11T 4.9T 6.0T 46% /btrfs
> [root@advanced ~]# btrfs fi show
> failed to read /dev/sr0
> Label: none uuid: c21f1221-a224-4ba4-92e5-cdea0fa6d0f9
> Total devices 12 FS bytes used 4.76TB
> devid6 size 930.99GB use
I noticed a few days ago that btrfs fi defrag -cXXX can not be used to
compress files unless they are fragmented. The attached patch passes
the compression flag to should_defrag_range, where it disables the
adjacent-extent and extent size checks if set. The inline/sparse
extent check is not modifie
[resent after getting rid of the damn signature]
Sorry I missed the list last time, I hit reply too fast. Yes, this
sounds like a good idea. I will try it and let you know.
Jim Maloney
On 06/05/2012 12:00 PM, Hugo Mills wrote:
[Please keep replies on the list]
On Tue, Jun 05, 2012 at 11:53:
[Please keep replies on the list]
On Tue, Jun 05, 2012 at 11:53:20AM -0400, Jim wrote:
> Thanks for the response. When I say mounts don't work I mean that
> when I try to mount an exported directory on an older os (most of my
> machines are centos 5.7) with a non btrfs kernel I get an "unknown
>
On Tue, Jun 05, 2012 at 10:38:11AM -0400, Jim wrote:
> Good morning btrfs list,
> I had written about 2 weeks ago about using extra btrfs space in an
> nfs file system setup. Nfs seems to export the files but the mounts
> don't work on older machines without btrfs kernels.
"The mounts don't wo
2012/6/5 Diego Calleja :
> [resend, for some reason kmail formatted the previous message with html]
>
> On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió:
>> Result: boot from ext4 takes less than 15 seconds, while boot from
>> btrfs takes 9 minutes (or 5 minutes if I disable re
Good morning btrfs list,
I had written about 2 weeks ago about using extra btrfs space in an nfs
file system setup. Nfs seems to export the files but the mounts don't
work on older machines without btrfs kernels. So I am down to deleting
several drives from btrfs to setup a standard raid 1 ar
[resend, for some reason kmail formatted the previous message with html]
On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió:
> Result: boot from ext4 takes less than 15 seconds, while boot from
> btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data
> file is not
On Tue, Jun 05, 2012 at 01:42:50PM +1000, Chris Samuel wrote:
> On 05/06/12 13:01, Marc MERLIN wrote:
>
> > First I though, I sure would be nice if I could take btrfs to reference
> > the same blocks from the snapshot to my current image.
> > But, --reflink failed across devices nodes, so I was fo
Hallo, Martin,
Du meintest am 05.06.12:
>> --super works but my root tree 2 has many errors too.
>>
>> What can I do next?
> Have a data recovery company try to physically recover the bad
> harddisk to a good one
About 1 year ago I asked Kroll-Ontrack. They told me they couldn't (yet)
recover
Hi, Goffredo,
I'm trying to do a new integration branch, and the patch inline in
the text is corrupt (plus it has a massively verbose commit message):
Applying: Leaking file handle in scrub_fs_info()
fatal: corrupt patch at line 74
Patch failed at 0001 Leaking file handle in scrub_fs_info()
Am Dienstag, 5. Juni 2012 schrieb Martin Steigerwald:
> Am Montag, 4. Juni 2012 schrieb Maxim Mikheev:
> > --super works but my root tree 2 has many errors too.
> >
> > What can I do next?
>
> Have a data recovery company try to physically recover the bad harddisk
> to a good one and then try to
Am Montag, 4. Juni 2012 schrieb Maxim Mikheev:
> --super works but my root tree 2 has many errors too.
>
> What can I do next?
Have a data recovery company try to physically recover the bad harddisk to
a good one and then try to mount BTRFS again and hope that your previous
attempts to repair t
Am Dienstag, 5. Juni 2012 schrieb Martin Steigerwald:
> Am Montag, 4. Juni 2012 schrieb Hugo Mills:
> > On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote:
> > > I run through all potential tree roots. It gave me everytime
> > > messages like these:
> > >
> > > parent transid verify fai
Am Montag, 4. Juni 2012 schrieb Hugo Mills:
> On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote:
> > I run through all potential tree roots. It gave me everytime
> > messages like these:
> >
> > parent transid verify failed on 3405159735296 wanted 9096 found 5263
> > parent transid ver
Use the generic printk_get_level function to search a message
for a kern_level. Add __printf to verify format and arguments.
Fix a few messages that had mismatches in format and arguments.
Add #ifdef CONFIG_PRINTK blocks to shrink the object size a bit
when not using printk.
Signed-off-by: Joe Pe
KERN_ currently takes up 3 bytes.
Shrink the kernel size by using an ASCII SOH and then the level byte.
Remove the need for KERN_CONT.
Convert directly embedded uses of <.> to KERN_
Joe Perches (8):
printk: Add generic functions to find KERN_ headers
printk: Add kern_levels.h to make KERN_ ava
On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas
wrote:
>
> Yes, I also noticed that sometimes transid gets bumped up, but there
> is no actual change.
>
> So let's say you identify that a particular part of the tree is not
> shared anymore, and, say, eventually you get to a particular leaf
> within th
57 matches
Mail list logo
