diff for duplicates of <20120409222120.GA14149@kroah.com> diff --git a/a/1.txt b/N1/1.txt index 0c8bb34..76922e4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -8,17 +8,17 @@ On Mon, Apr 09, 2012 at 03:13:00PM -0700, Colin Cross wrote: > >> So I personally think that the real problem is this code in > >> profile_handoff_task: > >> -> >> return (ret == NOTIFY_OK) ? 1 : 0; +> >> � � � � return (ret == NOTIFY_OK) ? 1 : 0; > >> > >> and ask yourself two questions: > >> -> >> - what the hell does NOTIFY_OK/NOTIFY_DONE mean? -> >> - what happens if there are multiple notifiers that all (or some) +> >> �- what the hell does NOTIFY_OK/NOTIFY_DONE mean? +> >> �- what happens if there are multiple notifiers that all (or some) > >> return NOTIFY_OK? > >> > > NOTIFY_OK should never be a valid response for this notifier the way it's > > currently implemented, it should be NOTIFY_STOP to stop iterating the call -> > chain to avoid a double free. Right now it doesn't matter because only +> > chain to avoid a double free. �Right now it doesn't matter because only > > oprofile is actually freeing the task_struct and lowmemorykiller should be > > using NOTIFY_DONE. > > @@ -28,11 +28,11 @@ On Mon, Apr 09, 2012 at 03:13:00PM -0700, Colin Cross wrote: > > > >> I'll tell you what my answers are: > >> -> >> (a) NOTIFY_DONE is the "ok, everything is fine, you can free the +> >> �(a) NOTIFY_DONE is the "ok, everything is fine, you can free the > >> task-struct". It's also what that handoff notifier thing returns if > >> there are no notifiers registered at all. > >> -> >> So the fix to the Android lowmemorykiller is as simple as just +> >> � � �So the fix to the Android lowmemorykiller is as simple as just > >> changing NOTIFY_OK to NOTIFY_DONE, which will mean that the caller > >> will properly free the task struct. > >> @@ -43,11 +43,11 @@ On Mon, Apr 09, 2012 at 03:13:00PM -0700, Colin Cross wrote: > > NOTIFY_DONE which would result in put_task_struct() doing free_task() > > itself for a double free. > > -> >> The NOTIFY_OK/NOTIFY_DONE difference really does seem to be just +> >> � � �The NOTIFY_OK/NOTIFY_DONE difference really does seem to be just > >> "NOTIFY_OK means that I will free the task myself later". That's what > >> the oprofile uses, and it frees the task. > >> -> >> (b) But the whole interface is a total f*cking mess. If *multiple* +> >> �(b) But the whole interface is a total f*cking mess. If *multiple* > >> people return NOTIFY_OK, they're royally fucked. And the whole (and > >> only) point of notifiers is that you can register multiple different > >> ones independently. @@ -59,7 +59,7 @@ On Mon, Apr 09, 2012 at 03:13:00PM -0700, Colin Cross wrote: > >> > > > > Right, we can't handoff the freeing of the task_struct to more than one -> > notifier. It seems misdesigned from the beginning and what we really want +> > notifier. �It seems misdesigned from the beginning and what we really want > > is to hijack task->usage for __put_task_struct(task) if we have such a > > notifier callchain and require each one (currently just oprofile) to take > > a reference on task->usage for NOTIFY_OK and then be responsible for @@ -68,10 +68,10 @@ On Mon, Apr 09, 2012 at 03:13:00PM -0700, Colin Cross wrote: > > > > That's _if_ we want to continue to have such an interface in the first > > place where it's only really necessary right now for oprofile (and, hence, -> > wasn't implemented in an extendable way). I'm thinking the +> > wasn't implemented in an extendable way). �I'm thinking the > > lowmemorykiller, as I eluded to, could be written in a way where we can > > detect if a thread we've already killed has exited yet before killing -> > another one. We can't just store a pointer to the task_struct of the +> > another one. �We can't just store a pointer to the task_struct of the > > killed task since it could be reused for a fork later, but we could use > > TIF_MEMDIE like the oom killer does. > diff --git a/a/content_digest b/N1/content_digest index a175e01..c5078bb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -34,17 +34,17 @@ "> >> So I personally think that the real problem is this code in\n" "> >> profile_handoff_task:\n" "> >>\n" - "> >> \302\240 \302\240 \302\240 \302\240 return (ret == NOTIFY_OK) ? 1 : 0;\n" + "> >> \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 return (ret == NOTIFY_OK) ? 1 : 0;\n" "> >>\n" "> >> and ask yourself two questions:\n" "> >>\n" - "> >> \302\240- what the hell does NOTIFY_OK/NOTIFY_DONE mean?\n" - "> >> \302\240- what happens if there are multiple notifiers that all (or some)\n" + "> >> \303\257\302\277\302\275- what the hell does NOTIFY_OK/NOTIFY_DONE mean?\n" + "> >> \303\257\302\277\302\275- what happens if there are multiple notifiers that all (or some)\n" "> >> return NOTIFY_OK?\n" "> >>\n" "> > NOTIFY_OK should never be a valid response for this notifier the way it's\n" "> > currently implemented, it should be NOTIFY_STOP to stop iterating the call\n" - "> > chain to avoid a double free. \302\240Right now it doesn't matter because only\n" + "> > chain to avoid a double free. \303\257\302\277\302\275Right now it doesn't matter because only\n" "> > oprofile is actually freeing the task_struct and lowmemorykiller should be\n" "> > using NOTIFY_DONE.\n" "> >\n" @@ -54,11 +54,11 @@ "> >\n" "> >> I'll tell you what my answers are:\n" "> >>\n" - "> >> \302\240(a) NOTIFY_DONE is the \"ok, everything is fine, you can free the\n" + "> >> \303\257\302\277\302\275(a) NOTIFY_DONE is the \"ok, everything is fine, you can free the\n" "> >> task-struct\". It's also what that handoff notifier thing returns if\n" "> >> there are no notifiers registered at all.\n" "> >>\n" - "> >> \302\240 \302\240 \302\240So the fix to the Android lowmemorykiller is as simple as just\n" + "> >> \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275So the fix to the Android lowmemorykiller is as simple as just\n" "> >> changing NOTIFY_OK to NOTIFY_DONE, which will mean that the caller\n" "> >> will properly free the task struct.\n" "> >>\n" @@ -69,11 +69,11 @@ "> > NOTIFY_DONE which would result in put_task_struct() doing free_task()\n" "> > itself for a double free.\n" "> >\n" - "> >> \302\240 \302\240 \302\240The NOTIFY_OK/NOTIFY_DONE difference really does seem to be just\n" + "> >> \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275The NOTIFY_OK/NOTIFY_DONE difference really does seem to be just\n" "> >> \"NOTIFY_OK means that I will free the task myself later\". That's what\n" "> >> the oprofile uses, and it frees the task.\n" "> >>\n" - "> >> \302\240(b) But the whole interface is a total f*cking mess. If *multiple*\n" + "> >> \303\257\302\277\302\275(b) But the whole interface is a total f*cking mess. If *multiple*\n" "> >> people return NOTIFY_OK, they're royally fucked. And the whole (and\n" "> >> only) point of notifiers is that you can register multiple different\n" "> >> ones independently.\n" @@ -85,7 +85,7 @@ "> >>\n" "> >\n" "> > Right, we can't handoff the freeing of the task_struct to more than one\n" - "> > notifier. \302\240It seems misdesigned from the beginning and what we really want\n" + "> > notifier. \303\257\302\277\302\275It seems misdesigned from the beginning and what we really want\n" "> > is to hijack task->usage for __put_task_struct(task) if we have such a\n" "> > notifier callchain and require each one (currently just oprofile) to take\n" "> > a reference on task->usage for NOTIFY_OK and then be responsible for\n" @@ -94,10 +94,10 @@ "> >\n" "> > That's _if_ we want to continue to have such an interface in the first\n" "> > place where it's only really necessary right now for oprofile (and, hence,\n" - "> > wasn't implemented in an extendable way). \302\240I'm thinking the\n" + "> > wasn't implemented in an extendable way). \303\257\302\277\302\275I'm thinking the\n" "> > lowmemorykiller, as I eluded to, could be written in a way where we can\n" "> > detect if a thread we've already killed has exited yet before killing\n" - "> > another one. \302\240We can't just store a pointer to the task_struct of the\n" + "> > another one. \303\257\302\277\302\275We can't just store a pointer to the task_struct of the\n" "> > killed task since it could be reused for a fork later, but we could use\n" "> > TIF_MEMDIE like the oom killer does.\n" "> \n" @@ -117,4 +117,4 @@ "\n" greg k-h -0d1015ca16277032ff0052996fcc85572d1143809ef43ec03a497f3ef9b815be +1b9f126af5c6af10db9ba421fd523f12ecfb07df74bd7ab4ecb9d1c0254de78c
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.