From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423397AbdD0WPw (ORCPT ); Thu, 27 Apr 2017 18:15:52 -0400 Received: from smtp57.i.mail.ru ([217.69.128.37]:47542 "EHLO smtp57.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162441AbdD0WPo (ORCPT ); Thu, 27 Apr 2017 18:15:44 -0400 Subject: Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly() To: Andy Lutomirski , Nadav Amit Cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Borislav Petkov , Rik van Riel , Dave Hansen , Michal Hocko , Sasha Levin , Andrew Morton References: <791a644076fc3577ba7f7b7cafd643cc089baa7d.1492844372.git.luto@kernel.org> From: Stas Sergeev Message-ID: <51bacda4-058b-f5e4-8f40-acc2e6f44520@list.ru> Date: Fri, 28 Apr 2017 01:15:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-MW Authentication-Results: smtp57.i.mail.ru; auth=pass smtp.auth=stsp@list.ru smtp.mailfrom=stsp@list.ru X-7FA49CB5: 0D63561A33F958A5DFB663AC2FBE40748D96FD15C33242C72C2D97955E88E214725E5C173C3A84C3A1C30C8AFC676C8BBFFE994228F58FFF24B591B534DDBB47C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F41B67924A99884D73B503F486389A921A5CC5B56E945C8DA X-Mailru-Sender: F1845AB6CCC9920DF7838D61D4D05C42931049FEA7443532CA87489B69CD478A4B9E3DE306C0EA931653177920737CA72999BEE114A20FF4278B2D54D4112F244F0A872F021F905956A8FB0C6EBA5FCCEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: OK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 27.04.2017 19:08, Andy Lutomirski пишет: > Those should probably be pgd_none(), not pgd_none_or_clear_bad(). > > But this whole function is just garbage. It mucks with page > protections without even looking up the VMA. What happens if the > pages are file-backed? How about chardevs? > > I'd like to delete it. Stas, do you know if there's any code at all > that uses VM86_SCREEN_BITMAP? Some Googling didn't turn any up at > all. dosemu1 has this: https://sourceforge.net/p/dosemu/code/ci/master/tree/src/env/video/video.c Scroll down to line 255. --- #if VIDEO_CHECK_DIRTY if (!config_dualmon) { vm86s.flags |= VM86_SCREEN_BITMAP; } #endif --- The check expands to "if 0": https://sourceforge.net/p/dosemu/code/ci/master/tree/src/include/video.h line 27: --- #define VIDEO_CHECK_DIRTY 0 --- Plus, in video.c you can see the comment that basically says that this functionality was of no use (not sure what exactly they were saying though). dosemu2 has no traces of this code at all. So perfectly fine with me if you remove it. In fact, I've cleaned up dosemu2 from any fancy stuff of vm86(), so probably more cleanups are possible on kernel side. I even wanted to switch to vm86old() if not for the very nasty bug that vm86old() generates SIGTRAP when int3 is called in v86. If this is fixed (and its a 1-line fix), we can remove entire vm86(). :)