RE: [PATCH v2]Btrfs: pwrite blocked when writing from the mmaped buffer of the same page

2011-02-10 Thread Zhong, Xin
Hi, Could you paste the output of sysrq+t here? Thanks! -Original Message- From: Johannes Hirte [mailto:johannes.hi...@fem.tu-ilmenau.de] Sent: Wednesday, February 02, 2011 7:35 AM To: Zhong, Xin Cc: Maria Wikström; linux-btrfs@vger.kernel.org Subject: Re: [PATCH v2]Btrfs: pwrite blocked

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Goffredo Baroncelli
On 02/10/2011 02:29 PM, Eduardo Silva wrote: > On Thu, 2011-02-10 at 12:39 +0100, Olaf van der Spek wrote: >> On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders >> wrote: >>> Olaf van der Spek wrote: >>> On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman wrote: > strncpy(args.name, sour

Re: mkfs.btrfs - error checking /dev/sda5 mount status

2011-02-10 Thread Lubos Kolouch
Goffredo Baroncelli, Thu, 10 Feb 2011 19:24:57 +0100: > On 02/09/2011 09:12 PM, Lubos Kolouch wrote: >> Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100: >> >>> On 02/08/2011 10:26 PM, Lubos Kolouch wrote: Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100: > On 02/08/2011 07:

Re: mkfs.btrfs - error checking /dev/sda5 mount status

2011-02-10 Thread Goffredo Baroncelli
On 02/09/2011 09:12 PM, Lubos Kolouch wrote: > Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100: > >> On 02/08/2011 10:26 PM, Lubos Kolouch wrote: >>> Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100: >>> On 02/08/2011 07:57 AM, Lubos Kolouch wrote: > Hi, > > I'm hitting t

Re: [PATCH] Btrfs-progs new btrfs_error() macro to deprecate fprintf(stderr, ...)

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 16:07 +0100, Hubert Kario wrote: > On Thursday, February 10, 2011 15:54:55 Eduardo Silva wrote: > > Hi, > > > > This patch add a new macro called btrfs_error(...) which deprecate the > > use of fprintf(stderr, ...) > > > > regards, > > > > Eduardo > > Sorry, but I don't se

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders wrote: > Of course C++ strings would be much better... :-) Yeah, why isn't C++ being used? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] Btrfs-progs new btrfs_error() macro to deprecate fprintf(stderr, ...)

