From 7b8cad3542ed83669272a86d3fbf3b48994ebf54 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 13 Nov 2012 15:22:45 -0800 Subject: [PATCH] 3.6-stable patches added patches: drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch drm-vmwgfx-fix-hibernation-device-reset.patch futex-handle-futex_pi-owner_died-take-over-correctly.patch mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch mmc-sh_mmcif-fix-use-after-free.patch --- ...e-missing-regs-to-the-vm-reg-checker.patch | 49 ++++ ...e-missing-regs-to-the-vm-reg-checker.patch | 40 ++++ ...ld-bug-when-trying-to-pin-gmr-memory.patch | 31 +++ ...-vmwgfx-fix-hibernation-device-reset.patch | 36 +++ ...ex_pi-owner_died-take-over-correctly.patch | 225 ++++++++++++++++++ ...-dereference-in-sdhci_request-tuning.patch | 52 ++++ .../mmc-sh_mmcif-fix-use-after-free.patch | 35 +++ queue-3.6/series | 7 + 8 files changed, 475 insertions(+) create mode 100644 queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch create mode 100644 queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch create mode 100644 queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch create mode 100644 queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch create mode 100644 queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch create mode 100644 queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch create mode 100644 queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch diff --git a/queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch b/queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch new file mode 100644 index 00000000000..636afed6068 --- /dev/null +++ b/queue-3.6/drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch @@ -0,0 +1,49 @@ +From 860fe2f05fa2eacac84368e23547ec8cf3cc6652 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Thu, 8 Nov 2012 10:08:04 -0500 +Subject: drm/radeon/cayman: add some missing regs to the VM reg checker + +From: Alex Deucher + +commit 860fe2f05fa2eacac84368e23547ec8cf3cc6652 upstream. + +These regs were being wronly rejected leading to rendering +issues. + +fixes: +https://bugs.freedesktop.org/show_bug.cgi?id=56876 + +Signed-off-by: Alex Deucher +Reviewed-by: Michel Dänzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/evergreen_cs.c | 3 +++ + drivers/gpu/drm/radeon/evergreend.h | 4 ++++ + 2 files changed, 7 insertions(+) + +--- a/drivers/gpu/drm/radeon/evergreen_cs.c ++++ b/drivers/gpu/drm/radeon/evergreen_cs.c +@@ -2725,6 +2725,9 @@ static bool evergreen_vm_reg_valid(u32 r + /* check config regs */ + switch (reg) { + case GRBM_GFX_INDEX: ++ case CP_STRMOUT_CNTL: ++ case CP_COHER_CNTL: ++ case CP_COHER_SIZE: + case VGT_VTX_VECT_EJECT_REG: + case VGT_CACHE_INVALIDATION: + case VGT_GS_VERTEX_REUSE: +--- a/drivers/gpu/drm/radeon/evergreend.h ++++ b/drivers/gpu/drm/radeon/evergreend.h +@@ -87,6 +87,10 @@ + + #define CONFIG_MEMSIZE 0x5428 + ++#define CP_STRMOUT_CNTL 0x84FC ++ ++#define CP_COHER_CNTL 0x85F0 ++#define CP_COHER_SIZE 0x85F4 + #define CP_COHER_BASE 0x85F8 + #define CP_STALLED_STAT1 0x8674 + #define CP_STALLED_STAT2 0x8678 diff --git a/queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch b/queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch new file mode 100644 index 00000000000..65f452036d8 --- /dev/null +++ b/queue-3.6/drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch @@ -0,0 +1,40 @@ +From f418b88aad0c42b4caf4d79a0cf8d14a5d0a2284 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Thu, 8 Nov 2012 10:13:24 -0500 +Subject: drm/radeon/si: add some missing regs to the VM reg checker + +From: Alex Deucher + +commit f418b88aad0c42b4caf4d79a0cf8d14a5d0a2284 upstream. + +This register is needed for streamout to work properly. + +Signed-off-by: Alex Deucher +Reviewed-by: Michel Dänzer +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/si.c | 1 + + drivers/gpu/drm/radeon/sid.h | 1 + + 2 files changed, 2 insertions(+) + +--- a/drivers/gpu/drm/radeon/si.c ++++ b/drivers/gpu/drm/radeon/si.c +@@ -2472,6 +2472,7 @@ static bool si_vm_reg_valid(u32 reg) + /* check config regs */ + switch (reg) { + case GRBM_GFX_INDEX: ++ case CP_STRMOUT_CNTL: + case VGT_VTX_VECT_EJECT_REG: + case VGT_CACHE_INVALIDATION: + case VGT_ESGS_RING_SIZE: +--- a/drivers/gpu/drm/radeon/sid.h ++++ b/drivers/gpu/drm/radeon/sid.h +@@ -424,6 +424,7 @@ + # define RDERR_INT_ENABLE (1 << 0) + # define GUI_IDLE_INT_ENABLE (1 << 19) + ++#define CP_STRMOUT_CNTL 0x84FC + #define SCRATCH_REG0 0x8500 + #define SCRATCH_REG1 0x8504 + #define SCRATCH_REG2 0x8508 diff --git a/queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch b/queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch new file mode 100644 index 00000000000..79033f579d8 --- /dev/null +++ b/queue-3.6/drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch @@ -0,0 +1,31 @@ +From afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 Mon Sep 17 00:00:00 2001 +From: Thomas Hellstrom +Date: Fri, 9 Nov 2012 10:45:14 +0100 +Subject: drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory + +From: Thomas Hellstrom + +commit afcc87aa6a233e52df73552dc1dc9ae3881b7cc8 upstream. + +Signed-off-by: Thomas Hellstrom +Reviewed-by: Brian Paul +Reviewed-by: Dmitry Torokhov +Cc: linux-graphics-maintainer@vmware.com +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c +@@ -306,7 +306,7 @@ void vmw_bo_pin(struct ttm_buffer_object + + BUG_ON(!atomic_read(&bo->reserved)); + BUG_ON(old_mem_type != TTM_PL_VRAM && +- old_mem_type != VMW_PL_FLAG_GMR); ++ old_mem_type != VMW_PL_GMR); + + pl_flags = TTM_PL_FLAG_VRAM | VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED; + if (pin) diff --git a/queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch b/queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch new file mode 100644 index 00000000000..158d9f662d9 --- /dev/null +++ b/queue-3.6/drm-vmwgfx-fix-hibernation-device-reset.patch @@ -0,0 +1,36 @@ +From 95e8f6a21996c4cc2c4574b231c6e858b749dce3 Mon Sep 17 00:00:00 2001 +From: Thomas Hellstrom +Date: Fri, 9 Nov 2012 10:05:57 +0100 +Subject: drm/vmwgfx: Fix hibernation device reset + +From: Thomas Hellstrom + +commit 95e8f6a21996c4cc2c4574b231c6e858b749dce3 upstream. + +The device would not reset properly when resuming from hibernation. + +Signed-off-by: Thomas Hellstrom +Reviewed-by: Brian Paul +Reviewed-by: Dmitry Torokhov +Cc: linux-graphics-maintainer@vmware.com +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +@@ -1099,6 +1099,11 @@ static void vmw_pm_complete(struct devic + struct drm_device *dev = pci_get_drvdata(pdev); + struct vmw_private *dev_priv = vmw_priv(dev); + ++ mutex_lock(&dev_priv->hw_mutex); ++ vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2); ++ (void) vmw_read(dev_priv, SVGA_REG_ID); ++ mutex_unlock(&dev_priv->hw_mutex); ++ + /** + * Reclaim 3d reference held by fbdev and potentially + * start fifo. diff --git a/queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch b/queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch new file mode 100644 index 00000000000..ff8d502a595 --- /dev/null +++ b/queue-3.6/futex-handle-futex_pi-owner_died-take-over-correctly.patch @@ -0,0 +1,225 @@ +From 59fa6245192159ab5e1e17b8e31f15afa9cff4bf Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 23 Oct 2012 22:29:38 +0200 +Subject: futex: Handle futex_pi OWNER_DIED take over correctly + +From: Thomas Gleixner + +commit 59fa6245192159ab5e1e17b8e31f15afa9cff4bf upstream. + +Siddhesh analyzed a failure in the take over of pi futexes in case the +owner died and provided a workaround. +See: http://sourceware.org/bugzilla/show_bug.cgi?id=14076 + +The detailed problem analysis shows: + +Futex F is initialized with PTHREAD_PRIO_INHERIT and +PTHREAD_MUTEX_ROBUST_NP attributes. + +T1 lock_futex_pi(F); + +T2 lock_futex_pi(F); + --> T2 blocks on the futex and creates pi_state which is associated + to T1. + +T1 exits + --> exit_robust_list() runs + --> Futex F userspace value TID field is set to 0 and + FUTEX_OWNER_DIED bit is set. + +T3 lock_futex_pi(F); + --> Succeeds due to the check for F's userspace TID field == 0 + --> Claims ownership of the futex and sets its own TID into the + userspace TID field of futex F + --> returns to user space + +T1 --> exit_pi_state_list() + --> Transfers pi_state to waiter T2 and wakes T2 via + rt_mutex_unlock(&pi_state->mutex) + +T2 --> acquires pi_state->mutex and gains real ownership of the + pi_state + --> Claims ownership of the futex and sets its own TID into the + userspace TID field of futex F + --> returns to user space + +T3 --> observes inconsistent state + +This problem is independent of UP/SMP, preemptible/non preemptible +kernels, or process shared vs. private. The only difference is that +certain configurations are more likely to expose it. + +So as Siddhesh correctly analyzed the following check in +futex_lock_pi_atomic() is the culprit: + + if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) { + +We check the userspace value for a TID value of 0 and take over the +futex unconditionally if that's true. + +AFAICT this check is there as it is correct for a different corner +case of futexes: the WAITERS bit became stale. + +Now the proposed change + +- if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) { ++ if (unlikely(ownerdied || ++ !(curval & (FUTEX_TID_MASK | FUTEX_WAITERS)))) { + +solves the problem, but it's not obvious why and it wreckages the +"stale WAITERS bit" case. + +What happens is, that due to the WAITERS bit being set (T2 is blocked +on that futex) it enforces T3 to go through lookup_pi_state(), which +in the above case returns an existing pi_state and therefor forces T3 +to legitimately fight with T2 over the ownership of the pi_state (via +pi_state->mutex). Probelm solved! + +Though that does not work for the "WAITERS bit is stale" problem +because if lookup_pi_state() does not find existing pi_state it +returns -ERSCH (due to TID == 0) which causes futex_lock_pi() to +return -ESRCH to user space because the OWNER_DIED bit is not set. + +Now there is a different solution to that problem. Do not look at the +user space value at all and enforce a lookup of possibly available +pi_state. If pi_state can be found, then the new incoming locker T3 +blocks on that pi_state and legitimately races with T2 to acquire the +rt_mutex and the pi_state and therefor the proper ownership of the +user space futex. + +lookup_pi_state() has the correct order of checks. It first tries to +find a pi_state associated with the user space futex and only if that +fails it checks for futex TID value = 0. If no pi_state is available +nothing can create new state at that point because this happens with +the hash bucket lock held. + +So the above scenario changes to: + +T1 lock_futex_pi(F); + +T2 lock_futex_pi(F); + --> T2 blocks on the futex and creates pi_state which is associated + to T1. + +T1 exits + --> exit_robust_list() runs + --> Futex F userspace value TID field is set to 0 and + FUTEX_OWNER_DIED bit is set. + +T3 lock_futex_pi(F); + --> Finds pi_state and blocks on pi_state->rt_mutex + +T1 --> exit_pi_state_list() + --> Transfers pi_state to waiter T2 and wakes it via + rt_mutex_unlock(&pi_state->mutex) + +T2 --> acquires pi_state->mutex and gains ownership of the pi_state + --> Claims ownership of the futex and sets its own TID into the + userspace TID field of futex F + --> returns to user space + +This covers all gazillion points on which T3 might come in between +T1's exit_robust_list() clearing the TID field and T2 fixing it up. It +also solves the "WAITERS bit stale" problem by forcing the take over. + +Another benefit of changing the code this way is that it makes it less +dependent on untrusted user space values and therefor minimizes the +possible wreckage which might be inflicted. + +As usual after staring for too long at the futex code my brain hurts +so much that I really want to ditch that whole optimization of +avoiding the syscall for the non contended case for PI futexes and rip +out the maze of corner case handling code. Unfortunately we can't as +user space relies on that existing behaviour, but at least thinking +about it helps me to preserve my mental sanity. Maybe we should +nevertheless :) + +Reported-and-tested-by: Siddhesh Poyarekar +Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1210232138540.2756@ionos +Acked-by: Darren Hart +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 41 ++++++++++++++++++++++------------------- + 1 file changed, 22 insertions(+), 19 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -716,7 +716,7 @@ static int futex_lock_pi_atomic(u32 __us + struct futex_pi_state **ps, + struct task_struct *task, int set_waiters) + { +- int lock_taken, ret, ownerdied = 0; ++ int lock_taken, ret, force_take = 0; + u32 uval, newval, curval, vpid = task_pid_vnr(task); + + retry: +@@ -755,17 +755,15 @@ retry: + newval = curval | FUTEX_WAITERS; + + /* +- * There are two cases, where a futex might have no owner (the +- * owner TID is 0): OWNER_DIED. We take over the futex in this +- * case. We also do an unconditional take over, when the owner +- * of the futex died. +- * +- * This is safe as we are protected by the hash bucket lock ! ++ * Should we force take the futex? See below. + */ +- if (unlikely(ownerdied || !(curval & FUTEX_TID_MASK))) { +- /* Keep the OWNER_DIED bit */ ++ if (unlikely(force_take)) { ++ /* ++ * Keep the OWNER_DIED and the WAITERS bit and set the ++ * new TID value. ++ */ + newval = (curval & ~FUTEX_TID_MASK) | vpid; +- ownerdied = 0; ++ force_take = 0; + lock_taken = 1; + } + +@@ -775,7 +773,7 @@ retry: + goto retry; + + /* +- * We took the lock due to owner died take over. ++ * We took the lock due to forced take over. + */ + if (unlikely(lock_taken)) + return 1; +@@ -790,20 +788,25 @@ retry: + switch (ret) { + case -ESRCH: + /* +- * No owner found for this futex. Check if the +- * OWNER_DIED bit is set to figure out whether +- * this is a robust futex or not. ++ * We failed to find an owner for this ++ * futex. So we have no pi_state to block ++ * on. This can happen in two cases: ++ * ++ * 1) The owner died ++ * 2) A stale FUTEX_WAITERS bit ++ * ++ * Re-read the futex value. + */ + if (get_futex_value_locked(&curval, uaddr)) + return -EFAULT; + + /* +- * We simply start over in case of a robust +- * futex. The code above will take the futex +- * and return happy. ++ * If the owner died or we have a stale ++ * WAITERS bit the owner TID in the user space ++ * futex is 0. + */ +- if (curval & FUTEX_OWNER_DIED) { +- ownerdied = 1; ++ if (!(curval & FUTEX_TID_MASK)) { ++ force_take = 1; + goto retry; + } + default: diff --git a/queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch b/queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch new file mode 100644 index 00000000000..5bd38099b53 --- /dev/null +++ b/queue-3.6/mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch @@ -0,0 +1,52 @@ +From 14efd957209461bbdf285bf0d67e931955d04a4c Mon Sep 17 00:00:00 2001 +From: Chris Ball +Date: Mon, 5 Nov 2012 14:29:49 -0500 +Subject: mmc: sdhci: fix NULL dereference in sdhci_request() tuning + +From: Chris Ball + +commit 14efd957209461bbdf285bf0d67e931955d04a4c upstream. + +Commit 473b095a72a9 ("mmc: sdhci: fix incorrect command used in tuning") +introduced a NULL dereference at resume-time if an SD 3.0 host controller +raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an +OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too. + +Signed-off-by: Chris Ball +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci.c | 21 ++++++++++++--------- + 1 file changed, 12 insertions(+), 9 deletions(-) + +--- a/drivers/mmc/host/sdhci.c ++++ b/drivers/mmc/host/sdhci.c +@@ -1307,16 +1307,19 @@ static void sdhci_request(struct mmc_hos + */ + if ((host->flags & SDHCI_NEEDS_RETUNING) && + !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) { +- /* eMMC uses cmd21 while sd and sdio use cmd19 */ +- tuning_opcode = mmc->card->type == MMC_TYPE_MMC ? +- MMC_SEND_TUNING_BLOCK_HS200 : +- MMC_SEND_TUNING_BLOCK; +- spin_unlock_irqrestore(&host->lock, flags); +- sdhci_execute_tuning(mmc, tuning_opcode); +- spin_lock_irqsave(&host->lock, flags); ++ if (mmc->card) { ++ /* eMMC uses cmd21 but sd and sdio use cmd19 */ ++ tuning_opcode = ++ mmc->card->type == MMC_TYPE_MMC ? ++ MMC_SEND_TUNING_BLOCK_HS200 : ++ MMC_SEND_TUNING_BLOCK; ++ spin_unlock_irqrestore(&host->lock, flags); ++ sdhci_execute_tuning(mmc, tuning_opcode); ++ spin_lock_irqsave(&host->lock, flags); + +- /* Restore original mmc_request structure */ +- host->mrq = mrq; ++ /* Restore original mmc_request structure */ ++ host->mrq = mrq; ++ } + } + + if (mrq->sbc && !(host->flags & SDHCI_AUTO_CMD23)) diff --git a/queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch b/queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch new file mode 100644 index 00000000000..91c58e08a41 --- /dev/null +++ b/queue-3.6/mmc-sh_mmcif-fix-use-after-free.patch @@ -0,0 +1,35 @@ +From a0d28ba01ebd048b4ba418142b37f5cf80e6d156 Mon Sep 17 00:00:00 2001 +From: Guennadi Liakhovetski +Date: Tue, 23 Oct 2012 14:08:52 +0200 +Subject: mmc: sh_mmcif: fix use after free + +From: Guennadi Liakhovetski + +commit a0d28ba01ebd048b4ba418142b37f5cf80e6d156 upstream. + +A recent commit "mmc: sh_mmcif: fix clock management" has introduced a +use after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to +mmc_free_host() frees private driver data, therefore using it afterwards +is a bug. Revert that hunk. + +Signed-off-by: Guennadi Liakhovetski +Signed-off-by: Chris Ball +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sh_mmcif.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mmc/host/sh_mmcif.c ++++ b/drivers/mmc/host/sh_mmcif.c +@@ -1464,9 +1464,9 @@ static int __devexit sh_mmcif_remove(str + + platform_set_drvdata(pdev, NULL); + ++ clk_disable(host->hclk); + mmc_free_host(host->mmc); + pm_runtime_put_sync(&pdev->dev); +- clk_disable(host->hclk); + pm_runtime_disable(&pdev->dev); + + return 0; diff --git a/queue-3.6/series b/queue-3.6/series index ffab1f80c45..d9d1fc5ea9f 100644 --- a/queue-3.6/series +++ b/queue-3.6/series @@ -55,3 +55,10 @@ tcp-repair-handle-zero-length-data-put-in-rcv-queue.patch net-inet_diag-return-error-code-if-protocol-handler-is-missed.patch af-packet-fix-oops-when-socket-is-not-present.patch ipv6-send-unsolicited-neighbour-advertisements-to-all-nodes.patch +futex-handle-futex_pi-owner_died-take-over-correctly.patch +mmc-sh_mmcif-fix-use-after-free.patch +mmc-sdhci-fix-null-dereference-in-sdhci_request-tuning.patch +drm-vmwgfx-fix-hibernation-device-reset.patch +drm-vmwgfx-fix-a-case-where-the-code-would-bug-when-trying-to-pin-gmr-memory.patch +drm-radeon-cayman-add-some-missing-regs-to-the-vm-reg-checker.patch +drm-radeon-si-add-some-missing-regs-to-the-vm-reg-checker.patch -- 2.47.3