Details

    • Bug
    • Resolution: Fixed
    • Critical
    • Lustre 2.8.0
    • Lustre 2.7.0
    • 3
    • 9223372036854775807

    Description

      According to the existing code, I can guess that cl_client_cache->ccc_lru needs spin_lock when being referred but the below code looks violating the rule.

      osc_lru_reclaim
      long osc_lru_reclaim(struct client_obd *cli)
      {
              struct cl_env_nest nest;
              struct lu_env *env;
              struct cl_client_cache *cache = cli->cl_cache;
              long rc = 0;
              int max_scans;
              ENTRY;
      
              LASSERT(cache != NULL);
              LASSERT(!list_empty(&cache->ccc_lru)); <--- HERE
      
              .....
      
              spin_lock(&cache->ccc_lru_lock);
                                        <---- The LASSERT should be here, isn't it ?
              cache->ccc_lru_shrinkers++;
      
              ....
      

      Actually I sometimes see LBUG in osc_lru_reclaim when running multiple WRITEs in the same time. So I'm convinced this LASSERT should be moved to the locked section, or the LASSERT can touch ccc_lru while the other is doing linked list operation on ccc_lru.

      Attachments

        Activity

          [LU-6624] LBUG in osc_lru_reclaim
          pjones Peter Jones added a comment -

          Landed for 2.8

          pjones Peter Jones added a comment - Landed for 2.8

          Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/14901/
          Subject: LU-6624 osc: LBUG in osc_lru_reclaim
          Project: fs/lustre-release
          Branch: master
          Current Patch Set:
          Commit: 1fee634f1ebfeccb1770951ca7b576f8b6e733a0

          gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/14901/ Subject: LU-6624 osc: LBUG in osc_lru_reclaim Project: fs/lustre-release Branch: master Current Patch Set: Commit: 1fee634f1ebfeccb1770951ca7b576f8b6e733a0

          Good point, if there is only one OSC, it could be empty temporarily.

          jay Jinshan Xiong (Inactive) added a comment - Good point, if there is only one OSC, it could be empty temporarily.
          nozaki Hiroya Nozaki (Inactive) added a comment - - edited

          OK, I'll post the backtrace when this case is reproduced.
          Btw, IMHO, if some cl_lru_osc()s are under list_move_tail() operation, ccc_lru can be empty temporarily, isn't it ?

          nozaki Hiroya Nozaki (Inactive) added a comment - - edited OK, I'll post the backtrace when this case is reproduced. Btw, IMHO, if some cl_lru_osc()s are under list_move_tail() operation, ccc_lru can be empty temporarily, isn't it ?

          cache->ccc_lru is the LRU list of all OSCs. Now that osc_lru_reclaim() is called, which means there exists at least one OSC, so this list shouldn't be NULL.

          Can you post the backtrace to this ticket when you see it next time?

          jay Jinshan Xiong (Inactive) added a comment - cache->ccc_lru is the LRU list of all OSCs. Now that osc_lru_reclaim() is called, which means there exists at least one OSC, so this list shouldn't be NULL. Can you post the backtrace to this ticket when you see it next time?

          Hiroya Nozaki (nozaki.hiroya@jp.fujitsu.com) uploaded a new patch: http://review.whamcloud.com/14901
          Subject: LU-6624 osc: LBUG in osc_lru_reclaim
          Project: fs/lustre-release
          Branch: master
          Current Patch Set: 1
          Commit: 3782cd123a74302c22735db5f9c5cafda625280e

          gerrit Gerrit Updater added a comment - Hiroya Nozaki (nozaki.hiroya@jp.fujitsu.com) uploaded a new patch: http://review.whamcloud.com/14901 Subject: LU-6624 osc: LBUG in osc_lru_reclaim Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 3782cd123a74302c22735db5f9c5cafda625280e

          I'll upload a trivial patch soon.

          nozaki Hiroya Nozaki (Inactive) added a comment - I'll upload a trivial patch soon.

          People

            jay Jinshan Xiong (Inactive)
            nozaki Hiroya Nozaki (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: