Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1358910 > unrolled thread
| Started by | Martin Kepplinger <martink@posteo.de> |
|---|---|
| First post | 2016-03-16 12:50 +0100 |
| Last post | 2016-03-16 16:20 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] mmc: card: don't use PF_MEMALLOC Martin Kepplinger <martink@posteo.de> - 2016-03-16 12:50 +0100
Re: [PATCH] mmc: card: don't use PF_MEMALLOC Jens Axboe <axboe@fb.com> - 2016-03-16 15:50 +0100
Re: [PATCH] mmc: card: don't use PF_MEMALLOC Martin Kepplinger <martink@posteo.de> - 2016-03-16 16:10 +0100
Re: [PATCH] mmc: card: don't use PF_MEMALLOC Jens Axboe <axboe@fb.com> - 2016-03-16 16:20 +0100
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-03-16 12:50 +0100 |
| Subject | [PATCH] mmc: card: don't use PF_MEMALLOC |
| Message-ID | <rdi7E-8pT-5@gated-at.bofh.it> |
PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory
reclaim and mm is not in control, strange hang-up or OOM Killer invocation
could happen.
Signed-off-by: Martin Kepplinger <martink@posteo.de>
---
I use MMC cards with this change perfectly fine. As I understand it,
even *if* PF_MEMALLOC has a real reason to be here, I think it should
be very well documented.
drivers/mmc/card/queue.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 6f4323c..be71249 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -51,8 +51,6 @@ static int mmc_queue_thread(void *d)
struct mmc_queue *mq = d;
struct request_queue *q = mq->queue;
- current->flags |= PF_MEMALLOC;
-
down(&mq->thread_sem);
do {
struct request *req = NULL;
--
2.1.4
[toc] | [next] | [standalone]
| From | Jens Axboe <axboe@fb.com> |
|---|---|
| Date | 2016-03-16 15:50 +0100 |
| Message-ID | <rdkVQ-1NZ-15@gated-at.bofh.it> |
| In reply to | #1358910 |
On 03/16/2016 04:43 AM, Martin Kepplinger wrote: > PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory > reclaim and mm is not in control, strange hang-up or OOM Killer invocation > could happen. > > Signed-off-by: Martin Kepplinger <martink@posteo.de> > --- > I use MMC cards with this change perfectly fine. As I understand it, > even *if* PF_MEMALLOC has a real reason to be here, I think it should > be very well documented. Did you try swap on mmcblk? -- Jens Axboe
[toc] | [prev] | [next] | [standalone]
| From | Martin Kepplinger <martink@posteo.de> |
|---|---|
| Date | 2016-03-16 16:10 +0100 |
| Message-ID | <rdlfd-2aF-45@gated-at.bofh.it> |
| In reply to | #1359060 |
Am 2016-03-16 um 15:41 schrieb Jens Axboe: > On 03/16/2016 04:43 AM, Martin Kepplinger wrote: >> PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory >> reclaim and mm is not in control, strange hang-up or OOM Killer >> invocation >> could happen. >> >> Signed-off-by: Martin Kepplinger <martink@posteo.de> >> --- >> I use MMC cards with this change perfectly fine. As I understand it, >> even *if* PF_MEMALLOC has a real reason to be here, I think it should >> be very well documented. > > Did you try swap on mmcblk? > No I haven't even thought about that :) If you know it can be necessary in that case, it's obviously fine. A comment would still be good though.
[toc] | [prev] | [next] | [standalone]
| From | Jens Axboe <axboe@fb.com> |
|---|---|
| Date | 2016-03-16 16:20 +0100 |
| Message-ID | <rdloT-2eB-25@gated-at.bofh.it> |
| In reply to | #1359077 |
On 03/16/2016 08:07 AM, Martin Kepplinger wrote: > Am 2016-03-16 um 15:41 schrieb Jens Axboe: >> On 03/16/2016 04:43 AM, Martin Kepplinger wrote: >>> PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory >>> reclaim and mm is not in control, strange hang-up or OOM Killer >>> invocation >>> could happen. >>> >>> Signed-off-by: Martin Kepplinger <martink@posteo.de> >>> --- >>> I use MMC cards with this change perfectly fine. As I understand it, >>> even *if* PF_MEMALLOC has a real reason to be here, I think it should >>> be very well documented. >> >> Did you try swap on mmcblk? >> > > No I haven't even thought about that :) If you know it can be necessary > in that case, it's obviously fine. A comment would still be good though. That's why it is there! So yes, adding a comment to that effect would be a better path forward. -- Jens Axboe
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web