Jan Kara | 22 Jul 14:19 2016
Picon

[PATCH 0/15 v2] dax: Clear dirty bits after flushing caches

Hello,

this is a second revision of my patches to clear dirty bits from radix tree of
DAX inodes when caches for corresponding pfns have been flushed. This patch set
is significantly larger than the previous version because I'm changing how
->fault, ->page_mkwrite, and ->pfn_mkwrite handlers may choose to handle the
fault so that we don't have to leak details about DAX locking into the generic
code. In principle, these patches enable handlers to easily update PTEs and do
other work necessary to finish the fault without duplicating the functionality
present in the generic code.  I'd be really interested in feedback from mm
folks whether such changes to fault handling code are fine or what they'd do
differently...

Changes since v1:
* make sure all PTE updates happen under radix tree entry lock to protect
  against races between faults & write-protecting code
* remove information about DAX locking from mm/memory.c
* smaller updates based on Ross' feedback

----
Background information regarding the motivation:

Currently we never clear dirty bits in the radix tree of a DAX inode. Thus
fsync(2) flushes all the dirty pfns again and again. This patches implement
clearing of the dirty tag in the radix tree so that we issue flush only when
needed.

The difficulty with clearing the dirty tag is that we have to protect against
a concurrent page fault setting the dirty tag and writing new data into the
page. So we need a lock serializing page fault and clearing of the dirty tag
(Continue reading)

Chris Clayton | 22 Jul 07:41 2016

4.7.0-rc7+: Oops during boot with USB pen drive inserted

Hi,

With Linus' latest and greatest, I get an opps when I boot my laptop with a pen drive inserted in any USB port.
The oops
message is:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2)

The oops seems to be 100% repeatable. If a USB pen drive is not inserted, the laptop boots successfully.

I've taken a photograph of the oops and you can view it at
http://s714.photobucket.com/user/chris2553/media/IMG_20160722_053841.jpg.html.

At the top of the picture, I notice that the partitions on my actual boot disk are being reported as being on /dev/sdb,
so it seems likely that, at this point, the pen drive is being seen as /dev/sda, although that has scrolled
off the
screen. I don't boot via a ramdisk - my kernel has ext4 built in.  The grub2 entry is:

menuentry "Krisux, Linux 4.7.0-rc7+" {
    insmod ext2
    set root=(hd0,2)

    linux   /boot/vmlinuz-4.7.0-rc7+ ro root=/dev/sda2 resume=/dev/sda6 rootfstype=ext4 net.ifnames=0

}

