On Mon, Aug 7, 2017 at 8:58 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Tue, Aug 8, 2017 at 2:42 AM, Christopher Li <sparse@xxxxxxxxxxx> wrote: >> On Mon, Aug 7, 2017 at 8:23 PM, Luc Van Oostenryck >> <luc.vanoostenryck@xxxxxxxxx> wrote: >>> If you don't mind, it would be nice if you could use the pull request >>> I sent here: http://marc.info/?l=linux-sparse&m=150188507213269&w=4 >>> (you never saw it because I copy-pasted "[PATCH v3]" in the title of >>> the cover page instead of using "[PATCH v4]" and so used the v3 and >>> corrected the s/list/__list/ by hand). >>> But it's not very important. >> >> I did not find that git pull url due to the V3 title. I did look for it. >> >> When I look at the patch, there is some compile error on one of the >> patch (patch 4?). I just fix it by hand. I assume the git pull has the >> same error because the patch are generated from git. >> >> I just checked, that compile error still on the git url you send out >> in the email. I still can't use it > > Are you sure? > in the link I pasted here above, the git branch is: > > git://github.com/lucvoo/sparse.git fix-nested-pseudo-users-deletion-v4 > > aka: bddf7d1e4ed81c3def7c6de2796a5489ca678399 Yes, see the git log -p bddf7d1e4ed81c3def7c6de2796a5489ca678399 commit bddf7d1e4ed81c3def7c6de2796a5489ca678399 (luc/fix-nested-pseudo-users-deletion-v4) Author: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> Date: Fri Aug 4 21:50:20 2017 +0200 mark pseudo users as deleted instead of removing them This will fix the (rare) problems with deletion while doing nested ptrlist walking that occurs when doing recursive kill_instruction() - remove_usage() - kill_instruction() Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> diff --git a/ptrlist.h b/ptrlist.h index 1839b0f..78625c8 100644 --- a/ptrlist.h +++ b/ptrlist.h @@ -162,7 +162,7 @@ static inline void *last_ptr_list(struct ptr_list *list) for (__nr = 0; __nr < __list->nr; __nr++) { \ do { \ ptr = PTR_ENTRY(__list,__nr); \ - if (list->rm && !ptr) \ + if (__list->rm && !ptr) \ continue; \ do { @@ -185,7 +185,7 @@ static inline void *last_ptr_list(struct ptr_list *list) while (--__nr >= 0) { \ do { \ ptr = PTR_ENTRY(__list,__nr); \ - if (list->rm && !ptr) \ + if (__list->rm && !ptr) \ continue; \ do { That change is your later patch fixing the compile error in the previous patch. I have to move this change into the previous patch. >> Also, can you please give the pull request a dedicate branch, >> like "for-chris", not a tag? I don't want to pull from random branch >> and end up merging between your topic branches. > > It won't change anything, in both case it's just a name for something > (and using specific name for specific thing is a good thing I think) > but no problem, it's fine for me. You can still have your specific topic branch. I want a unified view to pull from you. It does change some thing. I find out that your like to just assign the tag to the topic branch you want me to pull from. The last "for-chris" tag might not be fast forwardable to the next "for-chris" tag. Think that "for-chris" as if your own luc-next. You can still maintain a lot of topic branches. You aggregate the stable enough bits as luc-next for others to try out. That is where I pull from, and I expect that to be fast forwardable from master. The difference will be, you will merge between your own branches before let me pull. I don't need to keep track of what is the updated version of different topic branches I have merged from you. Currently, rebase the sparse-next with your topic branch pulled is very tricky. I need to create a stable point for your aggregated topic branches. That is equivalent of the "for-chris" branch on my side. Then I rebase sparse-next on that. If you maintain that "for-chris" to aggregate your own topic branch. I can just use "for-chris" as a base to rease the sparse-next, I only need to rebase patches not from you. I do want to have the flexibility to rebase spase-next. It is just how to do it in a way impact you less. >> I often need to seek clarify if this patches series is mean for merge. >> If you make that in the dedicate pull branch, I will know for sure. Let me clarify that does not stop you from send out review with specific topic branch. I want a merged unified view from you to use as my base. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
