All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter LaDow <petela@gocougs.wsu.edu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Process Hang in __read_seqcount_begin
Date: Mon, 22 Oct 2012 12:24:49 -0700	[thread overview]
Message-ID: <CAN8Q1EcTRsHjCJD90q0bKRJFMvi7Vn8YRsyQTAHNtTFVuuNdWQ@mail.gmail.com> (raw)
In-Reply-To: <CAN8Q1EeqmHMHD-VUgr7Wzv0Z_DAD1SrEniftg==L14d+hGwu+Q@mail.gmail.com>

> Now, is preemption required to be disabled in non-SMP systems?

I did more digging, and I found this.

In linux/netfilter/x_tables.h, there is the definition of
xt_write_recseq_begin.  This function updates the sequence number for
the sequence locks.  This is called in the iptables kernel code.  From
the header for the function:

/**
 * xt_write_recseq_begin - start of a write section
 *
 * Begin packet processing : all readers must wait the end
 * 1) Must be called with preemption disabled
 * 2) softirqs must be disabled too (or we should use irqsafe_cpu_add())
 * Returns :
 *  1 if no recursion on this cpu
 *  0 if recursion detected
 */

Note #1.  Your earlier response what that local_bh_disable should
disable preemption.  Indeed, looking at the calls to
xt_write_recseq_begin in the code, all are preceeded by a call to
local_bh_disable().  This call (local_bh_disable) is modified by the
RT patch.  The standard kernel calls __local_bh_disable, which does
quite a bit of work.  From the standard kernel:

static inline void _local_bh_enable_ip(unsigned long ip)
{
        WARN_ON_ONCE(in_irq() || irqs_disabled());
#ifdef CONFIG_TRACE_IRQFLAGS
        local_irq_disable();
#endif
        /*
         * Are softirqs going to be turned on now:
         */
        if (softirq_count() == SOFTIRQ_DISABLE_OFFSET)
                trace_softirqs_on(ip);
        /*
         * Keep preemption disabled until we are done with
         * softirq processing:
         */
        sub_preempt_count(SOFTIRQ_DISABLE_OFFSET - 1);

        if (unlikely(!in_interrupt() && local_softirq_pending()))
                do_softirq();

        dec_preempt_count();
#ifdef CONFIG_TRACE_IRQFLAGS
        local_irq_enable();
#endif
        preempt_check_resched();
}

But the patch changes things:

void local_bh_disable(void)
{
       migrate_disable();
       current->softirq_nestcnt++;
}

And the call to migrate_disable() is defined as a macro, depending
upon the configuration.  From the patch:

#ifdef CONFIG_PREEMPT_RT_FULL
# define preempt_disable_rt()           preempt_disable()
# define preempt_enable_rt()            preempt_enable()
# define preempt_disable_nort()         do { } while (0)
# define preempt_enable_nort()          do { } while (0)
# ifdef CONFIG_SMP
   extern void migrate_disable(void);
   extern void migrate_enable(void);
# else /* CONFIG_SMP */
#  define migrate_disable()             do { } while (0)
#  define migrate_enable()              do { } while (0)
# endif /* CONFIG_SMP */
#else
# define preempt_disable_rt()           do { } while (0)
# define preempt_enable_rt()            do { } while (0)
# define preempt_disable_nort()         preempt_disable()
# define preempt_enable_nort()          preempt_enable()
# define migrate_disable()              preempt_disable()
# define migrate_enable()               preempt_enable()
#endif

In our configuration, we have CONFIG_PREEMPT_RT_FULL defined, and do
not have CONFIG_SMP defined.  So migrate_enable() becomes a NOP.  This
seems to violate the requirement on the xt_write_recseq_begin
requirement.  However, enabling SMP does enable the actual function.

Should local_bh_disable() call the actual function in non-SMP systems
to meet the requirements for xt_write_recseq_begin()?

  reply	other threads:[~2012-10-22 19:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 16:46 Process Hang in __read_seqcount_begin Peter LaDow
2012-10-22 17:01 ` Eric Dumazet
2012-10-22 17:25   ` Peter LaDow
2012-10-22 19:24     ` Peter LaDow [this message]
2012-10-24  0:15       ` Peter LaDow
2012-10-24  4:32         ` Eric Dumazet
2012-10-24 16:30           ` Peter LaDow
2012-10-24 16:44             ` Eric Dumazet
2012-10-26 16:15           ` Peter LaDow
2012-10-26 16:48             ` Eric Dumazet
2012-10-26 18:51               ` Peter LaDow
2012-10-26 20:53                 ` Thomas Gleixner
2012-10-26 21:05                 ` Eric Dumazet
2012-10-26 21:25                   ` Peter LaDow
2012-10-26 21:54                     ` Thomas Gleixner
2012-10-30 23:09                       ` Peter LaDow
2012-10-31  0:33                         ` Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2012-07-28 20:43 Peter LaDow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN8Q1EcTRsHjCJD90q0bKRJFMvi7Vn8YRsyQTAHNtTFVuuNdWQ@mail.gmail.com \
    --to=petela@gocougs.wsu.edu \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.