2011-02-10 Thread Hubert Kario
On Thursday, February 10, 2011 15:54:55 Eduardo Silva wrote: > Hi, > > This patch add a new macro called btrfs_error(...) which deprecate the > use of fprintf(stderr, ...) > > regards, > > Eduardo Sorry, but I don't see a reason for such change. IMHO it only makes the code _less_ readable. Re

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 3:00 PM, Eduardo Silva wrote: > On Thu, 2011-02-10 at 14:52 +0100, Olaf van der Spek wrote: >> On Thu, Feb 10, 2011 at 2:37 PM, Eduardo Silva >> wrote: >> > string_copy seems pointless, it's kinda equivalent to strcpy. >> > >> > Yeah, but if we are thinking into write som

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 14:52 +0100, Olaf van der Spek wrote: > On Thu, Feb 10, 2011 at 2:37 PM, Eduardo Silva > wrote: > > string_copy seems pointless, it's kinda equivalent to strcpy. > > > > Yeah, but if we are thinking into write some wrappers let's create a couple > > for the major string mani

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 2:37 PM, Eduardo Silva wrote: > string_copy seems pointless, it's kinda equivalent to strcpy. > > Yeah, but if we are thinking into write some wrappers let's create a couple > for the major string manipulation used... A wrapper should have a benefit, your string_copy doesn

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 14:34 +0100, Olaf van der Spek wrote: > On Thu, Feb 10, 2011 at 2:29 PM, Eduardo Silva > wrote: > >> > There's strlcpy, but it's not in glibc because of possible truncation > >> > errors! > >> > >> Then use a private wrapper. > >> > > > > Here's the new patch: > > > > >

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 2:29 PM, Eduardo Silva wrote: >> > There's strlcpy, but it's not in glibc because of possible truncation >> > errors! >> >> Then use a private wrapper. >> > > Here's the new patch: > > > [PATCH] Add safe string manipulation functions > > Deprecate direct use of strcpy(

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 12:39 +0100, Olaf van der Spek wrote: > On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders > wrote: > > Olaf van der Spek wrote: > > > >> On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman > >> wrote: > >>> strncpy(args.name, source, BTRFS_PATH_NAME_MAX); > >>> args.name[BTRFS_P

Re: Corrupt filesystem after power failure

2011-02-10 Thread Hugo Mills
On Thu, Feb 10, 2011 at 10:29:41PM +1100, Anil Kumar wrote: > Full backtrace is at http://pastebin.com/4Re7tVFP Pastebins aren't archived. For posterity, here it is: Feb 10 21:57:36 linux-wuce kernel: [ 337.522818] Btrfs loaded Feb 10 21:57:36 linux-wuce kernel: [ 337.538044] device fsid d0

Re: Corrupt filesystem after power failure

2011-02-10 Thread A. James Lewis
I'm far from an expert here, but perhaps you would be worth trying a newer version of the BTRFS drivers, either via a newer kernel or re-compiling a kernel with updated BTRFS patches. I would think that the simplest "quick test" to see if this would help you would be to get a snapshot from Ubuntu

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Thomas Bellman
On 2011-02-10 13:27, Olaf van der Spek wrote: > On Thu, Feb 10, 2011 at 12:54 PM, Lars Wirzenius wrote: >> snprintf is standard, and should be about as safe as it gets with the >> glibc functions. > > But snprintf is not like strlcpy. It is indeed uglier to write 'snprintf(dst, size, "%s", src

Re: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

2011-02-10 Thread Petr Uzel
On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote: > /* > * CC'd to linux-kernel in case they have any feedback on this. > * > * Long thread, trying to work out why mkfs.btrfs failed to > * make a filesystem on an encrypted loopback mount called > * /dev/loop2. Cause turned out to b

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:54 PM, Lars Wirzenius wrote: > On to, 2011-02-10 at 11:37 +, Jeremy Sanders wrote: >> There's strlcpy, but it's not in glibc because of possible truncation >> errors! > > snprintf is standard, and should be about as safe as it gets with the > glibc functions. But sn

Re: New btrfsck status

2011-02-10 Thread Ben Gamari
On Thu, 10 Feb 2011 07:17:10 -0500, Chris Mason wrote: > Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500: > > Is there a timeline for getting btrfsck into some sort of usable form? > > Yes, but its still real soon now. I've been at about 90% done since > Christmas. It would have

Re: New btrfsck status

2011-02-10 Thread Chris Mason
Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500: > Hey all, > > Over the last several months there have been many claims regarding the > release of the rewritten btrfsck. Unfortunately, despite numerous > claims that it will be released Real Soon Now(c), I have yet to see > even a

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Lars Wirzenius
On to, 2011-02-10 at 11:37 +, Jeremy Sanders wrote: > There's strlcpy, but it's not in glibc because of possible truncation > errors! snprintf is standard, and should be about as safe as it gets with the glibc functions. -- To unsubscribe from this list: send the line "unsubscribe linux-btrf

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 12:08 +0100, Thomas Bellman wrote: > On 2011-02-07 13:22, Eduardo Silva wrote: > > > Please find the attached patch which replace unsafe strcpy(3) by > > strncpy(3) functions. > > strncpy() doesn't NUL-terminate the destination buffer if the > maximum length is reached. And

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders wrote: > Olaf van der Spek wrote: > >> On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman >> wrote: >>> strncpy(args.name, source, BTRFS_PATH_NAME_MAX); >>> args.name[BTRFS_PATH_NAME_MAX] = '\0'; >> >> That's silly. Isn't there a sane safe variant of

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Jeremy Sanders
Olaf van der Spek wrote: > On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman > wrote: >> strncpy(args.name, source, BTRFS_PATH_NAME_MAX); >> args.name[BTRFS_PATH_NAME_MAX] = '\0'; > > That's silly. Isn't there a sane safe variant of strcpy? There's strlcpy, but it's not in glibc because of possi

Corrupt filesystem after power failure

2011-02-10 Thread Anil Kumar
Hi, I am using btrfs on my /home successfully for a while now. After a power failure I am no longer able to mount it. I tried to use btrfsck without any success. The backup I have is about a month old, is there a way I can salvage my files?. Full backtrace is at http://pastebin.com/4Re7tVFP  I am a

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman wrote: >    strncpy(args.name, source, BTRFS_PATH_NAME_MAX); >    args.name[BTRFS_PATH_NAME_MAX] = '\0'; That's silly. Isn't there a sane safe variant of strcpy? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Thomas Bellman
On 2011-02-07 13:22, Eduardo Silva wrote: > Please find the attached patch which replace unsafe strcpy(3) by > strncpy(3) functions. strncpy() doesn't NUL-terminate the destination buffer if the maximum length is reached. And as far as I can see, there is no other initialization of those buffers