@@ -797,57 +797,6 @@ void bfq_bic_update_cgroup(struct bfq_io_cq *bic, struct bio *bio)
797
797
*/
798
798
bfq_link_bfqg (bfqd , bfqg );
799
799
__bfq_bic_change_cgroup (bfqd , bic , bfqg );
800
- /*
801
- * Update blkg_path for bfq_log_* functions. We cache this
802
- * path, and update it here, for the following
803
- * reasons. Operations on blkg objects in blk-cgroup are
804
- * protected with the request_queue lock, and not with the
805
- * lock that protects the instances of this scheduler
806
- * (bfqd->lock). This exposes BFQ to the following sort of
807
- * race.
808
- *
809
- * The blkg_lookup performed in bfq_get_queue, protected
810
- * through rcu, may happen to return the address of a copy of
811
- * the original blkg. If this is the case, then the
812
- * bfqg_and_blkg_get performed in bfq_get_queue, to pin down
813
- * the blkg, is useless: it does not prevent blk-cgroup code
814
- * from destroying both the original blkg and all objects
815
- * directly or indirectly referred by the copy of the
816
- * blkg.
817
- *
818
- * On the bright side, destroy operations on a blkg invoke, as
819
- * a first step, hooks of the scheduler associated with the
820
- * blkg. And these hooks are executed with bfqd->lock held for
821
- * BFQ. As a consequence, for any blkg associated with the
822
- * request queue this instance of the scheduler is attached
823
- * to, we are guaranteed that such a blkg is not destroyed, and
824
- * that all the pointers it contains are consistent, while we
825
- * are holding bfqd->lock. A blkg_lookup performed with
826
- * bfqd->lock held then returns a fully consistent blkg, which
827
- * remains consistent until this lock is held.
828
- *
829
- * Thanks to the last fact, and to the fact that: (1) bfqg has
830
- * been obtained through a blkg_lookup in the above
831
- * assignment, and (2) bfqd->lock is being held, here we can
832
- * safely use the policy data for the involved blkg (i.e., the
833
- * field bfqg->pd) to get to the blkg associated with bfqg,
834
- * and then we can safely use any field of blkg. After we
835
- * release bfqd->lock, even just getting blkg through this
836
- * bfqg may cause dangling references to be traversed, as
837
- * bfqg->pd may not exist any more.
838
- *
839
- * In view of the above facts, here we cache, in the bfqg, any
840
- * blkg data we may need for this bic, and for its associated
841
- * bfq_queue. As of now, we need to cache only the path of the
842
- * blkg, which is used in the bfq_log_* functions.
843
- *
844
- * Finally, note that bfqg itself needs to be protected from
845
- * destruction on the blkg_free of the original blkg (which
846
- * invokes bfq_pd_free). We use an additional private
847
- * refcounter for bfqg, to let it disappear only after no
848
- * bfq_queue refers to it any longer.
849
- */
850
- blkg_path (bfqg_to_blkg (bfqg ), bfqg -> blkg_path , sizeof (bfqg -> blkg_path ));
851
800
bic -> blkcg_serial_nr = serial_nr ;
852
801
}
853
802
0 commit comments