Re: [Patch 7/10]: ext3 online resize: SMP locking for group metadata

From: Pavel Machek (pavel_at_ucw.cz)
Date: 10/01/04

  • Next message: David Mosberger: "Re: [ia64 patch 2.6.9-rc3] build: ccache/distcc fix for ia64"
    Date:	Fri, 1 Oct 2004 12:18:22 +0200
    To: Stephen Tweedie <sct@redhat.com>
    
    

    Hi!

    > Fix the SMP locking for group metadata in online resize.
    >
    > Most of the resize is simply not dangerous from an SMP point of view, as
    > we're adding new data beyond the end of the device and so we're
    > guaranteed that no existing CPUs can already be using that data. But we
    > need to be extremely careful about the ordering when enabling that new
    > data.
    >
    > The key to this is sb->s_groups_count; when that is raised, it enables
    > new space on a filesystem, and the kernel will suddenly start accessing
    > all of the newly-created tables for that space.
    >
    > The precise rules we use are:
    >
    > * Writers of s_groups_count *must* hold lock_super
    > AND
    > * Writers must perform a smp_wmb() after updating all dependent
    > data and before modifying the groups count
    >
    > * Readers must hold lock_super() over the access
    > OR
    > * Readers must perform an smp_rmb() after reading the groups count
    > and before reading any dependent data.
    >
    > This leaves the hot path, where s_groups_count is referenced, requiring
    > an smp_rmb(); but no other locking on that hot path is required.

    Should not s_groups_count be atomic_t, then? Is it possible that
    normal read sees only half-updated value?

    [I know this is non-issue at least on i386, and probably on most
    architectures as long as s_groups_count is aligned...

                                                            Pavel

    -- 
    People were complaining that M$ turns users into beta-testers...
    ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: David Mosberger: "Re: [ia64 patch 2.6.9-rc3] build: ccache/distcc fix for ia64"

    Relevant Pages

    • Re: So, Poll is not scalable... what to do?
      ... >>little bit more under the hood ... kernel do that by unblocking the thread, handles SMP cases, etc. ... > If you remove the realtime priority array (disable RT scheduling support) ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [CFT][PATCH] 2.6.4-rc1 remove x86 boot page tables
      ... For VISWS I think you actually need to turn paging off explicitly. ... of my patch sent to akpm and which is now in -mm (basically the SMP ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6.0-mm2] e100 driver hangs after period of moderate receive load
      ... My test consists of downloading an iso from RedHat's ftp ... I doubt that downloading a Red Hat iso would give ... This was on a 2-way SMP box. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.10-rc3, syslogd hangs then processes get stuck in schedule_timeout
      ... > stops writing output, then everything that does schedule_timeouthangs, ... > I'm running 2.6.10-rc3, compiled with smp. ... instances of cron running. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: emu10k1 under kernel 2.6?
      ... > Btw, the system is SMP, a Tyan Tiger MPX with two Athlon XPs. ... I have a tyan tiger MP with two Athlon MPs, and my emu10k1 does not work ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)