RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 691267 - [RFE] kernel: add new syncfs syscall
Summary: [RFE] kernel: add new syncfs syscall
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 6.2
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 691474
TreeView+ depends on / blocked
 
Reported: 2011-03-28 01:59 UTC by Harshula Jayasuriya
Modified: 2011-12-06 12:46 UTC (History)
4 users (show)

Fixed In Version: kernel-2.6.32-180.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
: 691474 (view as bug list)
Environment:
Last Closed: 2011-12-06 12:46:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1530 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 6 kernel security, bug fix and enhancement update 2011-12-06 01:45:35 UTC

Description Harshula Jayasuriya 2011-03-28 01:59:53 UTC
------------------------------------------------------------
commit b7ed78f56575074f29ec99d8984f347f6c99c914
Author: Sage Weil <sage>
Date:   Thu Mar 10 11:31:30 2011 -0800

    introduce sys_syncfs to sync a single file system
    
    It is frequently useful to sync a single file system, instead of all
    mounted file systems via sync(2):
    
     - On machines with many mounts, it is not at all uncommon for some of
       them to hang (e.g. unresponsive NFS server).  sync(2) will get stuck on
       those and may never get to the one you do care about (e.g., /).
     - Some applications write lots of data to the file system and then
       want to make sure it is flushed to disk.  Calling fsync(2) on each
       file introduces unnecessary ordering constraints that result in a large
       amount of sub-optimal writeback/flush/commit behavior by the file
       system.
    
    There are currently two ways (that I know of) to sync a single super_block:
    
     - BLKFLSBUF ioctl on the block device: That also invalidates the bdev
       mapping, which isn't usually desirable, and doesn't work for non-block
       file systems.
     - 'mount -o remount,rw' will call sync_filesystem as an artifact of the
       current implemention.  Relying on this little-known side effect for
       something like data safety sounds foolish.
    
    Both of these approaches require root privileges, which some applications
    do not have (nor should they need?) given that sync(2) is an unprivileged
    operation.
    
    This patch introduces a new system call syncfs(2) that takes an fd and
    syncs only the file system it references.  Maybe someday we can
    
     $ sync /some/path
    
    and not get
    
     sync: ignoring all arguments
    
    The syscall is motivated by comments by Al and Christoph at the last LSF.
    syncfs(2) seems like an appropriate name given statfs(2).
    
    A similar ioctl was also proposed a while back, see
    	http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2
    
    Signed-off-by: Sage Weil <sage>
    Signed-off-by: Al Viro <viro.org.uk>

commit c7a1fcd8e6e0c3c8f4f8f74fc926ff04da3bf7a7
Author: Andrew Morton <akpm>
Date:   Tue Mar 22 16:30:07 2011 -0700

    include/asm-generic/unistd.h: fix syncfs syscall number
    
    syncfs() is duplicating name_to_handle_at() due to a merging mistake.
    
    Cc: Sage Weil <sage>
    Cc: Al Viro <viro.org.uk>
    Signed-off-by: Andrew Morton <akpm>
    Signed-off-by: Linus Torvalds <torvalds>
------------------------------------------------------------

Architecture specific commits:
------------------------------------------------------------
commit 1bbf28756149a0aa0e3c8a74cea9bbe715639027
Author: Ralf Baechle <ralf>
Date:   Fri Mar 25 18:45:20 2011 +0100

    MIPS: Wire up syncfs(2).
    
    Signed-off-by: Ralf Baechle <ralf>

commit d0d2e31af691ed3dbb4e556bf939b86ef745e6a3
Author: Heiko Carstens <heiko.carstens.com>
Date:   Wed Mar 23 10:15:58 2011 +0100

    [S390] wire up sys_syncfs
    
    Signed-off-by: Heiko Carstens <heiko.carstens.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky.com>


commit 4e3d96deff59d126cfa289645e136e295e65480f
Author: Mike Frysinger <vapier>
Date:   Tue Mar 22 13:41:22 2011 -0400

    Blackfin: wire up new syncfs syscall
    
    Signed-off-by: Mike Frysinger <vapier>

commit 9298168d16faf939141cddc836b6b9b1ef2a8aac
Author: Tony Luck <tony.luck>
Date:   Tue Mar 22 10:54:24 2011 -0700

    [IA64] New syscalls for 2.6.39
    
    Four new syscalls:
    	sys_name_to_handle_at
    	sys_open_by_handle_at
    	sys_clock_adjtime
    	sys_syncfs
    
    Signed-off-by: Tony Luck <tony.luck>

commit 2a03cfbd906dc9bbf5e9a97727cf4ba1889d4829
Author: Paul Mundt <lethal>
Date:   Tue Mar 22 21:56:08 2011 +0900

    sh: wire up sys_syncfs.
    
    Signed-off-by: Paul Mundt <lethal>
------------------------------------------------------------

Comment 1 Harshula Jayasuriya 2011-03-28 02:09:50 UTC
Upstream discussion:
http://thread.gmane.org/gmane.linux.file-systems/51497/

Comment 2 Eric Sandeen 2011-03-28 18:33:35 UTC
Hm, seems upstream doesn't have it wired up on PPC?

Comment 3 Harshula Jayasuriya 2011-03-29 01:00:28 UTC
$ grep -lR __NR_syncfs arch/*
arch/blackfin/include/asm/unistd.h
arch/ia64/include/asm/unistd.h
arch/mips/include/asm/unistd.h
arch/s390/include/asm/unistd.h
arch/sh/include/asm/unistd_32.h
arch/sh/include/asm/unistd_64.h
arch/x86/include/asm/unistd_32.h
arch/x86/include/asm/unistd_64.h

Comment 4 Eric Sandeen 2011-03-29 04:44:41 UTC
A patch for m68k just got sent on the 23rd.

Anyway, not a big deal to wire it up for ppc; and we don't usually patch arches we don't build in any case.

Comment 7 Lukáš Czerner 2011-06-16 13:38:36 UTC
Sent to rhkernel-list. I have backported following upstream patches and tested on x86_64, i686, s390, ppc64.

    b7ed78f56575074f29ec99d8984f347f6c99c914
        introduce sys_syncfs to sync a single file system
    c7a1fcd8e6e0c3c8f4f8f74fc926ff04da3bf7a7
        include/asm-generic/unistd.h: fix syncfs syscall numbe
    d0d2e31af691ed3dbb4e556bf939b86ef745e6a3
        [S390] wire up sys_syncfs
    834796a8493809ae6667b65c4c044066f41d32c7
        powerpc: Wire up new syscalls

Thanks!
-Lukas

Comment 9 Aristeu Rozanski 2011-08-06 16:09:52 UTC
Patch(es) available on kernel-2.6.32-180.el6

Comment 13 errata-xmlrpc 2011-12-06 12:46:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1530.html


Note You need to log in before you can comment on or make changes to this bug.