(BTW, Krisux is not a real distro - it's just the name I have given Linux from Scratch system.)

The stack that is dumped is:

(Continue reading)

Charles Gong | 21 Jul 01:11 2016

[PATCH] Fix sysrq emergency thaw

"SYSRQ + J" triggers a call to emergency_thaw_all(). Currently, this
is an infinite loop. Once we trigger it, we'll need to do a hard
power-cycle. There are users reporting this bug from 2012 to 2016, for
example, at https://bugzilla.kernel.org/show_bug.cgi?id=47741.

This happens because thaw_bdev() fails to return -EINVAL in the
non-frozen case, so fix it so that do_one_thaw() can recognize this case
and quit from looping. I checked that none of the other thaw_bdev()
callers check the return value.

The regression was introduced in commit 4504230a7156 ("freeze_bdev: grab
active reference to frozen superblocks").

Reviewed-by: Chris Mason <clm <at> fb.com>
Signed-off-by: Charles Gong <cggong <at> fb.com>
---
 fs/block_dev.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 71ccab1..14f015e 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
 <at>  <at>  -301,14 +301,12  <at>  <at>  int thaw_bdev(struct block_device *bdev, struct super_block *sb)
 		error = sb->s_op->thaw_super(sb);
 	else
 		error = thaw_super(sb);
-	if (error) {
+	if (error)
 		bdev->bd_fsfreeze_count++;
(Continue reading)

Nicolas Pitre | 20 Jul 21:22 2016

[PATCH v4 00/12] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable
binaries meant for no-MMU systems to actually run on systems with a MMU.
Also thrown in are various cleanups to binfmt_flat.c.

This can also be found in the following git repo:

	git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu

*Why?*

Because developing and testing natively on a large system with lots of
RAM makes it so much more convenient to use all the existing profiling
tools and debugging facilities that a kernel with lots of RAM can give.
And incidentally, those systems with lots of RAM all have a MMU.

*Why not use elf_fdpic?*

The flat executable format is simple with very small footprint
overhead, either in the executables themselves or kernel support.
This makes the flat format more suitable than elf_fdpic for very small
single-user-app embedded systems.

And while elf_fdpic binaries can run on MMU systems, flat binaries still
couldn't, which just felt wrong.

So here it is. The no-MMU support should remain unaffected, confirmed by
Greg Ungerer. Tested on ARM with MMU only with a busybox build.

Please consider for merging.

(Continue reading)

Nicolas Pitre | 20 Jul 06:20 2016

[PATCH v3 00/12] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable
binaries meant for no-MMU systems to actually run on systems with a MMU.

This can also be found in the following git repo:

	git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu

*Why?*

Because developing and testing natively on a large system with lots of
RAM makes it so much more convenient to use all the existing profiling
tools and debugging facilities that a kernel with lots of RAM can give.
And incidentally, those systems with lots of RAM all have a MMU.

*Why not use elf_fdpic?*

The flat executable format is simple with very small footprint
overhead, either in the executables themselves or kernel support.
This makes the flat format more suitable than elf_fdpic for very small
single-user-app embedded systems.

And while elf_fdpic binaries can run on MMU systems, flat binaries still
couldn't, which just felt wrong.

So here it is. The no-MMU support should remain unaffected, confirmed by
Greg Ungerer. Tested on ARM with MMU only with a busybox build.

Please consider for merging.

Changes since  v2:
(Continue reading)

Wei Yongjun | 19 Jul 14:54 2016

[PATCH -next] dax: Fix non static symbol warning

From: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>

Fixes the following sparse warnings:

fs/dax.c:53:19: warning: symbol 'wait_table' was not declared. Should it be static?

Signed-off-by: Wei Yongjun <yongjun_wei <at> trendmicro.com.cn>
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index 432b9e6..fdf8f18 100644
--- a/fs/dax.c
+++ b/fs/dax.c
 <at>  <at>  -50,7 +50,7  <at>  <at> 
 #define DAX_WAIT_TABLE_BITS 12
 #define DAX_WAIT_TABLE_ENTRIES (1 << DAX_WAIT_TABLE_BITS)

-wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
+static wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];

 static int __init init_dax_wait_table(void)
 {

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Peter Chen | 18 Jul 21:13 2016
Picon

Getting the file path of a file descriptor

Hi,

  I was wondering if I intercepted the system call such as read(). Can
I get the file path of the file descriptor somehow from the kernel
process's internal data structures or some helper functions? For
example if I had previously opened a file "abcd.txt", and then called
read on it, I would like to get the filepath "abcd.txt" from the fd
for the read().

   Also aside, I was wondering if it was all possible to get the file
path of the executable of the process itself. So if I was running a
program such as "ping", when I intercept the system calls of the
program, I want to know the filepath of the ping program.

Thanks,

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alex Richman | 18 Jul 14:34 2016

Fuse fgetattr() Not Being Called By fstat()

(Resending because linux-fsdevel rejected non-text/plain content?)

Hi all,

I'm running into an issue with Fuse and fstat().

If I call fstat() on a file within a fuse file system I only see an
fgetattr() when the file is first created by the open call. If I call
fstat() on an existing file, it uses getattr() instead.

I initially thought that this was a libfuse issue, but after some
debugging I believe it is an issue with the kernel module.  I created
an issue on the libfuse project here:
https://github.com/libfuse/libfuse/issues/62 which has all the
information I've gathered so far.  If you want I can copy the contents
of the issue into an email here, but I figured there was no need to
duplicate it.

Any ideas? :)

Cheers,
- Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nicolas Pitre | 18 Jul 05:31 2016

[PULL REQUEST] [PATCH v2 00/10] allow BFLT executables on systems with a MMU

This series provides the necessary changes to allow "flat" executable
binaries meant for no-MMU systems to actually run on systems with a MMU.

This can also be found in the following git repo:

	git://git.linaro.org/people/nicolas.pitre/linux binfmt_flat_with_mmu

*Why?*

Because developing and testing natively on a large system with lots of
RAM makes it so much more convenient to use all the existing profiling
tools and debugging facilities that a kernel with lots of RAM can give.
And incidentally, those systems with lots of RAM all have a MMU.

*Why not use elf_fdpic?*

The flat executable format is simple with very small footprint
overhead, either in the executables themselves or kernel support.
This makes the flat format more suitable than elf_fdpic for very small
single-user-app embedded systems.

And while elf_fdpic binaries can run on MMU systems, flat binaries still
couldn't, which just felt wrong.

So here it is.  The no-MMU support should remain unaffected. Please consider
for pulling.

Tested on ARM only with a busybox build.

Changes since v1:
(Continue reading)

Feifei Xu | 14 Jul 15:25 2016
Picon

[Bug] fs/dcache.c: NULL pointer dereference on dentry_string_cmp

Hi,

I met crashes on ppc64le machine.

Call trace: lookup_fast( ) -> __d_lookup_rcu( ) -> dentry_cmp( ) -> 
dentry_string_cmp ( )
 From the symbolized trace and disassembly code, when doing 
dentry_string_cmp(),
dentry.d_name->name is NULL , this dereference triggered crash.

The dentry's data when crash happens: http://paste.ubuntu.com/19340635/.
And the analysis of the crash vmcore here if you're interested: 
http://paste.ubuntu.com/19359665/

Also pasted above traces on attached txt file.

Can we add check before at the begging of dentry_string_cmp() as below?
Or maybe we should not silently ignore the NULL pointer.
static inline int dentry_string_cmp(const unsigned char *cs, const 
unsigned char *ct, unsigned tcount)
  {
         do {
+             if (unlikely(!cs || !ct ))
+                     return 1;
                 if (*cs != *ct)
                         return 1;
                 cs++;

Below is the stack
trace:
(Continue reading)

Financial Service | 13 Jul 14:27 2016
Picon

Fast Loans

Hae lainaa 3% vastaus tähän viestiin lisätietoja

Apply for a loan at 3% reply to this Email for more Info
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane