Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime
On Sat, 25 Nov 2017, Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 2:48 PM, Thomas Gleixner wrote: > > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner wrote: > >> > On Sat, 25 Nov 2017, Andy Lutomirski wrote: > >> >> Keep in mind that, for a static_branch, actually setting the thing needs > >> >> to be deferred, but that's straightforward. > >> > > >> > That's not an issue during boot. That would be an issue for a run time > >> > switch. > >> > >> What I mean is: if you modify a static_branch too early, it blows up > >> terribly. > > > > I'm aware of that. We can't switch it in the early boot stage. But that > > does not matter as we can switch way before we reach user space. > > > > The early kaiser mappings are fine whether we use them later or not. At the > > point in boot where we actually make the decision, there is nothing more > > than the extra 4k shadow which got initialized. > > > > If we ever want to do runtime switching, then the full shadow mapping needs > > to be maintained even while kaiser is disabled, just the NX poisoning of > > the user space mappings is what makes the difference. > > One unfortunate thing is that, if we boot with kaiser off and don't > intend to ever switch it on at runtime, we could avoid the 8k pgd > allocations. But if we want to be able to enable kaiser, we need the > 8k mappings. My inclination is to not try for runtime control until > some distro asks for it. I completely agree. boot time is good enough. We should start with the 8k allocations for simplicity reasons and when that works have a patch on top which switches is back to 4k. > In general, I think that trying to runtime switch without stop_machine > is a bit nuts, and getting it to be reliable even with stop_machine is > gross. Not to mention that stop_machine is currently incompatible > with writing to static branches, although that's fixable. Yes, it's doable, but surely not trivial and I'd like to avoid the mess it creates. Thanks, tglx
Re: [PATCH] input: pegasus_notetaker: add license information
On Sat, Nov 25, 2017 at 04:42:59PM -0800, Dmitry Torokhov wrote: > Hi Martin, > > On Sat, Nov 18, 2017 at 09:45:18AM +0100, Martin Kepplinger wrote: > > This adds an SPDX license identifier to this driver I wrote some time back. > > > > Signed-off-by: Martin Kepplinger > > --- > > drivers/input/tablet/pegasus_notetaker.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/input/tablet/pegasus_notetaker.c > > b/drivers/input/tablet/pegasus_notetaker.c > > index 47de5a81172f..cdf75c989469 100644 > > --- a/drivers/input/tablet/pegasus_notetaker.c > > +++ b/drivers/input/tablet/pegasus_notetaker.c > > @@ -1,3 +1,4 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Should this be GPL-2.0+? The MODULE_LICENSE specifies that the module is > "GPL" which in kernel land means GPLv2+. Or we should change the module > license to strict "GPLv2"? That is up to Martin, given that he is the author, as to what he wants to mark this as. Odd that it missed the big "fix up all files with no license information" sweep. Philippe, how did we miss this one? > Also, why do we use C++ -style comments for this? That is what Linus wants, see the thread on lkml in the past few hours for his reasoning here. > Greg, do you have any plans on dropping MODULE_LICENSE() altogether and > generating the appropriate string from SPDX markings in the source? At this time, no, it's not a simple solution as it gets messy quickly (multiple c files make up modulues, what about .h files, etc...) > Doing this would prevent mismatches between license notices, SPDX tags > and MODULE_LCENSE() strings, which happen very often. I agree, but now that we are getting SPDX tags, we can fix up all of the mismatches in MODULE_LICENSE() strings, of which there are a lot. thanks, greg k-h
Re: [PATCH v2 02/22] mmc: renesas_sdhi: remove wrong depends on to enable compile test
On Fri, Nov 24, 2017 at 5:24 PM, Masahiro Yamada
wrote:
> ARCH_RENESAS is a stronger condition than (ARM || ARM64).
> If ARCH_RENESAS is enabled, (ARM || ARM64) is met as well.
>
> What is worse, the first depends on line prevents COMPILE_TEST from
> enabling this driver. It should be removed.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S, U}20
Hi,
On Nov 24 2017 08:31, Maciej S. Szmigiero wrote:
This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
allow 3-byte accesses (including DMA) so a 4-byte (more conventional)
format is needed for it.
Signed-off-by: Maciej S. Szmigiero
---
Changes from v1: Drop "_4" suffix from these formats since they aren't
non-standard ones, use empty format slots starting from format number 25
for them, add information that they are LSB justified formats.
Corresponding alsa-lib changes will be posted as soon as this patch is
merged on the kernel side, to keep alsa-lib and kernel synchronized.
include/sound/pcm.h | 8
include/sound/soc-dai.h | 2 ++
include/uapi/sound/asound.h | 9 +
sound/core/pcm_misc.c | 16
4 files changed, 35 insertions(+)
...
diff --git a/sound/core/pcm_misc.c b/sound/core/pcm_misc.c
index 9be81025372f..c62bfe27106f 100644
--- a/sound/core/pcm_misc.c
+++ b/sound/core/pcm_misc.c
@@ -170,6 +170,22 @@ static struct pcm_format_data
pcm_formats[(INT)SNDRV_PCM_FORMAT_LAST+1] = {
[SNDRV_PCM_FORMAT_GSM] = {
.le = -1, .signd = -1,
},
+ [SNDRV_PCM_FORMAT_S20_LE] = {
+ .width = 20, .phys = 32, .le = 1, .signd = 1,
+ .silence = {},
+ },
+ [SNDRV_PCM_FORMAT_S20_BE] = {
+ .width = 20, .phys = 32, .le = 0, .signd = 1,
+ .silence = {},
+ },
+ [SNDRV_PCM_FORMAT_U20_LE] = {
+ .width = 20, .phys = 32, .le = 1, .signd = 0,
+ .silence = { 0x00, 0x00, 0x08, 0x00 },
+ },
+ [SNDRV_PCM_FORMAT_U20_BE] = {
+ .width = 20, .phys = 32, .le = 0, .signd = 0,
+ .silence = { 0x00, 0x08, 0x00, 0x00 },
+ },
[SNDRV_PCM_FORMAT_SPECIAL] = {
.le = -1, .signd = -1,
},
Before applying this patch:
166 /* FIXME: the following three formats are not defined
properly yet */
167 [SNDRV_PCM_FORMAT_MPEG] = {
168 .le = -1, .signd = -1,
169 },
170 [SNDRV_PCM_FORMAT_GSM] = {
171 .le = -1, .signd = -1,
172 },
173 [SNDRV_PCM_FORMAT_SPECIAL] = {
174 .le = -1, .signd = -1,
175 },
After applying this patch:
166 /* FIXME: the following three formats are not defined
properly yet */
167 [SNDRV_PCM_FORMAT_MPEG] = {
168 .le = -1, .signd = -1,
169 },
170 [SNDRV_PCM_FORMAT_GSM] = {
171 .le = -1, .signd = -1,
172 },
173 [SNDRV_PCM_FORMAT_S20_LE] = {
174 .width = 20, .phys = 32, .le = 1, .signd = 1,
175 .silence = {},
176 },
177 [SNDRV_PCM_FORMAT_S20_BE] = {
178 .width = 20, .phys = 32, .le = 0, .signd = 1,
179 .silence = {},
180 },
181 [SNDRV_PCM_FORMAT_U20_LE] = {
182 .width = 20, .phys = 32, .le = 1, .signd = 0,
183 .silence = { 0x00, 0x00, 0x08, 0x00 },
184 },
185 [SNDRV_PCM_FORMAT_U20_BE] = {
186 .width = 20, .phys = 32, .le = 0, .signd = 0,
187 .silence = { 0x00, 0x08, 0x00, 0x00 },
188 },
189 [SNDRV_PCM_FORMAT_SPECIAL] = {
190 .le = -1, .signd = -1,
191 },
I think it good to add an alternative comment for each of entry which is
not defined yet, like:
-> 166 /* FIXME: this format is not defined properly yet */
167 [SNDRV_PCM_FORMAT_MPEG] = {
168 .le = -1, .signd = -1,
169 },
-> 170 /* FIXME: this format is not defined properly yet */
171 [SNDRV_PCM_FORMAT_GSM] = {
172 .le = -1, .signd = -1,
173 },
174 [SNDRV_PCM_FORMAT_S20_LE] = {
175 .width = 20, .phys = 32, .le = 1, .signd = 1,
176 .silence = {},
177 },
178 [SNDRV_PCM_FORMAT_S20_BE] = {
179 .width = 20, .phys = 32, .le = 0, .signd = 1,
180 .silence = {},
181 },
182 [SNDRV_PCM_FORMAT_U20_LE] = {
183 .width = 20, .phys = 32, .le = 1, .signd = 0,
184 .silence = { 0x00, 0x00, 0x08, 0x00 },
185 },
186 [SNDRV_PCM_FORMAT_U20_BE] = {
187 .width = 20, .phys = 32, .le = 0, .signd = 0,
188 .silence = { 0x00, 0x08, 0x00, 0x00 },
189 },
-> 190 /* FIXME: this format is not defined properly yet */
191 [SNDRV_PCM_FORMAT_SPECIAL] = {
192 .le = -1, .signd = -1,
193 },
Regards
Takashi Sakamoto
Re: [PATCH] x86/orc: Don't bail on stack overflow
On Sat, 25 Nov 2017, Josh Poimboeuf wrote: > It looks a *lot* better with mine and your patches applied. It probably > would have helped Ingo and Thomas figure the problem out a lot sooner: > [1.159583] CS: 0010 DS: ES: CR0: 80050033 > [1.159583] CR2: ff083fb8 CR3: 000136f78002 CR4: > 001606e0 > [1.159583] Call Trace: > [1.159583] > [1.159583] __do_page_fault+0x4b0/0x4b0 > [1.159583] page_fault+0x2c/0x60 > [1.159583] RIP: 0010:do_page_fault+0x0/0x100 > [1.159583] RSP: :ff084120 EFLAGS: 00010012 > [1.159583] RAX: 819d0a87 RBX: 0001 RCX: > 819d0a87 > [1.159583] RDX: 1000 RSI: 0010 RDI: > ff084128 > [1.159583] RBP: 0d68 R08: 7f6d6bb24278 R09: > 0023 > [1.159583] R10: 558e0feca600 R11: 0246 R12: > 7f6d6bb203c0 > [1.159583] R13: 7f6d6bb1f880 R14: 7793bebc R15: > 0100 > [1.159583] ? native_iret+0x7/0x7 > [1.159583] page_fault+0x2c/0x60 > [1.159583] RIP: 0010:apic_timer_interrupt+0x0/0xb0 Yes. That would have pointed immediately to the right place. It'd been obvious that apic_timer_interrupt is not mapped. Thanks, tglx
[PATCH 0/4] video: sm501fb: Adjustments for seven function implementations
From: Markus Elfring Date: Sun, 26 Nov 2017 11:10:01 +0100 A few update suggestions were taken into account from static source code analysis. Markus Elfring (4): Delete error messages for a failed memory allocation in two functions Improve a size determination in sm501fb_probe() Combine substrings for four messages Adjust 15 checks for null pointers drivers/video/fbdev/sm501fb.c | 66 ++- 1 file changed, 28 insertions(+), 38 deletions(-) -- 2.15.0
[PATCH 1/4] video: sm501fb: Delete error messages for a failed memory allocation in two functions
From: Markus Elfring
Date: Sun, 26 Nov 2017 10:10:31 +0100
Omit extra messages for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/sm501fb.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 6f0a19501c6a..e8301c4e7d44 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1934,10 +1934,8 @@ static int sm501fb_probe(struct platform_device *pdev)
/* allocate our framebuffers */
info = kzalloc(sizeof(struct sm501fb_info), GFP_KERNEL);
- if (!info) {
- dev_err(dev, "failed to allocate state\n");
+ if (!info)
return -ENOMEM;
- }
info->dev = dev = &pdev->dev;
platform_set_drvdata(pdev, info);
@@ -2121,16 +2119,12 @@ static int sm501fb_suspend_fb(struct sm501fb_info *info,
/* backup copies in case chip is powered down over suspend */
par->store_fb = vmalloc(par->screen.size);
- if (par->store_fb == NULL) {
- dev_err(info->dev, "no memory to store screen\n");
+ if (!par->store_fb)
return -ENOMEM;
- }
par->store_cursor = vmalloc(par->cursor.size);
- if (par->store_cursor == NULL) {
- dev_err(info->dev, "no memory to store cursor\n");
+ if (!par->store_cursor)
goto err_nocursor;
- }
dev_dbg(info->dev, "suspending screen to %p\n", par->store_fb);
dev_dbg(info->dev, "suspending cursor to %p\n", par->store_cursor);
--
2.15.0
[PATCH 2/4] video: sm501fb: Improve a size determination in sm501fb_probe()
From: Markus Elfring Date: Sun, 26 Nov 2017 10:22:37 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/sm501fb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c index e8301c4e7d44..80bda5a655c0 100644 --- a/drivers/video/fbdev/sm501fb.c +++ b/drivers/video/fbdev/sm501fb.c @@ -1932,8 +1932,7 @@ static int sm501fb_probe(struct platform_device *pdev) int ret; /* allocate our framebuffers */ - - info = kzalloc(sizeof(struct sm501fb_info), GFP_KERNEL); + info = kzalloc(sizeof(*info), GFP_KERNEL); if (!info) return -ENOMEM; -- 2.15.0
[PATCH 3/4] video: sm501fb: Combine substrings for four messages
From: Markus Elfring
Date: Sun, 26 Nov 2017 10:43:36 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: quoted string split across lines
Thus fix four source code places.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/sm501fb.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 80bda5a655c0..f38e3773ccc0 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -510,10 +510,10 @@ static int sm501fb_set_par_common(struct fb_info *info,
/* update fb layer with actual clock used */
var->pixclock = sm501fb_hz_to_ps(sm501pixclock);
- dev_dbg(fbi->dev, "%s: pixclock(ps) = %u, pixclock(Hz) = %lu, "
- "sm501pixclock = %lu, error = %ld%%\n",
- __func__, var->pixclock, pixclock, sm501pixclock,
- ((pixclock - sm501pixclock)*100)/pixclock);
+ dev_dbg(fbi->dev,
+ "%s: pixclock(ps) = %u, pixclock(Hz) = %lu, sm501pixclock =
%lu, error = %ld%%\n",
+ __func__, var->pixclock, pixclock, sm501pixclock,
+ ((pixclock - sm501pixclock) * 100) / pixclock);
return 0;
}
@@ -1789,16 +1789,16 @@ static int sm501fb_init_fb(struct fb_info *fb, enum
sm501_controller head,
switch (ret) {
case 1:
- dev_info(info->dev, "using mode specified in "
- "@mode\n");
+ dev_info(info->dev,
+"using mode specified in @mode\n");
break;
case 2:
- dev_info(info->dev, "using mode specified in "
- "@mode with ignored refresh rate\n");
+ dev_info(info->dev,
+"using mode specified in @mode with
ignored refresh rate\n");
break;
case 3:
- dev_info(info->dev, "using mode default "
- "mode\n");
+ dev_info(info->dev,
+"using mode default mode\n");
break;
case 4:
dev_info(info->dev, "using mode from list\n");
--
2.15.0
[PATCH 4/4] video: sm501fb: Adjust 15 checks for null pointers
From: Markus Elfring
Date: Sun, 26 Nov 2017 10:56:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written !…
Thus fix the affected source code places.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/sm501fb.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index f38e3773ccc0..313acc83bb71 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1484,7 +1484,7 @@ static int sm501_init_cursor(struct fb_info *fbi,
unsigned int reg_base)
struct sm501fb_info *info;
int ret;
- if (fbi == NULL)
+ if (!fbi)
return 0;
par = fbi->par;
@@ -1532,7 +1532,7 @@ static int sm501fb_start(struct sm501fb_info *info,
/* allocate, reserve and remap resources for display
* controller registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
+ if (!res) {
dev_err(dev, "no resource definition for registers\n");
ret = -ENOENT;
goto err_release;
@@ -1541,15 +1541,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->regs_res = request_mem_region(res->start,
resource_size(res),
pdev->name);
-
- if (info->regs_res == NULL) {
+ if (!info->regs_res) {
dev_err(dev, "cannot claim registers\n");
ret = -ENXIO;
goto err_release;
}
info->regs = ioremap(res->start, resource_size(res));
- if (info->regs == NULL) {
+ if (!info->regs) {
dev_err(dev, "cannot remap registers\n");
ret = -ENXIO;
goto err_regs_res;
@@ -1558,7 +1557,7 @@ static int sm501fb_start(struct sm501fb_info *info,
/* allocate, reserve and remap resources for 2d
* controller registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (res == NULL) {
+ if (!res) {
dev_err(dev, "no resource definition for 2d registers\n");
ret = -ENOENT;
goto err_regs_map;
@@ -1567,15 +1566,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->regs2d_res = request_mem_region(res->start,
resource_size(res),
pdev->name);
-
- if (info->regs2d_res == NULL) {
+ if (!info->regs2d_res) {
dev_err(dev, "cannot claim registers\n");
ret = -ENXIO;
goto err_regs_map;
}
info->regs2d = ioremap(res->start, resource_size(res));
- if (info->regs2d == NULL) {
+ if (!info->regs2d) {
dev_err(dev, "cannot remap registers\n");
ret = -ENXIO;
goto err_regs2d_res;
@@ -1583,7 +1581,7 @@ static int sm501fb_start(struct sm501fb_info *info,
/* allocate, reserve resources for framebuffer */
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- if (res == NULL) {
+ if (!res) {
dev_err(dev, "no memory resource defined\n");
ret = -ENXIO;
goto err_regs2d_map;
@@ -1592,14 +1590,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->fbmem_res = request_mem_region(res->start,
resource_size(res),
pdev->name);
- if (info->fbmem_res == NULL) {
+ if (!info->fbmem_res) {
dev_err(dev, "cannot claim framebuffer\n");
ret = -ENXIO;
goto err_regs2d_map;
}
info->fbmem = ioremap(res->start, resource_size(res));
- if (info->fbmem == NULL) {
+ if (!info->fbmem) {
dev_err(dev, "cannot remap framebuffer\n");
ret = -ENXIO;
goto err_mem_res;
@@ -1862,13 +1860,13 @@ static int sm501fb_probe_one(struct sm501fb_info *info,
pd = (head == HEAD_CRT) ? info->pdata->fb_crt : info->pdata->fb_pnl;
/* Do not initialise if we've not been given any platform data */
- if (pd == NULL) {
+ if (!pd) {
dev_info(info->dev, "no data for fb %s (disabled)\n", name);
return 0;
}
fbi = framebuffer_alloc(sizeof(struct sm501fb_par), info->dev);
- if (fbi == NULL) {
+ if (!fbi) {
dev_err(info->dev, "cannot allocate %s framebuffer\n", name);
return -ENOMEM;
}
@@ -1944,7 +1942,7 @@ static int sm501fb_probe(struct platform_device *pdev)
info->pdata = pd->fb;
}
-
Re: [PATCH v6 01/11] intel_sgx: updated MAINTAINERS
Joe Perches writes: > On Sat, 2017-11-25 at 21:29 +0200, Jarkko Sakkinen wrote: >> diff --git a/MAINTAINERS b/MAINTAINERS > [] >> @@ -14932,6 +14932,11 @@ L: linux...@kvack.org >> S: Maintained >> F: mm/zswap.c >> >> +INTEL SGX >> +M: Jarkko Sakkinen >> +L: intel-sgx-kernel-...@lists.01.org >> +Q: https://patchwork.kernel.org/project/intel-sgx/list/ > > Alphabetical order please and this should > have at least an "F:" pattern like: > > F:drivers/platform/x86/intel_sgx/ FYI: Darren already requested that when reviewing v5: https://www.spinics.net/lists/kernel/msg2651743.html Bjørn
Re: Sparse warnings from sched.h
On Sat, Nov 25, 2017 at 09:46:11PM -0800, Jakub Kicinski wrote: > Hi! > > Did these: > > ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:479:62: error: dubious one-bit signed bitfield > > got fixed? I saw there were patches posted, but nothing have reached > Linus's tree, yet. I got an email from tipbot indicating that Ingo merged it to sched/urgent. Commit-ID: aa5222e92f8000ed3c1c38dddf11c83222aadfb3 Gitweb: https://git.kernel.org/tip/aa5222e92f8000ed3c1c38dddf11c83222aadfb3 Author: Dan Carpenter AuthorDate: Fri, 13 Oct 2017 10:01:22 +0300 Committer: Ingo Molnar CommitDate: Tue, 21 Nov 2017 09:25:01 +0100
Re: Sparse warnings from sched.h
On Sat, 25 Nov 2017 21:46:11 -0800 Jakub Kicinski wrote: > Hi! > > Did these: > > ./include/linux/sched.h:476:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:477:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:478:62: error: dubious one-bit signed bitfield > ./include/linux/sched.h:479:62: error: dubious one-bit signed bitfield > > got fixed? I saw there were patches posted, but nothing have reached > Linus's tree, yet. I think a fix is in the tip tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=aa5222e92f8000ed3c1c38dddf11c83222aadfb3 Luca
Re: About GPL license compliance of Tesla Model S, Linux kernel 4.4
Here is my next activity. After reading http://gpl-violations.org/helping/, I have reported this issue to solve a potential GPL misuse about the Linux kernel open source code that is used to deploy Tesla Model S (Linux kernel based commercial product). BRs, Geunsik Lim. On Sat, Nov 25, 2017 at 4:48 PM, Geunsik Lim wrote: > Hi All, > > I want to talk about a potential GPL misuse of the Linux open source > that is used by Tesla Model S. Some months ago, I have read that a > version information of Linux kernel that is deployed into the > commercial self-driving car such as Tesla Model S via (1) the twitter > web page of Tesla CEO Elon Musk and (2) the presentation material of > the Blackhat 2017 presenter Sen Nie as follows. > > Oct-05-2016, Twitter, "When we upgrade the core Linux OS to 4.4, which > is probably December" > https://twitter.com/elonmusk/status/783759011724210176 > > Jul-22-2017, Blackhat 2017, "FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN > BUS" > https://www.blackhat.com/us-17/briefings.html#free-fall-hacking-tesla-from-wireless-to-can-bus > > > In case of the embedded device vendors, it seems that the most of the > global vendors have being uploaded related open source software that > are used by commercial products via their open source release center > to keep the GPL compliance as following: > > https://opensource.google.com/ > https://opensource.microsoft.com/ > https://opensource.apple.com > https://opensource.samsung.com > https://opensource.lge.com > https://opensource.dell.com/ > http://opensource.alibaba.com/ > https://developer.sonymobile.com/knowledge-base/open-source/ > http://consumer.huawei.com/en/opensource/ > http://xiaomi.github.io/ > https://software.intel.com/en-us/open-source > > > Also, we can download related open sources such as Linux kernel, GCC, > and so on from their official homepage in case of BMW, GM, Ford, and > Toyota cars. > > BMW - http://www.bmw-carit.de/open-source/ > GM - http://oss.bosch-cm.com/gm.html > Ford - http://corporate.ford.com/ford-open-source.html > Toyota - http://www.globaldenso.com/en/opensource/ivi/toyota/ > > > BTW, in case of Tesla, where can we find an official open source > release center to download their Linux kernel source that is deployed > into a commercial self-driving car? I could not find an official web > page of Tesla to download Linux Kernel 4.4 (GPLv2) and other open > sources that are used by Tesla company. And, I can not find the > related Linux kernel source code from https://github.com/teslamotors. > Unfortunately, even though I asked a person in charging on this issue, > they do not reply me any e-mail for 2 weeks. Anyone that already tried > to get their Linux kernel source of Tesla Model S? > > As we all know, Linus Torvalds has released his Linux Kernel under > GPLv2 license via https://www.kernel.org/. > For more details, please visit the below web-pages. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.4 > http://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic > > I wonder if they correctly keep the GPL compliance because I am not a lawyer. > > > Thanks for reading. > > > > BRs, > Geunsik Lim. > > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Best regards, Geunsik Lim, Samsung Electronics http://leemgs.fedorapeople.org To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: pegasus_notetaker: add license information
Greg, Martin:
On Sun, Nov 26, 2017 at 9:59 AM, Greg Kroah-Hartman
wrote:
> On Sat, Nov 25, 2017 at 04:42:59PM -0800, Dmitry Torokhov wrote:
>> Hi Martin,
>>
>> On Sat, Nov 18, 2017 at 09:45:18AM +0100, Martin Kepplinger wrote:
>> > This adds an SPDX license identifier to this driver I wrote some time back.
>> >
>> > Signed-off-by: Martin Kepplinger
>> > ---
>> > drivers/input/tablet/pegasus_notetaker.c | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/drivers/input/tablet/pegasus_notetaker.c
>> > b/drivers/input/tablet/pegasus_notetaker.c
>> > index 47de5a81172f..cdf75c989469 100644
>> > --- a/drivers/input/tablet/pegasus_notetaker.c
>> > +++ b/drivers/input/tablet/pegasus_notetaker.c
>> > @@ -1,3 +1,4 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>>
>> Should this be GPL-2.0+? The MODULE_LICENSE specifies that the module is
>> "GPL" which in kernel land means GPLv2+. Or we should change the module
>> license to strict "GPLv2"?
>
> That is up to Martin, given that he is the author, as to what he wants
> to mark this as. Odd that it missed the big "fix up all files with no
> license information" sweep.
>
> Philippe, how did we miss this one?
It was not missed but instead was set aside by design.
drivers/input/tablet/pegasus_notetaker.c does not have (or rather did
not have until now) any licensing information beside a
MODULE_LICENSE("GPL") and these were left aside as requiring some
extra review and the eventual need of a clarification by the author,
just as Martin is rightfully doing so just now.
>> Doing this would prevent mismatches between license notices, SPDX tags
>> and MODULE_LCENSE() strings, which happen very often.
>
> I agree, but now that we are getting SPDX tags, we can fix up all of the
> mismatches in MODULE_LICENSE() strings, of which there are a lot.
I said that I would take a stab at it... but I did not attack this yet:
Let me get over the ThanksGiving hangover and provide a list this
week. I guess there could be three lists in fact:
- modules with only a MODULE_LICENSE and no other license info: these
could be candidates for adding an SPDX id matching the MODULE_LICENSE
- modules updated to use an SPDX id and with a conflicting
MODULE_LICENSE: the MODULE_LICENSE should be aligned to match the SPDX
id
- modules not yet updated to use an SPDX id and with a license notice
conflicting with the MODULE_LICENSE: the MODULE_LICENSE should be
aligned to match the licensing
I'll run a scancode-toolkit scan on the tip of Linus' tree and create
a CSV from that to surface these oddities.
Unless you prefer me to use another tree like on the USB side for a start.
--
Cordially
Philippe Ombredanne, the wild licenses tamer
Re: [PATCH v3 2/2] Protected O_CREAT open in sticky directories
2017-11-24 12:53 GMT+01:00 David Laight :
> From: Salvatore Mesoraca [mailto:s.mesorac...@gmail.com]
>> Sent: 24 November 2017 11:44
>>
>> 2017-11-24 11:53 GMT+01:00 David Laight :
>> > From: Alan Cox
>> >> Sent: 22 November 2017 16:52
>> >>
>> >> On Wed, 22 Nov 2017 09:01:46 +0100
>> >> Salvatore Mesoraca wrote:
>> >>
>> >> > Disallows O_CREAT open missing the O_EXCL flag, in world or
>> >> > group writable directories, even if the file doesn't exist yet.
>> >> > With few exceptions (e.g. shared lock files based on flock())
>> >>
>> >> Enough exceptions to make it a bad idea.
>> >>
>> >> Firstly if you care this much *stop* having shared writable directories.
>> >> We have namespaces, you don't need them. You can give every user their
>> >> own /tmp etc.
>> >
>> > Looks like a very bad idea to me as well.
>> >
>> > Doesn't this stop all shell redirects into a shared /tmp ?
>> > I'm pretty sure most programs use O_CREAT | O_TRUNC for output
>> > files - they'll all stop working.
>>
>> If some program does such a thing, that's a potential vulnerability.
>> With "protected_hardlinks" you are, in most cases, safe.
>> But, still, that program has a bug and having this feature enabled will
>> help you notice it soon.
>> For that matter, I'm using this patch on my system and I don't have any
>> program behaving like this.
>
> Hmmm a quick strace shows cp and vi doing stat("/tmp/foo") and then
> open(O_WRONLY|O_TRUNC) if it exists and O_CREATE|O_EXCL if it doesn't.
> I can't help feeling that is just hiding a race.
Yes, unfortunately, doing something like "cp somefile /tmp/" is a bad
practice that
in most cases will go unnoticed by this feature. Nevertheless there
are many other
real world vulnerability that it would have been able to detect.
Thank you very much for taking the time to do some experiments.
Salvatore
Re: [PATCH 22/43] x86/mm/kaiser: Prepare assembly for entry/exit CR3 switching
On Fri, Nov 24, 2017 at 06:23:50PM +0100, Ingo Molnar wrote: > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index 3fd8bc560fae..e1650da01323 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -1,6 +1,7 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > #include > #include > +#include > > /* > > @@ -187,6 +188,70 @@ For 32-bit we have the following conventions - kernel is > built with > #endif > .endm > > +#ifdef CONFIG_KAISER > + > +/* KAISER PGDs are 8k. Flip bit 12 to switch between the two halves: */ > +#define KAISER_SWITCH_MASK (1< +.macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req > + movq%cr3, %r\scratch_reg > + movq%r\scratch_reg, \save_reg What happened to making it uniform so that that macro can be invoked like this: SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax ... instead of "splitting" the arg? IOW, hunk below builds here, and asm looks correct: 14bf: 31 db xor%ebx,%ebx 14c1: 0f 20 d8mov%cr3,%rax 14c4: 49 89 c6mov%rax,%r14 14c7: 48 a9 00 10 00 00 test $0x1000,%rax 14cd: 74 09 je 14d8 14cf: 48 25 ff ef ff ff and$0xefff,%rax 14d5: 0f 22 d8mov%rax,%cr3 --- diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index e1650da01323..d528f7060774 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -188,10 +188,12 @@ For 32-bit we have the following conventions - kernel is built with #endif .endm +#define CONFIG_KAISER + #ifdef CONFIG_KAISER /* KAISER PGDs are 8k. Flip bit 12 to switch between the two halves: */ -#define KAISER_SWITCH_MASK (1< diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index 34e3110b0876..4ac952080869 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -168,6 +168,9 @@ ENTRY(entry_SYSCALL_64_trampoline) > /* Stash the user RSP. */ > movq%rsp, RSP_SCRATCH > > + /* Note: using %rsp as a scratch reg. */ Haha, yap, it just got freed :) > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp > + > /* Load the top of the task stack into RSP */ > movqCPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp > > @@ -198,6 +201,13 @@ ENTRY(entry_SYSCALL_64) > > swapgs > movq%rsp, PER_CPU_VAR(rsp_scratch) < newline here. > + /* > + * The kernel CR3 is needed to map the process stack, but we > + * need a scratch register to be able to load CR3. %rsp is > + * clobberable right now, so use it as a scratch register. > + * %rsp will be look crazy here for a couple instructions. s/be // or "will be looking crazy" :-) > + */ > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp Now, this is questionable: we did enter through the trampoline entry_SYSCALL_64_trampoline so theoretically, we wouldn't need to switch to CR3 here again because, well, we did already. I.e., entry_SYSCALL_64 is not going to be called anymore. Unless we will jump to it when we decide to jump over the trampolines in the kaiser disabled case. Just pointing it out here so that we don't forget to deal with this... > @@ -1239,7 +1254,11 @@ ENTRY(paranoid_entry) > js 1f /* negative -> in kernel */ > SWAPGS > xorl%ebx, %ebx > -1: ret > + > +1: > + SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=ax save_reg=%r14 > + > + ret > END(paranoid_entry) > > /* > @@ -1261,6 +1280,7 @@ ENTRY(paranoid_exit) > testl %ebx, %ebx /* swapgs needed? */ > jnz .Lparanoid_exit_no_swapgs > TRACE_IRQS_IRETQ > + RESTORE_CR3 %r14 RESTORE_CR3 save_reg=%r14 like the other invocation below. But if the runtime disable gets changed to a boottime one, you don't need that macro anymore. > SWAPGS_UNSAFE_STACK > jmp .Lparanoid_exit_restore > .Lparanoid_exit_no_swapgs: -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v6 14/17] ASoC: madera: Add common support for Cirrus Logic Madera codecs
Hi Richard, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to ljones-mfd/for-mfd-next asoc/for-next v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20171126-145824 config: arm64-allmodconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): drivers/mfd/madera-i2c.o: In function `madera_i2c_probe': >> madera-i2c.c:(.text+0x208): undefined reference to `__devm_regmap_init_i2c' madera-i2c.c:(.text+0x24c): undefined reference to `__devm_regmap_init_i2c' drivers/mfd/madera-i2c.o: In function `madera_i2c_driver_init': >> madera-i2c.c:(.init.text+0x20): undefined reference to `i2c_register_driver' drivers/mfd/madera-i2c.o: In function `madera_i2c_driver_exit': >> madera-i2c.c:(.exit.text+0x14): undefined reference to `i2c_del_driver' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe()
From: Markus Elfring
Date: Sun, 26 Nov 2017 13:08:43 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/sh_mobile_meram.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_meram.c
b/drivers/video/fbdev/sh_mobile_meram.c
index baadfb207b2e..b5a6735aeb87 100644
--- a/drivers/video/fbdev/sh_mobile_meram.c
+++ b/drivers/video/fbdev/sh_mobile_meram.c
@@ -644,10 +644,8 @@ static int sh_mobile_meram_probe(struct platform_device
*pdev)
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(&pdev->dev, "cannot allocate device data\n");
+ if (!priv)
return -ENOMEM;
- }
/* Initialize private data. */
mutex_init(&priv->lock);
--
2.15.0
[PATCH] arm: l2c: unlock ways when in non-secure mode
To boot Linux in Non-secure mode with l2x0, the l2x0 controller
is enabled in secure mode and ways locked to make it seems L2 cache
disabled during linux boot process. So during l2x0 initialization,
need to unlock the ways to make l2x0 could cache data/inst.
Signed-off-by: Peng Fan
Cc: Russell King
Cc: Mark Rutland
Cc: Thomas Gleixner
Cc: Chris Brandt
Cc: Will Deacon
---
arch/arm/mm/cache-l2x0.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..de8eed0871ec 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -879,6 +879,10 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
l2x0_saved_regs.aux_ctrl = aux;
data->enable(l2x0_base, data->num_lock);
+ } else {
+ pr_info("%s: unlock cache controller\n", data->type);
+
+ data->unlock(l2x0_base, data->num_lock);
}
outer_cache = fns;
--
2.14.1
[GIT PULL] objtool fixes
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: a356d2ae50790f49858ebed35da9e206336fafee tools/headers: Sync objtool
UAPI header
A handful of objtool fixes, most of them related to making the UAPI
header-syncing
warnings easier to read and easier to act upon.
Thanks,
Ingo
-->
Ingo Molnar (1):
tools/headers: Sync objtool UAPI header
Josh Poimboeuf (5):
objtool: Add a comment for the unreachable annotation macros
objtool: Make unreachable annotation inline asms explicitly volatile
objtool: Move synced files to their original relative locations
objtool: Move kernel headers/code sync check to a script
objtool: Fix cross-build
include/linux/compiler.h | 21 ++--
tools/objtool/.gitignore | 2 +-
tools/objtool/Makefile | 22
tools/objtool/arch/x86/Build | 10
tools/objtool/arch/x86/decode.c| 6 ++---
.../objtool/arch/x86/{insn => include/asm}/inat.h | 12 -
.../arch/x86/{insn => include/asm}/inat_types.h| 0
.../objtool/arch/x86/{insn => include/asm}/insn.h | 2 +-
.../objtool/{ => arch/x86/include/asm}/orc_types.h | 0
tools/objtool/arch/x86/{insn => lib}/inat.c| 2 +-
tools/objtool/arch/x86/{insn => lib}/insn.c| 4 +--
.../arch/x86/{insn => lib}/x86-opcode-map.txt | 0
.../arch/x86/{insn => tools}/gen-insn-attr-x86.awk | 0
tools/objtool/orc.h| 2 +-
tools/objtool/sync-check.sh| 29 ++
15 files changed, 72 insertions(+), 40 deletions(-)
rename tools/objtool/arch/x86/{insn => include/asm}/inat.h (95%)
rename tools/objtool/arch/x86/{insn => include/asm}/inat_types.h (100%)
rename tools/objtool/arch/x86/{insn => include/asm}/insn.h (99%)
rename tools/objtool/{ => arch/x86/include/asm}/orc_types.h (100%)
rename tools/objtool/arch/x86/{insn => lib}/inat.c (99%)
rename tools/objtool/arch/x86/{insn => lib}/insn.c (99%)
rename tools/objtool/arch/x86/{insn => lib}/x86-opcode-map.txt (100%)
rename tools/objtool/arch/x86/{insn => tools}/gen-insn-attr-x86.awk (100%)
create mode 100755 tools/objtool/sync-check.sh
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 3672353a0acd..188ed9f65517 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -88,17 +88,22 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
/* Unreachable code */
#ifdef CONFIG_STACK_VALIDATION
+/*
+ * These macros help objtool understand GCC code flow for unreachable code.
+ * The __COUNTER__ based labels are a hack to make each instance of the macros
+ * unique, to convince GCC not to merge duplicate inline asm statements.
+ */
#define annotate_reachable() ({
\
- asm("%c0:\n\t" \
- ".pushsection .discard.reachable\n\t" \
- ".long %c0b - .\n\t"\
- ".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("%c0:\n\t" \
+".pushsection .discard.reachable\n\t" \
+".long %c0b - .\n\t" \
+".popsection\n\t" : : "i" (__COUNTER__)); \
})
#define annotate_unreachable() ({ \
- asm("%c0:\n\t" \
- ".pushsection .discard.unreachable\n\t" \
- ".long %c0b - .\n\t"\
- ".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("%c0:\n\t" \
+".pushsection .discard.unreachable\n\t"\
+".long %c0b - .\n\t" \
+".popsection\n\t" : : "i" (__COUNTER__)); \
})
#define ASM_UNREACHABLE
\
"999:\n\t" \
diff --git a/tools/objtool/.gitignore b/tools/objtool/.gitignore
index d3102c865a95..914cff12899b 100644
--- a/tools/objtool/.gitignore
+++ b/tools/objtool/.gitignore
@@ -1,3 +1,3 @@
-arch/x86/insn/inat-tables.c
+arch/x86/lib/inat-tables.c
objtool
fixdep
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 424b1965d06f..0f94af3ccaaa 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -25,7 +25,9 @@ OBJTOOL_IN := $(OBJTOOL)-in.o
all: $(OBJTOOL)
-INCLUDES := -I$(srctree)/tools/include
-I$(src
[GIT PULL] static keys fix
Linus, Please pull the latest locking-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking-urgent-for-linus # HEAD: 92ee46efeb505ead3ab06d3c5ce695637ed5f152 jump_label: Invoke jump_label_test() via early_initcall() Fix a boot warning related to bad init ordering of the static keys self-test. Thanks, Ingo --> Jason Baron (1): jump_label: Invoke jump_label_test() via early_initcall() kernel/jump_label.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/jump_label.c b/kernel/jump_label.c index 8ff4ca4665ff..8594d24e4adc 100644 --- a/kernel/jump_label.c +++ b/kernel/jump_label.c @@ -769,7 +769,7 @@ static __init int jump_label_test(void) return 0; } -late_initcall(jump_label_test); +early_initcall(jump_label_test); #endif /* STATIC_KEYS_SELFTEST */ #endif /* HAVE_JUMP_LABEL */
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 4a31b424ac0656d1bb17520ee861144fe7a19664 perf/core: Fix memory leak
triggered by perf --namespace
Misc fixes: two PMU driver fixes and a memory leak fix.
Thanks,
Ingo
-->
Andi Kleen (1):
perf/x86/intel: Hide TSX events when RTM is not supported
Kan Liang (1):
perf/x86/intel/uncore: Add event constraint for BDX PCU
Vasily Averin (1):
perf/core: Fix memory leak triggered by perf --namespace
arch/x86/events/intel/core.c | 35 +++
arch/x86/events/intel/uncore_snbep.c | 8
kernel/events/core.c | 1 +
3 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 9fb9a1f1e47b..f94855000d4e 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3730,6 +3730,19 @@ EVENT_ATTR_STR(cycles-t, cycles_t,
"event=0x3c,in_tx=1");
EVENT_ATTR_STR(cycles-ct, cycles_ct,
"event=0x3c,in_tx=1,in_tx_cp=1");
static struct attribute *hsw_events_attrs[] = {
+ EVENT_PTR(mem_ld_hsw),
+ EVENT_PTR(mem_st_hsw),
+ EVENT_PTR(td_slots_issued),
+ EVENT_PTR(td_slots_retired),
+ EVENT_PTR(td_fetch_bubbles),
+ EVENT_PTR(td_total_slots),
+ EVENT_PTR(td_total_slots_scale),
+ EVENT_PTR(td_recovery_bubbles),
+ EVENT_PTR(td_recovery_bubbles_scale),
+ NULL
+};
+
+static struct attribute *hsw_tsx_events_attrs[] = {
EVENT_PTR(tx_start),
EVENT_PTR(tx_commit),
EVENT_PTR(tx_abort),
@@ -3742,18 +3755,16 @@ static struct attribute *hsw_events_attrs[] = {
EVENT_PTR(el_conflict),
EVENT_PTR(cycles_t),
EVENT_PTR(cycles_ct),
- EVENT_PTR(mem_ld_hsw),
- EVENT_PTR(mem_st_hsw),
- EVENT_PTR(td_slots_issued),
- EVENT_PTR(td_slots_retired),
- EVENT_PTR(td_fetch_bubbles),
- EVENT_PTR(td_total_slots),
- EVENT_PTR(td_total_slots_scale),
- EVENT_PTR(td_recovery_bubbles),
- EVENT_PTR(td_recovery_bubbles_scale),
NULL
};
+static __init struct attribute **get_hsw_events_attrs(void)
+{
+ return boot_cpu_has(X86_FEATURE_RTM) ?
+ merge_attr(hsw_events_attrs, hsw_tsx_events_attrs) :
+ hsw_events_attrs;
+}
+
static ssize_t freeze_on_smi_show(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -4182,7 +4193,7 @@ __init int intel_pmu_init(void)
x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
- x86_pmu.cpu_events = hsw_events_attrs;
+ x86_pmu.cpu_events = get_hsw_events_attrs();
x86_pmu.lbr_double_abort = true;
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
@@ -4221,7 +4232,7 @@ __init int intel_pmu_init(void)
x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
- x86_pmu.cpu_events = hsw_events_attrs;
+ x86_pmu.cpu_events = get_hsw_events_attrs();
x86_pmu.limit_period = bdw_limit_period;
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
@@ -4279,7 +4290,7 @@ __init int intel_pmu_init(void)
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
extra_attr = merge_attr(extra_attr, skl_format_attr);
- x86_pmu.cpu_events = hsw_events_attrs;
+ x86_pmu.cpu_events = get_hsw_events_attrs();
intel_pmu_pebs_data_source_skl(
boot_cpu_data.x86_model == INTEL_FAM6_SKYLAKE_X);
pr_cont("Skylake events, ");
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index 95cb19f4e06f..f4e4168455a8 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -3035,11 +3035,19 @@ static struct intel_uncore_type *bdx_msr_uncores[] = {
NULL,
};
+/* Bit 7 'Use Occupancy' is not available for counter 0 on BDX */
+static struct event_constraint bdx_uncore_pcu_constraints[] = {
+ EVENT_CONSTRAINT(0x80, 0xe, 0x80),
+ EVENT_CONSTRAINT_END
+};
+
void bdx_uncore_cpu_init(void)
{
if (bdx_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores)
bdx_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores;
uncore_msr_uncores = bdx_msr_uncores;
+
+ hswep_uncore_pcu.constraints = bdx_uncore_pcu_constraints;
}
static struct intel_uncore_type bdx_uncore_ha = {
diff --git a/kernel
[GIT PULL] scheduler fixes
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 3f5fe9fef5b2da06b6319fab8123056da5217c3f sched/debug: Fix task state
recording/printout
Misc fixes: a documentation fix, a Sparse warning fix and a debugging fix.
Thanks,
Ingo
-->
Claudio Scordino (1):
sched/deadline: Fix the description of runtime accounting in the
documentation
Dan Carpenter (1):
sched/deadline: Don't use dubious signed bitfields
Thomas Gleixner (1):
sched/debug: Fix task state recording/printout
Documentation/scheduler/sched-deadline.txt | 13 ++---
include/linux/sched.h | 8
include/trace/events/sched.h | 6 +++---
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/Documentation/scheduler/sched-deadline.txt
b/Documentation/scheduler/sched-deadline.txt
index e89e36ec15a5..8ce78f82ae23 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -204,10 +204,17 @@ CONTENTS
It does so by decrementing the runtime of the executing task Ti at a pace
equal
to
- dq = -max{ Ui, (1 - Uinact) } dt
+ dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt
- where Uinact is the inactive utilization, computed as (this_bq - running_bw),
- and Ui is the bandwidth of task Ti.
+ where:
+
+ - Ui is the bandwidth of task Ti;
+ - Umax is the maximum reclaimable utilization (subjected to RT throttling
+limits);
+ - Uinact is the (per runqueue) inactive utilization, computed as
+(this_bq - running_bw);
+ - Uextra is the (per runqueue) extra reclaimable utilization
+(subjected to RT throttling limits).
Let's now see a trivial example of two deadline tasks with runtime equal
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a5dc7c98b0a2..21991d668d35 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -473,10 +473,10 @@ struct sched_dl_entity {
* conditions between the inactive timer handler and the wakeup
* code.
*/
- int dl_throttled : 1;
- int dl_boosted: 1;
- int dl_yielded: 1;
- int dl_non_contending : 1;
+ unsigned intdl_throttled : 1;
+ unsigned intdl_boosted: 1;
+ unsigned intdl_yielded: 1;
+ unsigned intdl_non_contending : 1;
/*
* Bandwidth enforcement timer. Each -deadline task has its
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 306b31de5194..bc01e06bc716 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -116,9 +116,9 @@ static inline long __trace_sched_switch_state(bool preempt,
struct task_struct *
* RUNNING (we will not have dequeued if state != RUNNING).
*/
if (preempt)
- return TASK_STATE_MAX;
+ return TASK_REPORT_MAX;
- return task_state_index(p);
+ return 1 << task_state_index(p);
}
#endif /* CREATE_TRACE_POINTS */
@@ -164,7 +164,7 @@ TRACE_EVENT(sched_switch,
{ 0x40, "P" }, { 0x80, "I" }) :
"R",
- __entry->prev_state & TASK_STATE_MAX ? "+" : "",
+ __entry->prev_state & TASK_REPORT_MAX ? "+" : "",
__entry->next_comm, __entry->next_pid, __entry->next_prio)
);
Re: [PATCH v4] drm: bridge: synopsys/dw-hdmi: Enable cec clock
On 11/26/2017 01:48 AM, Pierre-Hugues Husson wrote:
Support the "cec" optional clock. The documentation already mentions "cec"
optional clock and it is used by several boards, but currently the driver
doesn't enable it, thus preventing cec from working on those boards.
And even worse: a /dev/cecX device will appear for those boards, but it
won't be functioning without configuring this clock.
Thanks for the updating the commit message. I will queue this to drm-misc-fixes
once
it's updated with the 4.15-rc1 tag.
Thanks,
Archit
Changes:
v4:
- Change commit message to stress the importance of this patch
v3:
- Drop useless braces
v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)
Signed-off-by: Pierre-Hugues Husson
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..d82b9747a979 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -138,6 +138,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+ struct clk *cec_clk;
struct dw_hdmi_i2c *i2c;
struct hdmi_data_info hdmi_data;
@@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_isfr;
}
+ hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");
+ if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
+ hdmi->cec_clk = NULL;
+ } else if (IS_ERR(hdmi->cec_clk)) {
+ ret = PTR_ERR(hdmi->cec_clk);
+ if (ret != -EPROBE_DEFER)
+ dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
+ ret);
+
+ hdmi->cec_clk = NULL;
+ goto err_iahb;
+ } else {
+ ret = clk_prepare_enable(hdmi->cec_clk);
+ if (ret) {
+ dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
+ ret);
+ goto err_iahb;
+ }
+ }
+
/* Product and revision IDs */
hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
| (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
@@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
cec_notifier_put(hdmi->cec_notifier);
clk_disable_unprepare(hdmi->iahb_clk);
+ if (hdmi->cec_clk)
+ clk_disable_unprepare(hdmi->cec_clk);
err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
err_res:
@@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
clk_disable_unprepare(hdmi->iahb_clk);
clk_disable_unprepare(hdmi->isfr_clk);
+ if (hdmi->cec_clk)
+ clk_disable_unprepare(hdmi->cec_clk);
if (hdmi->i2c)
i2c_del_adapter(&hdmi->i2c->adap);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[GIT PULL] x86 fixes
Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df x86/decoder: Add new TEST instruction pattern Misc fixes: - topology enumeration fixes - KASAN fix - two entry fixes (not yet the big series related to KASLR) - remove obsolete code - instruction decoder fix - better /dev/mem sanity checks, hopefully working better this time - pkeys fixes - two ACPI fixes - 5-level paging related fixes - UMIP fixes that should make application visible faults more debuggable - boot fix for weird virtualization environment out-of-topic modifications in x86-urgent-for-linus: - drivers/pci/Kconfig# fd2fa6c18b72: x86/PCI: Remove unused Hyper drivers/pci/Makefile # fd2fa6c18b72: x86/PCI: Remove unused Hyper drivers/pci/htirq.c# fd2fa6c18b72: x86/PCI: Remove unused Hyper include/linux/htirq.h # fd2fa6c18b72: x86/PCI: Remove unused Hyper include/linux/pci.h# fd2fa6c18b72: x86/PCI: Remove unused Hyper tools/testing/selftests/x86/5lvl.c # 97f404ad3e53: x86/selftests: Add test for tools/testing/selftests/x86/Makefile# 97f404ad3e53: x86/selftests: Add test for tools/testing/selftests/x86/mpx-hw.h# a6400120d042: x86/mpx/selftests: Fix up we tools/testing/selftests/x86/pkey-helpers.h# 7b659ee3e1fe: x86/pkeys/selftests: Fix pro tools/testing/selftests/x86/protection_keys.c# 91c49c2deb96: x86/pkeys/selftests: Rename Thanks, Ingo --> Andi Kleen (2): perf/x86/intel/uncore: Cache logical pkg id in uncore driver x86/topology: Avoid wasting 128k for package id array Andrey Ryabinin (1): x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow Andy Lutomirski (2): x86/entry/64: Fix entry_SYSCALL_64_after_hwframe() IRQ tracing x86/entry/64: Add missing irqflags tracing to native_load_gs_index() Bjorn Helgaas (1): x86/PCI: Remove unused HyperTransport interrupt support Borislav Petkov (1): x86/umip: Fix insn_get_code_seg_params()'s return value Chao Fan (1): x86/boot/KASLR: Remove unused variable Craig Bergstrom (1): x86/mm: Limit mmap() of /dev/mem to valid physical addresses Dave Hansen (4): x86/pkeys: Update documentation about availability x86/mpx/selftests: Fix up weird arrays x86/pkeys/selftests: Rename 'si_pkey' to 'siginfo_pkey' x86/pkeys/selftests: Fix protection keys write() warning Kirill A. Shutemov (2): x86/mm: Prevent non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border x86/selftests: Add test for mapping placement for 5-level paging Masami Hiramatsu (1): x86/decoder: Add new TEST instruction pattern Prarit Bhargava (1): x86/smpboot: Fix __max_logical_packages estimate Ricardo Neri (4): x86/umip: Select X86_INTEL_UMIP by default x86/umip: Print a line in the boot log that UMIP has been enabled x86/umip: Identify the STR and SLDT instructions x86/umip: Print a warning into the syslog if UMIP-protected instructions are used Tom Lendacky (1): x86/boot: Fix boot failure when SMP MP-table is based at 0 Vikas C Sajjan (2): x86/acpi: Handle SCI interrupts above legacy space gracefully x86/acpi: Reduce code duplication in mp_override_legacy_irq() Documentation/x86/protection-keys.txt | 9 +- arch/x86/Kconfig | 14 +- arch/x86/boot/compressed/kaslr.c | 5 +- arch/x86/entry/entry_64.S | 14 +- arch/x86/events/intel/uncore.c| 4 +- arch/x86/events/intel/uncore.h| 2 +- arch/x86/events/intel/uncore_snbep.c | 2 +- arch/x86/include/asm/elf.h| 1 + arch/x86/include/asm/hw_irq.h | 8 -- arch/x86/include/asm/hypertransport.h | 46 -- arch/x86/include/asm/insn-eval.h | 2 +- arch/x86/include/asm/io.h | 4 + arch/x86/include/asm/irqdomain.h | 6 - arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/acpi/boot.c | 61 +--- arch/x86/kernel/apic/Makefile | 1 - arch/x86/kernel/apic/htirq.c | 198 -- arch/x86/kernel/apic/vector.c | 5 +- arch/x86/kernel/cpu/common.c | 2 + arch/x86/kernel/mpparse.c | 6 +- arch/x86/kernel/smpboot.c | 128 + arch/x86/kernel/sys_x86_64.c | 10 +- arch/x86/kernel/umip.c| 88 ++-- arch/x86/lib/insn-eval.c | 4 +- arch/x86/lib/x86-opcode-map.txt | 2 +- arch/x86/mm/hugetlbpage.c | 1
[GIT pull] irq updates for 4.15
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
The last set of updates for 4.15-rc1:
- Unbreak the irq trigger type check for legacy platforms
- A handful fixes for ARM GIC v3/4 interrupt controllers
- A few trivial fixes all over the place.
Thanks,
tglx
-->
Arvind Yadav (2):
irqchip/s3c24xx: pr_err() strings should end with newlines
irqchip/gic-v3: pr_err() strings should end with newlines
Colin Ian King (1):
irqchip/qcom: Fix u32 comparison with value less than zero
Johan Hovold (1):
irqchip/gic-v3: Fix ppi-partitions lookup
Kees Cook (1):
genirq/matrix: Make - vs ?: Precedence explicit
Marc Zyngier (4):
genirq: Track whether the trigger type has been set
irqchip/gic-v4: Clear IRQ_DISABLE_UNLAZY again if mapping fails
irqchip/gic-v4: Add forward definition of struct irq_domain_ops
irqchip/gic-v3-its: Remove artificial dependency on PCI
Vasyl Gomonovych (1):
irqchip/imgpdc: Use resource_size function on resource object
Wei Yongjun (1):
irqchip/exiu: Fix return value check in exiu_init()
drivers/irqchip/Kconfig | 7 +++
drivers/irqchip/Makefile| 3 ++-
drivers/irqchip/irq-gic-v3.c| 11 +++
drivers/irqchip/irq-gic-v4.c| 7 ++-
drivers/irqchip/irq-imgpdc.c| 2 +-
drivers/irqchip/irq-s3c24xx.c | 4 ++--
drivers/irqchip/irq-sni-exiu.c | 4 ++--
drivers/irqchip/qcom-irq-combiner.c | 2 +-
include/linux/irq.h | 11 ++-
include/linux/irqchip/arm-gic-v4.h | 1 +
kernel/irq/manage.c | 13 -
kernel/irq/matrix.c | 2 +-
12 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 53380bd72ea4..c70476b34a53 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -41,8 +41,15 @@ config ARM_GIC_V3
config ARM_GIC_V3_ITS
bool
+ select GENERIC_MSI_IRQ_DOMAIN
+ default ARM_GIC_V3
+
+config ARM_GIC_V3_ITS_PCI
+ bool
+ depends on ARM_GIC_V3_ITS
depends on PCI
depends on PCI_MSI
+ default ARM_GIC_V3_ITS
config ARM_NVIC
bool
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index dae7282bfdef..d2df34a54d38 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -30,7 +30,8 @@ obj-$(CONFIG_ARM_GIC_PM) += irq-gic-pm.o
obj-$(CONFIG_ARCH_REALVIEW)+= irq-gic-realview.o
obj-$(CONFIG_ARM_GIC_V2M) += irq-gic-v2m.o
obj-$(CONFIG_ARM_GIC_V3) += irq-gic-v3.o irq-gic-common.o
-obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o irq-gic-v4.o
+obj-$(CONFIG_ARM_GIC_V3_ITS) += irq-gic-v3-its.o
irq-gic-v3-its-platform-msi.o irq-gic-v4.o
+obj-$(CONFIG_ARM_GIC_V3_ITS_PCI) += irq-gic-v3-its-pci-msi.o
obj-$(CONFIG_PARTITION_PERCPU) += irq-partition-percpu.o
obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index b54b55597ffb..16fddff38f22 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1103,18 +1103,18 @@ static void __init gic_populate_ppi_partitions(struct
device_node *gic_node)
int nr_parts;
struct partition_affinity *parts;
- parts_node = of_find_node_by_name(gic_node, "ppi-partitions");
+ parts_node = of_get_child_by_name(gic_node, "ppi-partitions");
if (!parts_node)
return;
nr_parts = of_get_child_count(parts_node);
if (!nr_parts)
- return;
+ goto out_put_node;
parts = kzalloc(sizeof(*parts) * nr_parts, GFP_KERNEL);
if (WARN_ON(!parts))
- return;
+ goto out_put_node;
for_each_child_of_node(parts_node, child_part) {
struct partition_affinity *part;
@@ -1181,6 +1181,9 @@ static void __init gic_populate_ppi_partitions(struct
device_node *gic_node)
gic_data.ppi_descs[i] = desc;
}
+
+out_put_node:
+ of_node_put(parts_node);
}
static void __init gic_of_setup_kvm_info(struct device_node *node)
@@ -1521,7 +1524,7 @@ gic_acpi_init(struct acpi_subtable_header *header, const
unsigned long end)
err = gic_validate_dist_version(acpi_data.dist_base);
if (err) {
- pr_err("No distributor detected at @%p, giving up",
+ pr_err("No distributor detected at @%p, giving up\n",
acpi_data.dist_base);
goto out_dist_unmap;
}
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
index cd0bcc3b7e33..dba9d67cb9c1 100644
Re: [PATCH] lib: memmove: Use optimised memcpy if possible
Hi Dan,
On 26 November 2017 at 02:10, Dan Carpenter wrote:
> Paul's original patch should have been separated into two patches to
> begin with. The patch does two different things and one part goes
> through the MIPS tree and one part goes through Andrew, probably.
Okay. I will split his patch into two and send with my modifications.
> On Sat, Nov 25, 2017 at 10:52:04PM +0530, PrasannaKumar Muralidharan wrote:
>> Hi,
>>
>> On 4 October 2017 at 22:26, PrasannaKumar Muralidharan
>> wrote:
>> > When there is no overlap between src and dst use optimised memcpy if it
>> > is available.
>> >
>> > Signed-off-by: Paul Burton
>> > Signed-off-by: PrasannaKumar Muralidharan
>> > ---
>> > This change is a small part of a patch [1] from Paul Burton. I have
>> > added his Signed-off by. I do not know whether it is correct. Please let
>> > me know if it has to be changed, I will send a v2.
>
>
> Sign-off is like signing a legal document. Read
> Documentation/process/submitting-patches.rst the section about
> "11) Sign your work - the Developer's Certificate of Origin" for an
> explanation.
>
> So, yeah, Paul provided his s-o-b and it needs to be here as well. But
> also he maybe should get authorship credit. Just put the first line in
> the email as:
>
> From: Paul Burton
>
> But that's sort of a trickier thing, so maybe put some explanation that
> you chopped out a bit from Pauls patch in the changelog:
>
> This is part of a patch that Paul Burton wrote
> https://patchwork.linux-mips.org/patch/14517/
>
> I know you put that here, but since it's under the --- cut off it won't
> be saved in the final git log.
Sure. Will do.
>> >
>> > This patch is boot tested with qemu for MIPS architecture by removing
>> > mips's memmove routine. This patch does not contain MIPS changes. I
>> > will try to find out why [1] was not taken already and figure out what
>> > to do.
>> >
>
> Instead of boot testing, it would be better if we had a benchmark to
> show it helped speed things up.
I will try to come up with some reasonable benchmark and post its results.
>> > 1. https://patchwork.linux-mips.org/patch/14517/
>> >
>> > lib/string.c | 11 +++
>> > 1 file changed, 11 insertions(+)
>> >
>> > diff --git a/lib/string.c b/lib/string.c
>> > index 9921dc2..462ab7b 100644
>> > --- a/lib/string.c
>> > +++ b/lib/string.c
>> > @@ -825,6 +825,17 @@ void *memmove(void *dest, const void *src, size_t
>> > count)
>> > char *tmp;
>> > const char *s;
>> >
>> > +#ifdef __HAVE_ARCH_MEMCPY
>> > + /* Use optimised memcpy when there is no overlap */
>> > + const char *s_end = src + count;
>> > + const char *d = dest;
>> > + char *d_end = dest + count;
>> > +
>> > + s = src;
>> > + if ((d_end <= s) || (s_end <= d))
>> > + return memcpy(dest, src, count);
>> > +#endif /* __HAVE_ARCH_MEMCPY */
>> > +
>> > if (dest <= src) {
>> > tmp = dest;
>> > s = src;
>> > --
>> > 2.10.0
>> >
>>
>> Is there anything more that I have to do for this patch?
>>
>
> Probably a patch like this needs to go through Andrew. Send it again
> and CC Andrew Morton . It would be nice if
> we could CC a better list than LKML but I don't know which one... Few
> people read LKML.
I will add Andrew. Get maintainer script gave me a small list of email
id for this. I don't know if there is a better way than using
get_maintainer.pl.
> regards,
> dan carpenter
Thanks a lot for your time Dan.
Thanks,
PrasannaKumar
Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling
Hi,
On 11/17/2017 04:29 AM, John Stultz wrote:
From: Arnd Bergmann
An otherwise correct cleanup patch from Dan Carpenter turned a broken
failure handling from a feature patch by Hans Verkuil into a kernel
Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
adv7511/33: add HDMI CEC support").
I've managed to piece together several partial problems, though
I'm still struggling with the bigger picture:
adv7511_probe() registers a drm_bridge structure that was allocated
with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
unknown reason, which in turn triggers the registered structure to be
removed.
Elsewhere, kirin_drm_platform_probe() gets called, which calls
of_graph_get_remote_node(), and that returns NULL. Before Dan's
patch we would go on with a NULL pointer here and register that,
now kirin_drm_platform_probe() fails with -ENODEV.
In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
which after not finding a panel goes on to call of_drm_find_bridge(),
and that crashes due to the earlier list corruption.
This addresses the first issue by making sure that adv7511_probe()
does not completely fail when the adv7511_cec_init() function fails,
and instead we just disable the CEC feature. This avoids having the
driver entirely fail to load if just the CEC initialization fails.
Reported-by: Naresh Kamboju
Cc: Xinliang Liu
Cc: Dan Carpenter
Cc: Sean Paul
Cc: Hans Verkuil
Cc: Archit Taneja
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Arnd Bergmann
[jstultz: Reworked so when adv7511_cec_init() fails, we disable the feature
instead
of disabling the entire driver, which causes graphics to not funciton]
Signed-off-by: John Stultz
---
Just wanted to send out my rework of Arnd's patch here.
Feedback would be welcome.
thanks
-john
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 0e14f15..939c3b9 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
#ifdef CONFIG_DRM_I2C_ADV7511_CEC
ret = adv7511_cec_init(dev, adv7511, offset);
- if (ret)
- goto err_unregister_cec;
#else
- regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
-ADV7511_CEC_CTRL_POWER_DOWN);
+ ret = 1;
#endif
+ if (ret)
+ regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
+ADV7511_CEC_CTRL_POWER_DOWN);
This would force CEC to be powered off even if adv7511_cec_init() returned 0,
right?
We wouldn't want that if we want to use CEC on a platform that supports it.
Do we know why the call to adv7511_cec_init() is failing on the Hikey board? If
it's
because there isn't a "cec" clock specified in DT, it's not really a fatal
error, it
just means that the platform hasn't been set up to support CEC. In that case, we
should just power down the CEC block. So, if adv7511_cec_init() would return a
-ENOENT, which we could use as a hint to power down CEC. So, maybe something
like this?:
#ifdef CONFIG_DRM_I2C_ADV7511_CEC
ret = adv7511_cec_init(dev, adv7511, offset);
if (ret && ret != -ENOENT)
goto err_unregister_cec;
#endif
if (ret)
regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
ADV7511_CEC_CTRL_POWER_DOWN);
Apart from this, we should also move adv7511_cec_init() up in the probe so that
it's called before the drm_bridge is registered.
Thanks,
Archit
return 0;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions
From: Markus Elfring
Date: Sun, 26 Nov 2017 13:48:55 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index c3a46506e47e..0f9b37034eaf 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -2149,10 +2149,8 @@ sh_mobile_lcdc_channel_fb_register(struct
sh_mobile_lcdc_chan *ch)
if (info->fbdefio) {
ch->sglist = vmalloc(sizeof(struct scatterlist) *
ch->fb_size >> PAGE_SHIFT);
- if (!ch->sglist) {
- dev_err(ch->lcdc->dev, "cannot allocate sglist\n");
+ if (!ch->sglist)
return -ENOMEM;
- }
}
info->bl_dev = ch->bl;
@@ -2718,10 +2716,8 @@ static int sh_mobile_lcdc_probe(struct platform_device
*pdev)
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(&pdev->dev, "cannot allocate device data\n");
+ if (!priv)
return -ENOMEM;
- }
priv->dev = &pdev->dev;
priv->meram_dev = pdata->meram_dev;
--
2.15.0
[PATCH] [RFC] um: Convert ubd driver to blk-mq
This is the first attempt to convert the UserModeLinux block driver
(UBD) to blk-mq.
While the conversion itself is rather trivial, a few questions
popped up in my head. Maybe you can help me with them.
MAX_SG is 64, used for blk_queue_max_segments(). This comes from
a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
value for blk-mq?
The driver does IO batching, for each request it issues many UML struct
io_thread_req request to the IO thread on the host side.
One io_thread_req per SG page.
Before the conversion the driver used blk_end_request() to indicate that
a part of the request is done.
blk_mq_end_request() does not take a length parameter, therefore we can
only mark the whole request as done. See the new is_last property on the
driver.
Maybe there is a way to partially end requests too in blk-mq?
Another obstacle with IO batching is that UML IO thread requests can
fail. Not only due to OOM, also because the pipe between the UML kernel
process and the host IO thread can return EAGAIN.
In this case the driver puts the request into a list and retried later
again when the pipe turns writable.
I’m not sure whether this restart logic makes sense with blk-mq, maybe
there is a way in blk-mq to put back a (partial) request?
Signed-off-by: Richard Weinberger
---
arch/um/drivers/ubd_kern.c | 188 ++---
1 file changed, 107 insertions(+), 81 deletions(-)
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 90034acace2a..abbfe0c97418 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +58,7 @@ struct io_thread_req {
unsigned long long cow_offset;
unsigned long bitmap_words[2];
int error;
+ bool is_last;
};
@@ -142,7 +144,6 @@ struct cow {
#define MAX_SG 64
struct ubd {
- struct list_head restart;
/* name (and fd, below) of the file opened for writing, either the
* backing or the cow file. */
char *file;
@@ -156,9 +157,12 @@ struct ubd {
struct cow cow;
struct platform_device pdev;
struct request_queue *queue;
+ struct blk_mq_tag_set tag_set;
spinlock_t lock;
+};
+
+struct ubd_pdu {
struct scatterlist sg[MAX_SG];
- struct request *request;
int start_sg, end_sg;
sector_t rq_pos;
};
@@ -182,10 +186,6 @@ struct ubd {
.shared = 0, \
.cow = DEFAULT_COW, \
.lock = __SPIN_LOCK_UNLOCKED(ubd_devs.lock), \
- .request = NULL, \
- .start_sg = 0, \
- .end_sg = 0, \
- .rq_pos = 0, \
}
/* Protected by ubd_lock */
@@ -196,6 +196,12 @@ static int fake_ide = 0;
static struct proc_dir_entry *proc_ide_root = NULL;
static struct proc_dir_entry *proc_ide = NULL;
+static blk_status_t ubd_queue_rq(struct blk_mq_hw_ctx *hctx,
+const struct blk_mq_queue_data *bd);
+static int ubd_init_request(struct blk_mq_tag_set *set,
+ struct request *req, unsigned int hctx_idx,
+ unsigned int numa_node);
+
static void make_proc_ide(void)
{
proc_ide_root = proc_mkdir("ide", NULL);
@@ -448,11 +454,8 @@ __uml_help(udb_setup,
"in the boot output.\n\n"
);
-static void do_ubd_request(struct request_queue * q);
-
/* Only changed by ubd_init, which is an initcall. */
static int thread_fd = -1;
-static LIST_HEAD(restart);
/* Function to read several request pointers at a time
* handling fractional reads if (and as) needed
@@ -510,9 +513,6 @@ static int bulk_req_safe_read(
/* Called without dev->lock held, and only in interrupt context. */
static void ubd_handler(void)
{
- struct ubd *ubd;
- struct list_head *list, *next_ele;
- unsigned long flags;
int n;
int count;
@@ -532,23 +532,22 @@ static void ubd_handler(void)
return;
}
for (count = 0; count < n/sizeof(struct io_thread_req *);
count++) {
- blk_end_request(
- (*irq_req_buffer)[count]->req,
- BLK_STS_OK,
- (*irq_req_buffer)[count]->length
- );
- kfree((*irq_req_buffer)[count]);
+ struct io_thread_req *io_req = (*irq_req_buffer)[count];
+
+ /*
+* UBD is batching IO, only end the blk mq request
+* if this is the last one.
+*/
+ if (io_req->is_last)
+ blk_mq_end_request(io_req->req,
+ io_req->error ?
+
[RFC 2/2] drivers: dma-mapping: parse per device reserved mem at probe time
Invoke of_reserved_mem_device_init at dma_configure, then
there is no need to call of_reserved_mem_device_init in device
specific probe function.
Signed-off-by: Peng Fan
---
drivers/base/dma-mapping.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index e584eddef0a7..55dca06a7b55 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -351,7 +352,9 @@ int dma_configure(struct device *dev)
}
if (dma_dev->of_node) {
- ret = of_dma_configure(dev, dma_dev->of_node);
+ ret = of_reserved_mem_device_init(dev);
+ if (ret)
+ ret = of_dma_configure(dev, dma_dev->of_node);
} else if (has_acpi_companion(dma_dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -367,5 +370,6 @@ int dma_configure(struct device *dev)
void dma_deconfigure(struct device *dev)
{
of_dma_deconfigure(dev);
+ of_reserved_mem_device_release(dev);
acpi_dma_deconfigure(dev);
}
--
2.14.1
[RFC 1/2] of: reserved_mem: check return value of_dma_configure
In commit <7b07cbefb6>("iommu: of: Handle IOMMU lookup failure
with deferred probing or error"), there is possibility that
of_dma_configure may fail. So in of_reserved_mem_device_init_by_idx,
also need to propagate the return value of_dma_configure to caller,
when need to use reserved memory for a device which needs iommu.
Signed-off-by: Peng Fan
---
drivers/of/of_reserved_mem.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 22b75c82e377..61523819b50e 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -357,9 +357,12 @@ int of_reserved_mem_device_init_by_idx(struct device *dev,
/* ensure that dma_ops is set for virtual devices
* using reserved memory
*/
- of_dma_configure(dev, np);
-
- dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
+ ret = of_dma_configure(dev, np);
+ if (ret)
+ of_reserved_mem_device_release(dev);
+ else
+ dev_info(dev, "assigned reserved memory node %s\n",
+rmem->name);
} else {
kfree(rd);
}
--
2.14.1
Re: [PATCH] arm: l2c: unlock ways when in non-secure mode
On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote: > To boot Linux in Non-secure mode with l2x0, the l2x0 controller > is enabled in secure mode and ways locked to make it seems L2 cache > disabled during linux boot process. So during l2x0 initialization, > need to unlock the ways to make l2x0 could cache data/inst. Why was this chosen instead of doing what everyone else does? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
Re: [PATCH v6 09/17] irqchip: Add driver for Cirrus Logic Madera codecs
Hi Richard, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.14 next-20171124] [cannot apply to ljones-mfd/for-mfd-next asoc/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20171126-145824 config: i386-randconfig-a1-201748 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 Note: the linux-review/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20171126-145824 HEAD 7f8a24863888ec8cffb97f9849b2d22564f564fb builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): In file included from include/linux/mfd/madera/core.h:17:0, from drivers/regulator/arizona-ldo1.c:34: >> include/linux/mfd/madera/pdata.h:19:32: fatal error: sound/madera-pdata.h: >> No such file or directory #include ^ compilation terminated. vim +19 include/linux/mfd/madera/pdata.h 0d9fb60e Richard Fitzgerald 2017-11-23 13 0d9fb60e Richard Fitzgerald 2017-11-23 14 #include 0d9fb60e Richard Fitzgerald 2017-11-23 15 #include 0d9fb60e Richard Fitzgerald 2017-11-23 16 #include 0d9fb60e Richard Fitzgerald 2017-11-23 17 #include 0d9fb60e Richard Fitzgerald 2017-11-23 18 #include 0d9fb60e Richard Fitzgerald 2017-11-23 @19 #include 0d9fb60e Richard Fitzgerald 2017-11-23 20 :: The code at line 19 was first introduced by commit :: 0d9fb60e7fd7381d8adc6c16ea0b78ee9668a565 mfd: madera: Add common support for Cirrus Logic Madera codecs :: TO: Richard Fitzgerald :: CC: 0day robot --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
* Dave Hansen wrote:
> On 11/10/2017 08:05 PM, Andy Lutomirski wrote:
> > -struct tss_struct doublefault_tss __cacheline_aligned = {
> > - .x86_tss = {
> > - .sp0= STACK_START,
> > - .ss0= __KERNEL_DS,
> > - .ldt= 0,
> ...
> > +struct x86_hw_tss doublefault_tss __cacheline_aligned = {
> > + .sp0= STACK_START,
> > + .ss0= __KERNEL_DS,
> > + .ldt= 0,
> > + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
>
> FWIW, I really like the trend of renaming the hardware structures in
> such a way that it's clear that they *are* hardware structures.
>
> It might also be nice to reference the relevant SDM sections on the
> topic, or even to include a comment along the lines of how it get used.
> This chunk from the SDM is particularly relevant:
>
> "The TSS holds information important to 64-bit mode and that is not
> directly related to the task-switch mechanism."
That makes sense - I've updated this patch with the following description added
to
struct x86_hw_tss:
+/*
+ * Note that while the legacy 'TSS' name comes from 'Task State Segment',
+ * on modern x86 CPUs the TSS holds information important to 64-bit mode
+ * unrelated to the task-switch mechanism:
+ */
I have also added your Reviewed-by tag. Updated patch below.
Thanks,
Ingo
=>
Subject: x86/entry: Fix assumptions that the HW TSS is at the beginning of
cpu_tss
From: Andy Lutomirski
Date: Thu, 23 Nov 2017 20:32:52 -0800
A future patch will move SYSENTER_stack to the beginning of cpu_tss
to help detect overflow. Before this can happen, fix several code
paths that hardcode assumptions about the old layout.
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
[ Updated the 'struct tss_struct' comments, as suggested by Dave Hansen. ]
Reviewed-by: Borislav Petkov
Reviewed-by: Dave Hansen
Reviewed-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Link:
https://lkml.kernel.org/r/d40a2c5ae4539d64090849a374f3169ec492f4e2.1511497875.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/desc.h |2 +-
arch/x86/include/asm/processor.h |9 +++--
arch/x86/kernel/cpu/common.c |8
arch/x86/kernel/doublefault.c| 32 +++-
arch/x86/power/cpu.c | 13 +++--
5 files changed, 34 insertions(+), 30 deletions(-)
Index: tip/arch/x86/include/asm/desc.h
===
--- tip.orig/arch/x86/include/asm/desc.h
+++ tip/arch/x86/include/asm/desc.h
@@ -178,7 +178,7 @@ static inline void set_tssldt_descriptor
#endif
}
-static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
+static inline void __set_tss_desc(unsigned cpu, unsigned int entry, struct
x86_hw_tss *addr)
{
struct desc_struct *d = get_cpu_gdt_rw(cpu);
tss_desc tss;
Index: tip/arch/x86/include/asm/processor.h
===
--- tip.orig/arch/x86/include/asm/processor.h
+++ tip/arch/x86/include/asm/processor.h
@@ -163,7 +163,7 @@ enum cpuid_regs_idx {
extern struct cpuinfo_x86 boot_cpu_data;
extern struct cpuinfo_x86 new_cpu_data;
-extern struct tss_struct doublefault_tss;
+extern struct x86_hw_tss doublefault_tss;
extern __u32 cpu_caps_cleared[NCAPINTS];
extern __u32 cpu_caps_set[NCAPINTS];
@@ -253,6 +253,11 @@ static inline void load_cr3(pgd_t *pgdir
write_cr3(__sme_pa(pgdir));
}
+/*
+ * Note that while the legacy 'TSS' name comes from 'Task State Segment',
+ * on modern x86 CPUs the TSS also holds information important to 64-bit mode,
+ * unrelated to the task-switch mechanism:
+ */
#ifdef CONFIG_X86_32
/* This is the TSS defined by the hardware. */
struct x86_hw_tss {
@@ -323,7 +328,7 @@ struct x86_hw_tss {
#define IO_BITMAP_BITS 65536
#define IO_BITMAP_BYTES(IO_BITMAP_BITS/8)
#define IO_BITMAP_LONGS(IO_BITMAP_BYTES/sizeof(long))
-#define IO_BITMAP_OFFSET offsetof(struct tss_struct, io_bitmap)
+#define IO_BITMAP_OFFSET (offsetof(struct tss_struct, io_bitmap)
- offsetof(struct tss_struct, x86_tss))
#define INVALID_IO_BITMAP_OFFSET 0x8000
struct tss_struct {
Index: tip/arch/x86/kernel/cpu/common.c
===
--- tip.orig/arch/x86/kernel/cpu/common.c
+++ tip/arch/x86/kernel/cpu/common.c
@@ -1582,7 +1582,7 @@ void cpu_init(void)
}
}
- t->x86_tss.io_bitmap_base = offsetof(struct tss_struct, io_bitmap);
+ t->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET;
/*
* <= is required because the CPU will access up to
@@ -1601,7 +1601,7 @@ void cpu_init(void)
Re: [PATCH v2 1/2] s390/virtio: remove the old KVM virtio headers
Hi Michael, I love your patch! Yet something to improve: [auto build test ERROR on v4.14] [cannot apply to s390/features linus/master kvms390/next next-20171124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michael-S-Tsirkin/s390-virtio-remove-the-old-KVM-virtio-headers/20171126-050658 config: s390-default_defconfig (attached as .config) compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=s390 All errors (new ones prefixed by >>): >> arch/s390/kernel/setup.c:63:10: fatal error: asm/kvm_virtio.h: No such file >> or directory #include ^~ compilation terminated. -- >> drivers/s390/virtio/kvm_virtio.c:27:10: fatal error: asm/kvm_virtio.h: No >> such file or directory #include ^~ compilation terminated. vim +63 arch/s390/kernel/setup.c ^1da177e4 Linus Torvalds2005-04-16 51 46b05d261 Michael Holzheu 2007-02-21 52 #include 1e3cab2f2 Heiko Carstens2012-03-30 53 #include ^1da177e4 Linus Torvalds2005-04-16 54 #include ^1da177e4 Linus Torvalds2005-04-16 55 #include ^1da177e4 Linus Torvalds2005-04-16 56 #include ^1da177e4 Linus Torvalds2005-04-16 57 #include ^1da177e4 Linus Torvalds2005-04-16 58 #include 0b642ede4 Peter Oberparleiter 2005-05-01 59 #include 0b642ede4 Peter Oberparleiter 2005-05-01 60 #include cc13ad621 Heiko Carstens2006-06-25 61 #include fe355b7f1 Hongjie Yang 2007-02-05 62 #include faeba830b Christian Borntraeger 2008-06-20 @63 #include 60a0c68df Michael Holzheu 2011-10-30 64 #include 4857d4bbe Michael Holzheu 2012-03-11 65 #include cd1834591 Heinz Graalfs 2012-06-11 66 #include bcfcbb6ba Martin Schwidefsky2014-08-11 67 #include 3a368f742 Philipp Hachtmann 2014-03-06 68 #include 8b646bd75 Martin Schwidefsky2012-03-11 69 #include "entry.h" c1821c2e9 Gerald Schaefer 2007-02-05 70 :: The code at line 63 was first introduced by commit :: faeba830b086bc9e58748869054e994cb09693cd s390: use virtio_console for KVM on s390 :: TO: Christian Borntraeger :: CC: Rusty Russell --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [uml-devel] [PATCH] [RFC] um: Convert ubd driver to blk-mq
Anton,
please don't crop the CC list.
Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
> I need to do some reading on this.
>
> First of all - a stupid question: mq's primary advantage is in
> multi-core systems as it improves io and core utilization. We are still
> single-core in UML and AFAIK this is likely to stay that way, right?
Well, someday blk-mq should completely replace the legacy block interface.
Christoph asked me convert the UML driver.
Also do find corner cases in blk-mq.
> On 26/11/17 13:10, Richard Weinberger wrote:
> > This is the first attempt to convert the UserModeLinux block driver
> > (UBD) to blk-mq.
> > While the conversion itself is rather trivial, a few questions
> > popped up in my head. Maybe you can help me with them.
> >
> > MAX_SG is 64, used for blk_queue_max_segments(). This comes from
> > a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
> > value for blk-mq?
> >
> > The driver does IO batching, for each request it issues many UML struct
> > io_thread_req request to the IO thread on the host side.
> > One io_thread_req per SG page.
> > Before the conversion the driver used blk_end_request() to indicate that
> > a part of the request is done.
> > blk_mq_end_request() does not take a length parameter, therefore we can
> > only mark the whole request as done. See the new is_last property on the
> > driver.
> > Maybe there is a way to partially end requests too in blk-mq?
> >
> > Another obstacle with IO batching is that UML IO thread requests can
> > fail. Not only due to OOM, also because the pipe between the UML kernel
> > process and the host IO thread can return EAGAIN.
> > In this case the driver puts the request into a list and retried later
> > again when the pipe turns writable.
> > I’m not sure whether this restart logic makes sense with blk-mq, maybe
> > there is a way in blk-mq to put back a (partial) request?
>
> This all sounds to me as blk-mq requests need different inter-thread
> IPC. We presently rely on the fact that each request to the IO thread is
> fixed size and there is no natural request grouping coming from upper
> layers.
>
> Unless I am missing something, this looks like we are now getting group
> requests, right? We need to send a group at a time which is not
> processed until the whole group has been received in the IO thread. We
> cans still batch groups though, but should not batch individual
> requests, right?
The question is, do we really need batching at all with blk-mq?
Jeff implemented that 10 years ago.
> My first step (before moving to mq) would have been to switch to a unix
> domain socket pair probably using SOCK_SEQPACKET or SOCK_DGRAM. The
> latter for a socket pair will return ENOBUF if you try to push more than
> the receiving side can handle so we should not have IPC message loss.
> This way, we can push request groups naturally instead of relying on a
> "last" flag and keeping track of that for "end of request".
The pipe is currently a socketpair. UML just calls it "pipe". :-(
> It will be easier to roll back the batching before we do that. Feel free
> to roll back that commit.
>
> Once that is in, the whole batching will need to be redone as it should
> account for variable IPC record size and use sendmmsg/recvmmsg pair -
> same as in the vector IO. I am happy to do the honors on that one :)
Let's see what block guys say.
Thanks,
//richard
Re: [PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.
On Tue, Nov 21, 2017 at 11:58:56AM -0700, Jason Gunthorpe wrote: > On Tue, Nov 21, 2017 at 10:28:58AM -0800, Guenter Roeck wrote: > > > I'll split the patch into two parts, and only add (hopefully) > > non-controversial tpm2 attributes for now (which I think is durations > > and timeouts). Or, in other words, I'll split the attributes into > > two groups - one generic and one for tpm1. > > Ok. Please look at new attributes you wish to add for tpm2 and see if > they meet the modern sysfs sensibility of one value per file, etc. > > Jason In general: if something can be retrieved through /dev/tpm0, there is no any sane reason to have a sysfs attribute for such. /Jarkko
Re: [PATCH 12/43] x86/espfix/64: Stop assuming that pt_regs is on the entry stack
* Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 10:25 AM, Borislav Petkov wrote:
> > On Fri, Nov 24, 2017 at 06:23:40PM +0100, Ingo Molnar wrote:
> >> From: Andy Lutomirski
> >>
> >> When we start using an entry trampoline, a #GP from userspace will
> >> be delivered on the entry stack, not on the task stack. Fix the
> >> espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than
> >> assuming that pt_regs + 1 == SP0. This won't change anything
> >> without an entry stack, but it will make the code continue to work
> >> when an entry stack is added.
> >>
> >> Signed-off-by: Andy Lutomirski
> >> Signed-off-by: Thomas Gleixner
> >> Reviewed-by: Thomas Gleixner
> >> Cc: Borislav Petkov
> >> Cc: Brian Gerst
> >> Cc: Dave Hansen
> >> Cc: Josh Poimboeuf
> >> Cc: Linus Torvalds
> >> Cc: Peter Zijlstra
> >> Link:
> >> https://lkml.kernel.org/r/b1ef4136616c6bd2a75d1fd2736d1d54437d65a8.1511497875.git.l...@kernel.org
> >> Signed-off-by: Ingo Molnar
> >> ---
> >> arch/x86/kernel/traps.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> >> index 2008dd0f8ccb..1bd43f044c62 100644
> >> --- a/arch/x86/kernel/traps.c
> >> +++ b/arch/x86/kernel/traps.c
> >> @@ -359,7 +359,8 @@ dotraplinkage void do_double_fault(struct pt_regs
> >> *regs, long error_code)
> >> regs->cs == __KERNEL_CS &&
> >> regs->ip == (unsigned long)native_irq_return_iret)
> >> {
> >> - struct pt_regs *normal_regs = task_pt_regs(current);
> >> + struct pt_regs *normal_regs =
> >> + (struct pt_regs *)this_cpu_read(cpu_tss.x86_tss.sp0)
> >> - 1;
> >
> > Just let that line stick out. Also, you can shorten it by renaming
> > normal_regs to something much shorter - it is a local variable and the
> > comment already explains everything you you can just as well have:
> >
> > struct pt_regs *r = (struct pt_regs
> > *)this_cpu_read(cpu_tss.x86_tss.sp0) - 1;
> >
>
> Done, along with much better comments.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack&id=6510485d026abdd144d170b1bc8508327acb5648
I have added Boris's reviewed-by tag:
Reviewed-by: Borislav Petkov
which I suspect applies now?
Thanks,
Ingo
Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On Tue, Nov 21, 2017 at 08:29:07PM +, Roberts, William C wrote: > > TPM specification is not a formal specification AFAIK. > > The published parts are, granted many things are changing. Yes, how it defines the protocol, you are correct. It does not have a formal definition of RM behavior or at least I haven't found it. > > > Yes, sorry for that. It wasn't clear to me that there was a sandbox > > > and my lack of familiarity with the code was the reason why I posted > > > as a RFC in the first place. > > > > > > Do you agree with Jason's suggestion to send a synthesized TPM command > > > in the that the command isn't supported? > > > > Nope. > > We should update the elf loader to make sure that ELF files don't contain > Incorrect instructions. We shouldn't have this type of policy in the driver > considering that the tpm is designed to handle it. Obviously you disagree, > just understand you're wrong :-P I think -EINVAL is better than synthetizing commands that are not really from the TPM. And we would break backwards compatability by doing this. As I said in an earlier response I would rather compare resource manager to virtual memory than virtual machine. /Jarkko
Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On Wed, Nov 22, 2017 at 10:26:24AM +0100, Javier Martinez Canillas wrote:
> On 11/21/2017 09:29 PM, Roberts, William C wrote:
>
> [snip]
>
> >>>
> >>> Do you agree with Jason's suggestion to send a synthesized TPM command
> >>> in the that the command isn't supported?
> >>
> >> Nope.
> >
> > We should update the elf loader to make sure that ELF files don't contain
> > Incorrect instructions. We shouldn't have this type of policy in the driver
> > considering that the tpm is designed to handle it. Obviously you disagree,
> > just understand you're wrong :-P
> >
>
> I think the sandbox is correct and makes sense to only send well constructed
> commands to the TPM. So my RFC patch breaking the sandbox is clearly wrong.
>
> I still do believe that both interfaces (/dev/tpm and /dev/tpmrm) should be
> consistent if possible though. In other words, I don't see the value of not
> behaving as expected by the spec if this doesn't have security implications
> as is the case with the approach suggested by Jason. And the implementation
> for sending the synthesized response is also trivial.
>
> The other option that's fixing this in user-space will be a workaround, since
> it would either be to check for TPM_RC_SUCCESS instead of TPM_RC_COMMAND_CODE
> or make the SAPI library infer that a -EINVAL error means that a command isn't
> supported and return a TPM_RC_COMMAND_CODE to the caller.
>
> For completeness, I'll share my patch implementing what Jason suggested, even
> when is quite likely that Jarkko won't like it since he has a strong opinion
> on this:
I apologize for long delay. I have this enormous upstreaming project on
my shoulders [1], which will temporarily cause more delay for TPM but
things will settle once it is pulled to the mainline.
I'll go through the patch within next few days.
[1] https://lkml.org/lkml/2017/11/25/123
/Jarkko
> From 145b6891a68b32ae803a4b0abd3d35679ed6b2a1 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Tue, 21 Nov 2017 12:32:15 +0100
> Subject: [RFCv2 PATCH] tpm: return a TPM_RC_COMMAND_CODE response if command
> isn't implemented
>
> According to the TPM Library Specification, a TPM device must do a command
> header validation before processing and return a TPM_RC_COMMAND_CODE code
> if the command is not implemented.
>
> So user-space will expect to handle the response cods as error. But if the
> in-kernel resource manager is used (/dev/tpmrm?), an -EINVAL errno code is
> returned instead if the command isn't implemented. This confuses userspace
> since it doesn't expect that error value.
>
> This also isn't consistent with the behavior when not using TPM spaces and
> accessing the TPM directly (/dev/tpm?). In this case, the command is sent
> to the TPM even when implemented and userspace gets an error from the TPM.
>
> Instead of returning an -EINVAL errno code when the tpm_validate_command()
> function fails, synthesize a TPM command response so userspace can get a
> TPM_RC_COMMAND_CODE as expected when a chip doesn't implement the command.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> Changes since RFCv1:
> - Don't send not validated commands to the TPM, instead return a synthesized
> response with the correct TPM return code (suggested by Jason Gunthorpe).
>
> drivers/char/tpm/tpm-interface.c | 28
> drivers/char/tpm/tpm.h | 1 +
> 2 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index ebe0a1d36d8c..b8d01897c0ba 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -328,7 +328,7 @@ unsigned long tpm_calc_ordinal_duration(struct tpm_chip
> *chip,
> }
> EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration);
>
> -static bool tpm_validate_command(struct tpm_chip *chip,
> +static int tpm_validate_command(struct tpm_chip *chip,
>struct tpm_space *space,
>const u8 *cmd,
>size_t len)
> @@ -340,10 +340,10 @@ static bool tpm_validate_command(struct tpm_chip *chip,
> unsigned int nr_handles;
>
> if (len < TPM_HEADER_SIZE)
> - return false;
> + return -EINVAL;
>
> if (!space)
> - return true;
> + return 0;
>
> if (chip->flags & TPM_CHIP_FLAG_TPM2 && chip->nr_commands) {
> cc = be32_to_cpu(header->ordinal);
> @@ -352,7 +352,7 @@ static bool tpm_validate_command(struct tpm_chip *chip,
> if (i < 0) {
> dev_dbg(&chip->dev, "0x%04X is an invalid command\n",
> cc);
> - return false;
> + return -EOPNOTSUPP;
> }
>
> attrs = chip->cc_attrs_tbl[i];
> @@ -362,11 +362,11 @@ static bool tpm_validate_command(struct tpm_chip *chip,
>
Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On Tue, Nov 21, 2017 at 01:49:23PM +0100, Javier Martinez Canillas wrote: > Ok. Thanks a lot for your feedback. I already had that patch but didn't want > to post it before knowing your opinion, I'll drop it now. > > Philip, > > I think this means that we can now fix this in user-space then? That was in > fact my first suggestion in the filed tpm2-tools issue. Thanks for anyway putting that patch out. I'll investigate it with time and reconsider my position. Philip, can you share your view. Adding also James. /Jarkko
[PATCH 0/2] video: s3c-fb: Adjustments for s3c_fb_probe()
From: Markus Elfring Date: Sun, 26 Nov 2017 15:12:34 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/video/fbdev/s3c-fb.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.15.0
[PATCH 1/2] video: s3c-fb: Delete an error message for a failed memory allocation in s3c_fb_probe()
From: Markus Elfring
Date: Sun, 26 Nov 2017 15:00:16 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/s3c-fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 5f4f696c2ecf..0914c973cbd9 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1384,10 +1384,8 @@ static int s3c_fb_probe(struct platform_device *pdev)
}
sfb = devm_kzalloc(dev, sizeof(struct s3c_fb), GFP_KERNEL);
- if (!sfb) {
- dev_err(dev, "no memory for framebuffers\n");
+ if (!sfb)
return -ENOMEM;
- }
dev_dbg(dev, "allocate new framebuffer %p\n", sfb);
--
2.15.0
Re: [PATCH 13/43] x86/asm/64: Use a percpu trampoline stack for IDT entries
* Borislav Petkov wrote: > On Fri, Nov 24, 2017 at 06:23:41PM +0100, Ingo Molnar wrote: > > From: Andy Lutomirski > > > > Historically, IDT entries from usermode have always gone directly > > to the running task's kernel stack. Rearrange it so that we enter on > > a percpu trampoline stack and then manually switch to the task's stack. > > This touches a couple of extra cachelines, but it gives us a chance > > to run some code before we touch the kernel stack. > > > > The asm isn't exactly beautiful, but I think that fully refactoring > > it can wait. > > > > Signed-off-by: Andy Lutomirski > > Signed-off-by: Thomas Gleixner > > I think you mean Reviewed-by: here. The following patches have it too. > > > Cc: Borislav Petkov > > Cc: Brian Gerst > > Cc: Dave Hansen > > Cc: Josh Poimboeuf > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Link: > > https://lkml.kernel.org/r/fa3958723a1a85baeaf309c735b775841205800e.1511497875.git.l...@kernel.org > > Signed-off-by: Ingo Molnar > > --- > > arch/x86/entry/entry_64.S| 67 > > ++-- > > arch/x86/entry/entry_64_compat.S | 5 ++- > > arch/x86/include/asm/switch_to.h | 2 +- > > arch/x86/include/asm/traps.h | 1 - > > arch/x86/kernel/cpu/common.c | 6 ++-- > > arch/x86/kernel/traps.c | 18 +-- > > 6 files changed, 68 insertions(+), 31 deletions(-) > > ... > > > diff --git a/arch/x86/include/asm/switch_to.h > > b/arch/x86/include/asm/switch_to.h > > index 8c6bd6863db9..a6796ac8d311 100644 > > --- a/arch/x86/include/asm/switch_to.h > > +++ b/arch/x86/include/asm/switch_to.h > > @@ -93,7 +93,7 @@ static inline void update_sp0(struct task_struct *task) > > #ifdef CONFIG_X86_32 > > load_sp0(task->thread.sp0); > > #else > > - load_sp0(task_top_of_stack(task)); > > + /* On x86_64, sp0 always points to the entry trampoline stack. */ > > #endif > > You can put this comment to the one ontop and remove the #else. > ifdeffery is always ugly and the less, the better. Ok, I made it: /* On x86_64, sp0 always points to the entry trampoline stack, which is constant: */ #ifdef CONFIG_X86_32 load_sp0(task->thread.sp0); #endif > > /* > > * This is called from entry_64.S early in handling a fault > > * caused by a bad iret to user mode. To handle the fault > > -* correctly, we want move our stack frame to task_pt_regs > > -* and we want to pretend that the exception came from the > > -* iret target. > > +* correctly, we want move our stack frame to where it would > > " ... we want to move... " > > > +* be had we entered directly on the entry stack (rather than > > +* just below the IRET frame) and we want to pretend that the > > +* exception came from the iret target. > > s/iret/IRET/ > > > */ > > struct bad_iret_stack *new_stack = > > - container_of(task_pt_regs(current), > > -struct bad_iret_stack, regs); > > + (struct bad_iret_stack *)this_cpu_read(cpu_tss.x86_tss.sp0) - 1; > > > > /* Copy the IRET target to the new stack. */ > > memmove(&new_stack->regs.ip, (void *)s->regs.sp, 5*8); > > -- > > with that: > > Reviewed-by: Borislav Petkov Fixed those details and added your tag, thanks Boris! Ingo
[PATCH 2/2] video: s3c-fb: Improve a size determination in s3c_fb_probe()
From: Markus Elfring Date: Sun, 26 Nov 2017 15:03:03 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/video/fbdev/s3c-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c index 0914c973cbd9..8c7623d63eb1 100644 --- a/drivers/video/fbdev/s3c-fb.c +++ b/drivers/video/fbdev/s3c-fb.c @@ -1383,7 +1383,7 @@ static int s3c_fb_probe(struct platform_device *pdev) return -EINVAL; } - sfb = devm_kzalloc(dev, sizeof(struct s3c_fb), GFP_KERNEL); + sfb = devm_kzalloc(dev, sizeof(*sfb), GFP_KERNEL); if (!sfb) return -ENOMEM; -- 2.15.0
Re: [PATCH 14/43] x86/asm/64: Return to userspace from the trampoline stack
* Borislav Petkov wrote: > On Fri, Nov 24, 2017 at 06:23:42PM +0100, Ingo Molnar wrote: > > From: Andy Lutomirski > > > > By itself, this is useless. It gives us the ability to run some final > > code before exit that cannnot run on the kernel stack. This could > > include a CR3 switch a la KAISER or some kernel stack erasing, for > > example. (Or even weird things like *changing* which kernel stack > > gets used as an ASLR-strengthening mechanism.) > > > > The SYSRET32 path is not covered yet. It could be in the future or > > we could just ignore it and force the slow path if needed. > > > > Signed-off-by: Andy Lutomirski > > Signed-off-by: Thomas Gleixner > > Cc: Borislav Petkov > > Cc: Brian Gerst > > Cc: Dave Hansen > > Cc: Josh Poimboeuf > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Link: > > https://lkml.kernel.org/r/d350017000eed20922c3b2711a2d9229dc809256.1511497875.git.l...@kernel.org > > Signed-off-by: Ingo Molnar > > --- > > arch/x86/entry/entry_64.S | 55 > > +++ > > 1 file changed, 51 insertions(+), 4 deletions(-) > > Nice commenting, future generations will appreciate it! > > :-) > > Reviewed-by: Borislav Petkov Heh, indeed - if by 'future generations' you mean 'the guys who merge it, a few months down the line'. ;-) Thanks, Ingo
Re: FW: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote: > The intent of this "mostly transparent" stuff is to convey that the RM > should be as transparent as possible while acknowledging that there are > some cases where it's not / can't be. I can't say why the original > author phrased it in this somewhat ambiguous way but I wouldn't call > this a fair interpretation. It's definitely one way to read it though. > > The case in question is the RM performing a function on behalf of the > TPM: command code validation. This is a perfectly valid thing to do in > the RM though the RM should aim to behave as the TPM would if the RM > takes any action (sending a TPM response buffer with the appropriate > response code). > > An additional detail is described in section 3.1 "Error Codes". There is > a mechanism to encode information about which layer in the stack > produced the response buffer. When the TPM gets a command with a command > code it doesn't support then this field will be '0' since '0' identifies > the TPM. If the RM is taking over this function it should set the field > to indicate as much. Thanks for explaining this. I guess we could take this direction. I think by utilizing the field that you mentioned we could consider this. And it would be hard to imagine this change to cause anything serious (if anything at all) with backwards compatbility. Javier, does you current version use this field? If not can you resend an update? /Jarkko
Re: FW: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation fails
On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote: > That was my interpretation as well and what I was arguing about. I'm glad to > know that you also think the same. It could be that this rationale has been your earlier emails but I just haven't recognized it :-) I think I'm starting to buy this. I don't have any fixed standing points anything basically. It is just better to be really resistant with anything that is related to user-kernel interaction until you really get it... /Jarkko
[PATCH] x86/entry/64: Create a percpu SYSCALL entry trampoline
* Andy Lutomirski wrote: > On Sat, Nov 25, 2017 at 3:40 AM, Borislav Petkov wrote: > > On Fri, Nov 24, 2017 at 06:23:43PM +0100, Ingo Molnar wrote: > >> From: Andy Lutomirski > >> > >> Handling SYSCALL is tricky: the SYSCALL handler is entered with every > >> single register (except FLAGS), including RSP, live. It somehow needs > >> to set RSP to point to a valid stack, which means it needs to save the > >> user RSP somewhere and find its own stack pointer. The canonical way > >> to do this is with SWAPGS, which lets us access percpu data using the > >> %gs prefix. > >> > >> With KAISER-like pagetable switching, this is problematic. Without a > >> scratch register, switching CR3 is impossible, so %gs-based percpu > >> memory would need to be mapped in the user pagetables. Doing that > >> without information leaks is difficult or impossible. > >> > >> Instead, use a different sneaky trick. Map a copy of the first part > >> of the SYSCALL asm at a different address for each CPU. Now RIP > >> varies depending on the CPU, so we can use RIP-relative memory access > >> to access percpu memory. By putting the relevant information (one > >> scratch slot and the stack address) at a constant offset relative to > >> RIP, we can make SYSCALL work without relying on %gs. > >> > >> A nice thing about this approach is that we can easily switch it on > >> and off if we want pagetable switching to be configurable. > >> > >> The compat variant of SYSCALL doesn't have this problem in the first > >> place -- there are plenty of scratch registers, since we don't care > >> about preserving r8-r15. This patch therefore doesn't touch SYSCALL32 > >> at all. > >> > >> XXX: Whenever we settle how KAISER gets turned on and off, we should do > >> the same to this. > >> > >> Signed-off-by: Andy Lutomirski > >> Signed-off-by: Thomas Gleixner > >> Cc: Borislav Petkov > >> Cc: Brian Gerst > >> Cc: Dave Hansen > >> Cc: Josh Poimboeuf > >> Cc: Linus Torvalds > >> Cc: Peter Zijlstra > >> Link: > >> https://lkml.kernel.org/r/b95ccae0a5a2f090c901e49fce7c9e8ff6acd40d.1511497875.git.l...@kernel.org > >> Signed-off-by: Ingo Molnar > >> --- > >> arch/x86/entry/entry_64.S | 48 > >> +++ > >> arch/x86/include/asm/fixmap.h | 2 ++ > >> arch/x86/kernel/asm-offsets.c | 1 + > >> arch/x86/kernel/cpu/common.c | 12 ++- > >> arch/x86/kernel/vmlinux.lds.S | 10 + > >> 5 files changed, 72 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > >> index 426b8c669d6a..0cde243b7542 100644 > >> --- a/arch/x86/entry/entry_64.S > >> +++ b/arch/x86/entry/entry_64.S > >> @@ -140,6 +140,54 @@ END(native_usergs_sysret64) > >> * with them due to bugs in both AMD and Intel CPUs. > >> */ > >> > >> + .pushsection .entry_trampoline, "ax" > >> + > >> +/* > >> + * The code in here gets remapped into cpu_entry_area's trampoline. This > >> means > >> + * that the assembler and linker have the wrong idea as to where this code > >> + * lives (and, in fact, it's mapped more than once, so it's not even at a > >> + * fixed address). So we can't reference any symbols outside the entry > >> + * trampoline and expect it to work. > >> + * > >> + * Instead, we carefully abuse %rip-relative addressing. > >> + * .Lentry_trampoline(%rip) refers to the start of the remapped) entry > > > > _entry_trampoline(%rip) I'd guess. > > Indeed. It used to be .L, but then I put it in the linker script the > obvious way and it wasn't any more. > > > > >> + * trampoline. We can thus find cpu_entry_area with this macro: > > > > Uuh, fun. :) > > That's what I thought! > > > > >> + */ > >> + > >> +#define CPU_ENTRY_AREA \ > >> + _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip) > > > > So this generates > > > > _entry_trampoline - 16384(%rip) > > > > here. IINM, the layout looks like this > > > > [ GDT | TSS | TSS | TSS | trampoline ] > > > > where each section is a page, and we have 4 pages per CPU. Just for my > > own understanding... > > Indeed. > > > > >> + > >> +/* The top word of the SYSENTER stack is hot and is usable as scratch > >> space. */ > >> +#define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ > >> + SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA > > > > I'm wondering if it would be easier to make SYSENTER_stack part of > > struct cpu_entry_area and thus simplify that wild offset math here :) > > It's like that with the last patch that I haven't send out applied, actually > :) > > > > > Also, pls align: > > > > #define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ > > SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA > > Done. > > > > >> + > >> +ENTRY(entry_SYSCALL_64_trampoline) > >> + UNWIND_HINT_EMPTY > >> + swapgs > >> + > >> + /* Stash the user RSP. */ > >> + movq%rsp, RSP_SCRATCH > >> + > >> + /* Load the top of the task stack into RSP */
Re: [PATCH 04/30] x86, kaiser: disable global pages by default with KAISER
* Rik van Riel wrote:
> On Fri, 2017-11-10 at 11:31 -0800, Dave Hansen wrote:
> > From: Dave Hansen
> >
> > Global pages stay in the TLB across context switches. Since all
> > contexts
> > share the same kernel mapping, these mappings are marked as global
> > pages
> > so kernel entries in the TLB are not flushed out on a context switch.
> >
> > But, even having these entries in the TLB opens up something that an
> > attacker can use [1].
> >
> > That means that even when KAISER switches page tables on return to
> > user
> > space the global pages would stay in the TLB cache.
> >
> > Disable global pages so that kernel TLB entries can be flushed before
> > returning to user space. This way, all accesses to kernel addresses
> > from
> > userspace result in a TLB miss independent of the existence of a
> > kernel
> > mapping.
> >
> > Replace _PAGE_GLOBAL by __PAGE_KERNEL_GLOBAL and keep _PAGE_GLOBAL
> > available so that it can still be used for a few selected kernel
> > mappings
> > which must be visible to userspace, when KAISER is enabled, like the
> > entry/exit code and data.
>
> Nice changelog.
>
> Why am I pointing this out?
>
> > +++ b/arch/x86/include/asm/pgtable_types.h 2017-11-10
> > 11:22:06.626244956 -0800
> > @@ -179,8 +179,20 @@ enum page_cache_mode {
> > #define PAGE_READONLY_EXEC __pgprot(_PAGE_PRESENT |
> > _PAGE_USER |\
> > _PAGE_ACCESSED)
> >
> > +/*
> > + * Disable global pages for anything using the default
> > + * __PAGE_KERNEL* macros. PGE will still be enabled
> > + * and _PAGE_GLOBAL may still be used carefully.
> > + */
> > +#ifdef CONFIG_KAISER
> > +#define __PAGE_KERNEL_GLOBAL 0
> > +#else
> > +#define __PAGE_KERNEL_GLOBAL _PAGE_GLOBAL
> > +#endif
> > +
>
> The comment above could use a little more info
> on why things are done that way, though :)
Good point - I've updated these comments to say:
/*
* Disable global pages for anything using the default
* __PAGE_KERNEL* macros.
*
* PGE will still be enabled and _PAGE_GLOBAL may still be used carefully
* for a few selected kernel mappings which must be visible to userspace,
* when KAISER is enabled, like the entry/exit code and data.
*/
#ifdef CONFIG_KAISER
#define __PAGE_KERNEL_GLOBAL0
#else
#define __PAGE_KERNEL_GLOBAL_PAGE_GLOBAL
#endif
... and I've added your Reviewed-by tag which I assume now applies?
Thanks,
Ingo
[PATCH v2] x86/mm/kaiser: Prepare the x86/entry assembly code for entry/exit CR3 switching
* Borislav Petkov wrote: > On Fri, Nov 24, 2017 at 06:23:50PM +0100, Ingo Molnar wrote: > > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > > index 3fd8bc560fae..e1650da01323 100644 > > --- a/arch/x86/entry/calling.h > > +++ b/arch/x86/entry/calling.h > > @@ -1,6 +1,7 @@ > > /* SPDX-License-Identifier: GPL-2.0 */ > > #include > > #include > > +#include > > > > /* > > > > @@ -187,6 +188,70 @@ For 32-bit we have the following conventions - kernel > > is built with > > #endif > > .endm > > > > +#ifdef CONFIG_KAISER > > + > > +/* KAISER PGDs are 8k. Flip bit 12 to switch between the two halves: */ > > +#define KAISER_SWITCH_MASK (1< > Btw, entry_64.o doesn't build when at this patch if you force-enable > CONFIG_KAISER by doing > > #define CONFIG_KAISER > > above it. > > arch/x86/entry/entry_64.S: Assembler messages: > arch/x86/entry/entry_64.S:210: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > arch/x86/entry/entry_64.S:406: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > arch/x86/entry/entry_64.S:743: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > arch/x86/entry/entry_64.S:955: Error: invalid operands (*ABS* and *UND* > sections) for `<<' > ... > > due to the missing PAGE_SHIFT definition in asm. > > I'm assuming that is resolved later - not that it breaks bisection... > > > +.macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req > > + movq%cr3, %r\scratch_reg > > + movq%r\scratch_reg, \save_reg > > What happened to making it uniform so that that macro can be invoked > like this: > > SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax ... > > instead of "splitting" the arg? > > IOW, hunk below builds here, and asm looks correct: > > 14bf: 31 db xor%ebx,%ebx > 14c1: 0f 20 d8mov%cr3,%rax > 14c4: 49 89 c6mov%rax,%r14 > 14c7: 48 a9 00 10 00 00 test $0x1000,%rax > 14cd: 74 09 je 14d8 > 14cf: 48 25 ff ef ff ff and$0xefff,%rax > 14d5: 0f 22 d8mov%rax,%cr3 > > --- > diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h > index e1650da01323..d528f7060774 100644 > --- a/arch/x86/entry/calling.h > +++ b/arch/x86/entry/calling.h > @@ -188,10 +188,12 @@ For 32-bit we have the following conventions - kernel > is built with > #endif > .endm > > +#define CONFIG_KAISER > + > #ifdef CONFIG_KAISER > > /* KAISER PGDs are 8k. Flip bit 12 to switch between the two halves: */ > -#define KAISER_SWITCH_MASK (1< +#define KAISER_SWITCH_MASK (1<<12) > > .macro ADJUST_KERNEL_CR3 reg:req > /* Clear "KAISER bit", point CR3 at kernel pagetables: */ > @@ -216,17 +218,17 @@ For 32-bit we have the following conventions - kernel > is built with > .endm > > .macro SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg:req save_reg:req > - movq%cr3, %r\scratch_reg > - movq%r\scratch_reg, \save_reg > + movq%cr3, \scratch_reg > + movq\scratch_reg, \save_reg > /* >* Is the switch bit zero? This means the address is >* up in real KAISER patches in a moment. >*/ > - testq $(KAISER_SWITCH_MASK), %r\scratch_reg > + testq $(KAISER_SWITCH_MASK), \scratch_reg > jz .Ldone_\@ > > - ADJUST_KERNEL_CR3 %r\scratch_reg > - movq%r\scratch_reg, %cr3 > + ADJUST_KERNEL_CR3 \scratch_reg > + movq\scratch_reg, %cr3 > > .Ldone_\@: > .endm > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index 4ac952080869..5a15d0852b2f 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -1256,7 +1256,7 @@ ENTRY(paranoid_entry) > xorl%ebx, %ebx > > 1: > - SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=ax save_reg=%r14 > + SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14 > > ret > END(paranoid_entry) > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > > index 34e3110b0876..4ac952080869 100644 > > --- a/arch/x86/entry/entry_64.S > > +++ b/arch/x86/entry/entry_64.S > > @@ -168,6 +168,9 @@ ENTRY(entry_SYSCALL_64_trampoline) > > /* Stash the user RSP. */ > > movq%rsp, RSP_SCRATCH > > > > + /* Note: using %rsp as a scratch reg. */ > > Haha, yap, it just got freed :) > > > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp > > + > > /* Load the top of the task stack into RSP */ > > movqCPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp > > > > @@ -198,6 +201,13 @@ ENTRY(entry_SYSCALL_64) > > > > swapgs > > movq%rsp, PER_CPU_VAR(rsp_scratch) > > < newline here. > > > + /* > > +* The kernel CR3 is needed to map the process stack, but we > > +* need a scratch register to be able to load CR3. %rsp is > > +* clobberable right now, so use it as a scratch register. > > +
[PATCH resend v2 1/3] virt: Add vboxguest driver for Virtual Box Guest integration UAPI
This commit adds the headers describing the ioctl API for the /dev/vboxguest device used by the Virtual Box Guest Additions in Virtual Box virtual machines. The driver providing the /dev/vboxguest device will allow Virtual Box Guest Additions features such as copy-and-paste, seamless mode and OpenGL pass-through. Signed-off-by: Hans de Goede --- Changes in v2: -Change all uapi headers to kernel coding style: Drop struct and enum typedefs make type and struct-member names all lowercase, enum values all uppercase. -Remove unused struct type declarations from some headers (shaving of another 1000 lines) -Remove or fixup doxygen style comments -Get rid of CHECK macros, use a function taking in_ and out_size args instead -Some other small codyingstyle fixes -Split into multiple patches --- MAINTAINERS| 7 + include/uapi/linux/vbox_err.h | 170 include/uapi/linux/vbox_vmmdev_types.h | 237 +++ include/uapi/linux/vboxguest.h | 341 + 4 files changed, 755 insertions(+) create mode 100644 include/uapi/linux/vbox_err.h create mode 100644 include/uapi/linux/vbox_vmmdev_types.h create mode 100644 include/uapi/linux/vboxguest.h diff --git a/MAINTAINERS b/MAINTAINERS index 275815e2ef44..fe3dc0e9b901 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14549,6 +14549,13 @@ S: Maintained F: drivers/virtio/virtio_input.c F: include/uapi/linux/virtio_input.h +VIRTUAL BOX GUEST DEVICE DRIVER +M: Hans de Goede +M: Arnd Bergmann +M: Greg Kroah-Hartman +S: Maintained +F: include/uapi/linux/vbox*.h + VIRTUAL SERIO DEVICE DRIVER M: Stephen Chandler Paul S: Maintained diff --git a/include/uapi/linux/vbox_err.h b/include/uapi/linux/vbox_err.h new file mode 100644 index ..6f56d2952621 --- /dev/null +++ b/include/uapi/linux/vbox_err.h @@ -0,0 +1,170 @@ +/* + * Copyright (C) 2017 Oracle Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifndef __UAPI_VBOX_ERR_H__ +#define __UAPI_VBOX_ERR_H__ + +#define VINF_SUCCESS0 +#define VERR_GENERAL_FAILURE(-1) +#define VERR_INVALID_PARAMETER (-2) +#define VERR_INVALID_MAGIC (-3) +#define VERR_INVALID_HANDLE (-4) +#define VERR_LOCK_FAILED(-5) +#define VERR_INVALID_POINTER(-6) +#define VERR_IDT_FAILED (-7) +#define VERR_NO_MEMORY (-8) +#define VERR_ALREADY_LOADED (-9) +#define VERR_PERMISSION_DENIED (-10) +#define VERR_VERSION_MISMATCH (-11) +#define VERR_NOT_IMPLEMENTED(-12) +#define VERR_INVALID_FLAGS (-13) + +#define VERR_NOT_EQUAL (-18) +#define VERR_NOT_SYMLINK(-19) +#define VERR_NO_TMP_MEMORY (-20) +#define VERR_INVALID_FMODE (-21) +#define VERR_WRONG_ORDER(-22) +#define VERR_NO_TLS_FOR_SELF(-23) +#define VERR_FAILED_TO_SET_SELF_TLS (-24) +#define VERR_NO_CONT_MEMORY (-26) +#define VERR_NO_PAGE_MEMORY (-27) +#define VERR_THREAD_IS_DEAD (-29) +#define VERR_THREAD_NOT_WAITABLE(-30) +#define VERR_PAGE_TABLE_NOT_PRESENT (-31) +#define VERR_INVALID_CONTEXT(-32) +#define VERR_TIMER_BUSY (-33) +#define VERR_ADDRESS_CONFLICT (-34) +#define VERR_UNRESOLVED_ERROR (-35) +#define VERR_INVALID_FUNCTION (-36) +#define VERR_NOT_SUPPORTED (-37) +#define VERR_ACCESS_DENIED (-38) +#define VERR_INTERRUPTED(-39) +#define VERR_TIMEOUT(-40) +#define VERR_BUFFER_OVERFLOW(-41) +#define VERR_TOO_MUCH_DA
[PATCH resend v2 2/3] virt: Add vboxguest VMMDEV communication code
This commits adds a header describing the hardware interface for the
Virtual Box Guest PCI device used in Virtual Box virtual machines and
utility functions for talking to the Virtual Box hypervisor over this
interface.
These utility functions will used both by the vboxguest driver for the
PCI device which offers the /dev/vboxguest ioctl API and by the vboxfs
driver which offers folder sharing support.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Change all uapi headers to kernel coding style: Drop struct and enum typedefs
make type and struct-member names all lowercase, enum values all uppercase.
-Remove unused struct type declarations from some headers (shaving of another
1000 lines)
-Remove or fixup doxygen style comments
-Get rid of CHECK macros, use a function taking in_ and out_size args instead
-Some other small codyingstyle fixes
-Split into multiple patches
---
MAINTAINERS | 2 +
drivers/virt/vboxguest/vboxguest_utils.c | 811 +++
drivers/virt/vboxguest/vmmdev.h | 460 ++
include/linux/vbox_utils.h | 92
4 files changed, 1365 insertions(+)
create mode 100644 drivers/virt/vboxguest/vboxguest_utils.c
create mode 100644 drivers/virt/vboxguest/vmmdev.h
create mode 100644 include/linux/vbox_utils.h
diff --git a/MAINTAINERS b/MAINTAINERS
index fe3dc0e9b901..01b30c12c267 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14554,7 +14554,9 @@ M: Hans de Goede
M: Arnd Bergmann
M: Greg Kroah-Hartman
S: Maintained
+F: include/linux/vbox_utils.h
F: include/uapi/linux/vbox*.h
+F: drivers/virt/vboxguest/
VIRTUAL SERIO DEVICE DRIVER
M: Stephen Chandler Paul
diff --git a/drivers/virt/vboxguest/vboxguest_utils.c
b/drivers/virt/vboxguest/vboxguest_utils.c
new file mode 100644
index ..5e1737d0a4fb
--- /dev/null
+++ b/drivers/virt/vboxguest/vboxguest_utils.c
@@ -0,0 +1,811 @@
+/*
+ * vboxguest vmm-req and hgcm-call code, VBoxGuestR0LibHGCMInternal.cpp,
+ * VBoxGuestR0LibGenericRequest.cpp and RTErrConvertToErrno.cpp in vbox svn.
+ *
+ * Copyright (C) 2006-2016 Oracle Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * The contents of this file may alternatively be used under the terms
+ * of the Common Development and Distribution License Version 1.0
+ * (CDDL) only, in which case the provisions of the CDDL are applicable
+ * instead of those of the GPL.
+ *
+ * You may elect to license modified versions of this file under the
+ * terms and conditions of either the GPL or the CDDL or both.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "vboxguest_core.h"
+
+/* Get the pointer to the first parameter of a HGCM call request. */
+#define VMMDEV_HGCM_CALL_PARMS(a) \
+ ((struct vmmdev_hgcm_function_parameter *)( \
+ (u8 *)(a) + sizeof(struct vmmdev_hgcm_call)))
+
+/* The max parameter buffer size for a user request. */
+#define VBG_MAX_HGCM_USER_PARM (24 * SZ_1M)
+/* The max parameter buffer size for a kernel request. */
+#define VBG_MAX_HGCM_KERNEL_PARM (16 * SZ_1M)
+
+#define VBG_DEBUG_PORT 0x504
+
+/* This protects vbg_log_buf and serializes VBG_DEBUG_PORT accesses */
+static DEFINE_SPINLOCK(vbg_log_lock);
+static char vbg_log_buf[128];
+
+#define VBG_LOG(name, pr_func) \
+void name(const char *fmt, ...)
\
+{ \
+ unsigned long flags;\
+ va_list args; \
+ int i, count; \
+ \
+ va_start(args, fmt);\
+ spin_lock_irqsave(&vbg_log_lock, flags);\
+ \
+ count = vscnprintf(vbg_log_buf, sizeof(vbg_log_buf), fmt, args);\
+ for (i = 0; i < count; i++) \
+ outb(vbg_log_buf[i], VBG_DEBUG_PORT); \
+ \
+ pr_func("%s", vbg_log_buf); \
+ \
+ spin_unlock_irqrestore(&vbg_log_lock, flags); \
+ va_end(args); \
+} \
+EXPORT_SYMBOL(name)
+
+VBG_LOG(vbg_info, pr_info);
+VBG_LOG(vbg_warn, pr_warn);
[PATCH resend v2 3/3] virt: Add vboxguest driver for Virtual Box Guest integration
This commit adds a driver for the Virtual Box Guest PCI device used in Virtual Box virtual machines. Enabling this driver will add support for Virtual Box Guest integration features such as copy-and-paste, seamless mode and OpenGL pass-through. This driver also offers vboxguest IPC functionality which is needed for the vboxfs driver which offers folder sharing support. Signed-off-by: Hans de Goede --- Changes in v2: -Change all uapi headers to kernel coding style: Drop struct and enum typedefs make type and struct-member names all lowercase, enum values all uppercase. -Remove unused struct type declarations from some headers (shaving of another 1000 lines) -Remove or fixup doxygen style comments -Get rid of CHECK macros, use a function taking in_ and out_size args instead -Some other small codyingstyle fixes -Split into multiple patches --- drivers/virt/Kconfig |1 + drivers/virt/Makefile |1 + drivers/virt/vboxguest/Kconfig | 16 + drivers/virt/vboxguest/Makefile|3 + drivers/virt/vboxguest/vboxguest_core.c| 1577 drivers/virt/vboxguest/vboxguest_core.h| 187 drivers/virt/vboxguest/vboxguest_linux.c | 469 + drivers/virt/vboxguest/vboxguest_version.h | 18 + 8 files changed, 2272 insertions(+) create mode 100644 drivers/virt/vboxguest/Kconfig create mode 100644 drivers/virt/vboxguest/Makefile create mode 100644 drivers/virt/vboxguest/vboxguest_core.c create mode 100644 drivers/virt/vboxguest/vboxguest_core.h create mode 100644 drivers/virt/vboxguest/vboxguest_linux.c create mode 100644 drivers/virt/vboxguest/vboxguest_version.h diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig index 99ebdde590f8..8d9cdfbd6bcc 100644 --- a/drivers/virt/Kconfig +++ b/drivers/virt/Kconfig @@ -30,4 +30,5 @@ config FSL_HV_MANAGER 4) A kernel interface for receiving callbacks when a managed partition shuts down. +source "drivers/virt/vboxguest/Kconfig" endif diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile index c47f04dd343b..d3f7b2540890 100644 --- a/drivers/virt/Makefile +++ b/drivers/virt/Makefile @@ -3,3 +3,4 @@ # obj-$(CONFIG_FSL_HV_MANAGER) += fsl_hypervisor.o +obj-y += vboxguest/ diff --git a/drivers/virt/vboxguest/Kconfig b/drivers/virt/vboxguest/Kconfig new file mode 100644 index ..e88ee46c31d4 --- /dev/null +++ b/drivers/virt/vboxguest/Kconfig @@ -0,0 +1,16 @@ +config VBOXGUEST + tristate "Virtual Box Guest integration support" + depends on X86 && PCI && INPUT + help + This is a driver for the Virtual Box Guest PCI device used in + Virtual Box virtual machines. Enabling this driver will add + support for Virtual Box Guest integration features such as + copy-and-paste, seamless mode and OpenGL pass-through. + + This driver also offers vboxguest IPC functionality which is needed + for the vboxfs driver which offers folder sharing support. + + Although it is possible to build this module in, it is advised + to build this driver as a module, so that it can be updated + independently of the kernel. Select M to build this driver as a + module. diff --git a/drivers/virt/vboxguest/Makefile b/drivers/virt/vboxguest/Makefile new file mode 100644 index ..203b8f465817 --- /dev/null +++ b/drivers/virt/vboxguest/Makefile @@ -0,0 +1,3 @@ +vboxguest-y := vboxguest_linux.o vboxguest_core.o vboxguest_utils.o + +obj-$(CONFIG_VBOXGUEST) += vboxguest.o diff --git a/drivers/virt/vboxguest/vboxguest_core.c b/drivers/virt/vboxguest/vboxguest_core.c new file mode 100644 index ..4927c0d3e336 --- /dev/null +++ b/drivers/virt/vboxguest/vboxguest_core.c @@ -0,0 +1,1577 @@ +/* + * vboxguest core guest-device handling code, VBoxGuest.cpp in upstream svn. + * + * Copyright (C) 2007-2016 Oracle Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * The contents of this file may alternatively be used under the terms + * of the Common Development and Distribution License Version 1.0 + * (CDDL) only, in which case the provisions of the CDDL are applicable + * instead of those of the GPL. + * + * You may elect to license modified versions of this file under the + * terms and conditions of either the GPL or the CDDL or both. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "vboxguest_core.h" +#include "vboxguest_version.h" + +/* Get the pointer to the first HGCM parameter. */ +#define VBG_IOCTL_HGCM_CALL_PARMS(a) \ + ((struct vmmdev_hgcm_function_parameter *)( \ + (u8 *)(a) + sizeof(struct vbg_ioctl_hgcm_call))) +/* Get the pointer to the first HGCM parameter in a 32-bit
[PATCH resend v2 0/3] virt: Add vboxguest driver for Virtual Box Guest integration
Here is resend of v2 of my cleaned up version of the VirtualBox vboxguest driver, rebased on top of current the master from Linus. Note there currently is an issue with vboxvideo in the current master from Linus, this is fixed by this patch: https://patchwork.freedesktop.org/patch/189812/ Once this is merged, I will do some further cleanups on the vboxsf driver and also submit that upstream, if people want to test it before then, here is a version which applies on top of this series: https://github.com/jwrdegoede/linux-sunxi/commit/7f18b741945de3ae09ca8f1a9e48456ce32986c9 Changes in v2: -Change all uapi headers to kernel coding style: Drop struct and enum typedefs make type and struct-member names all lowercase, enum values all uppercase. -Remove unused struct type declarations from some headers (shaving of another 1000 lines) -Remove or fixup doxygen style comments -Get rid of CHECK macros, use a function taking in_ and out_size args instead -Some other small codyingstyle fixes -Split into multiple patches Here is (part of) the v1 cover-letter which is still relevant: VirtualBox upstream has declared the ioctl API for the /dev/vboxguest device as being stable now, so once this passes review this is ready for merging. I'm only submitting the vboxguest driver for now, as the vboxsf driver depends on this and it easier to first just get the vboxguest driver upstream. I've removed all depenencies on vbox's OS-independent runtime and the runtime itself, reducing the vboxguest driver from 10+ lines of code to aprox. 4300 lines. This reduces the non debug vboxguest.ko size from 450kB to less then 100 kB. I've also cleaned up various other warts such as doing hardware init in module_init rather then in a pci_probe callback. The vboxguest driver introduces a new userspace API + ABI in the form of ioctls on a character device. VirtualBox upstream not willing to commit to keeping this ABI stable was one of the things which has kept this driver driver out of mainline sofar. I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner from now on. Regards, Hans
Re: [PATCH 25/43] x86/mm/kaiser: Unmap kernel from userspace page tables (core patch)
* Dave Hansen wrote: > On 11/24/2017 04:16 AM, Peter Zijlstra wrote: > > On Fri, Nov 24, 2017 at 10:14:30AM +0100, Ingo Molnar wrote: > >> +The minimalistic kernel portion of the user page tables try to > >> +map only what is needed to enter/exit the kernel such as the > >> +entry/exit functions themselves and the interrupt descriptor > >> +table (IDT). > > > > There are a few unnecessary things that get mapped > >> +such as the first C function when entering an interrupt (see > >> +comments in kaiser.c). > > > > If I understood Andy's patches correctly, this should no longer be > > required. Is this text still correct? > > It is out of date. We were able to remove the irq handler mappings. I have updated the Documentation/x86/kaiser.txt file accordingly. Thanks, Ingo
Re: [PATCH 25/43] x86/mm/kaiser: Unmap kernel from userspace page tables (core patch)
* Peter Zijlstra wrote:
> On Fri, Nov 24, 2017 at 10:14:30AM +0100, Ingo Molnar wrote:
> > +static pte_t *kaiser_shadow_pagetable_walk(unsigned long address,
> > + unsigned long flags)
> > +{
> > + pte_t *pte;
> > + pmd_t *pmd;
> > + pud_t *pud;
> > + p4d_t *p4d;
> > + pgd_t *pgd = kernel_to_shadow_pgdp(pgd_offset_k(address));
> > + gfp_t gfp = (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
> > +
> > + if (flags & KAISER_WALK_ATOMIC) {
> > + gfp &= ~GFP_KERNEL;
> > + gfp |= __GFP_HIGH | __GFP_ATOMIC;
> > + }
> > +
> > + if (address < PAGE_OFFSET) {
> > + WARN_ONCE(1, "attempt to walk user address\n");
> > + return NULL;
> > + }
> > +
> > + if (pgd_none(*pgd)) {
> > + WARN_ONCE(1, "All shadow pgds should have been populated\n");
> > + return NULL;
> > + }
> > + BUILD_BUG_ON(pgd_large(*pgd) != 0);
> > +
> > + p4d = p4d_offset(pgd, address);
> > + BUILD_BUG_ON(p4d_large(*p4d) != 0);
> > + if (p4d_none(*p4d)) {
> > + unsigned long new_pud_page = __get_free_page(gfp);
> > + if (!new_pud_page)
> > + return NULL;
> > +
> > + spin_lock(&shadow_table_allocation_lock);
> > + if (p4d_none(*p4d))
> > + set_p4d(p4d, __p4d(_KERNPG_TABLE | __pa(new_pud_page)));
> > + else
> > + free_page(new_pud_page);
> > + spin_unlock(&shadow_table_allocation_lock);
>
> So mm/memory.c has two patterns here.. I prefer the other one:
>
> spin_lock(&shadow_table_allocation_lock);
> if (p4d_none(*p4d)) {
> set_p4d(p4d, __p4d(_KERNEL_TABLE | __pa(new_pud_page)));
> new_pud_page = NULL;
> }
> spin_unlock(&shadow_table_allocation_lock);
> if (new_pud_page)
> free_page(new_pud_page);
>
> > + }
Ok, would be nice to get this cleanup as a delta patch, because the existing
pattern has been tested to a fair degree already.
Thanks,
Ingo
Re: [PATCH 28/43] x86/mm/kaiser: Map cpu entry area
* Thomas Gleixner wrote:
> On Fri, 24 Nov 2017, Ingo Molnar wrote:
> > +void kaiser_add_mapping_cpu_entry(int cpu)
> > +{
> > + kaiser_add_user_map_early(get_cpu_gdt_ro(cpu), PAGE_SIZE,
> > + __PAGE_KERNEL_RO);
> > +
> > + /* includes the entry stack */
> > + kaiser_add_user_map_early(&get_cpu_entry_area(cpu)->tss,
> > + sizeof(get_cpu_entry_area(cpu)->tss),
> > + __PAGE_KERNEL | _PAGE_GLOBAL);
> > +
> > + /* Entry code, so needs to be EXEC */
> > + kaiser_add_user_map_early(&get_cpu_entry_area(cpu)->entry_trampoline,
> > +
> > sizeof(get_cpu_entry_area(cpu)->entry_trampoline),
> > + __PAGE_KERNEL_EXEC | _PAGE_GLOBAL);
>
> This creates a RWX mapping and wants to be __PAGE_KERNEL_RX!
So I think __PAGE_KERNEL_EXEC and __PAGE_KERNEL are really dangerous names
which
creates RWX mappings without people intending it.
Should be renamed to something like __PAGE_KERNEL_RWX ? And not be used
anywhere ...
Thanks,
Ingo
Re: [uml-devel] [PATCH] [RFC] um: Convert ubd driver to blk-mq
On 26/11/17 13:56, Richard Weinberger wrote:
> Anton,
>
> please don't crop the CC list.
Apologies, I wanted to keep the discussion UML side until we have come
up with something.
Will not do it again.
>
> Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
>> I need to do some reading on this.
>>
>> First of all - a stupid question: mq's primary advantage is in
>> multi-core systems as it improves io and core utilization. We are still
>> single-core in UML and AFAIK this is likely to stay that way, right?
> Well, someday blk-mq should completely replace the legacy block interface.
> Christoph asked me convert the UML driver.
> Also do find corner cases in blk-mq.
>
>> On 26/11/17 13:10, Richard Weinberger wrote:
>>> This is the first attempt to convert the UserModeLinux block driver
>>> (UBD) to blk-mq.
>>> While the conversion itself is rather trivial, a few questions
>>> popped up in my head. Maybe you can help me with them.
>>>
>>> MAX_SG is 64, used for blk_queue_max_segments(). This comes from
>>> a0044bdf60c2 ("uml: batch I/O requests"). Is this still a good/sane
>>> value for blk-mq?
>>>
>>> The driver does IO batching, for each request it issues many UML struct
>>> io_thread_req request to the IO thread on the host side.
>>> One io_thread_req per SG page.
>>> Before the conversion the driver used blk_end_request() to indicate that
>>> a part of the request is done.
>>> blk_mq_end_request() does not take a length parameter, therefore we can
>>> only mark the whole request as done. See the new is_last property on the
>>> driver.
>>> Maybe there is a way to partially end requests too in blk-mq?
>>>
>>> Another obstacle with IO batching is that UML IO thread requests can
>>> fail. Not only due to OOM, also because the pipe between the UML kernel
>>> process and the host IO thread can return EAGAIN.
>>> In this case the driver puts the request into a list and retried later
>>> again when the pipe turns writable.
>>> I’m not sure whether this restart logic makes sense with blk-mq, maybe
>>> there is a way in blk-mq to put back a (partial) request?
>> This all sounds to me as blk-mq requests need different inter-thread
>> IPC. We presently rely on the fact that each request to the IO thread is
>> fixed size and there is no natural request grouping coming from upper
>> layers.
>>
>> Unless I am missing something, this looks like we are now getting group
>> requests, right? We need to send a group at a time which is not
>> processed until the whole group has been received in the IO thread. We
>> cans still batch groups though, but should not batch individual
>> requests, right?
> The question is, do we really need batching at all with blk-mq?
> Jeff implemented that 10 years ago.
Well, but in that case we need to match our IPC to the existing batching
in the blck queue, right?
So my proposal still stands - I suggest we roll back my batching patch
which is no longer needed and change the IPC to match what is coming out
of blk-mq :)
>
>> My first step (before moving to mq) would have been to switch to a unix
>> domain socket pair probably using SOCK_SEQPACKET or SOCK_DGRAM. The
>> latter for a socket pair will return ENOBUF if you try to push more than
>> the receiving side can handle so we should not have IPC message loss.
>> This way, we can push request groups naturally instead of relying on a
>> "last" flag and keeping track of that for "end of request".
> The pipe is currently a socketpair. UML just calls it "pipe". :-(
I keep forgetting if we applied that patch or not :)
It was a pipe once upon a time and I suggested we change it socket pair
due to better buffering behavior for lots of small requests.
>
>> It will be easier to roll back the batching before we do that. Feel free
>> to roll back that commit.
>>
>> Once that is in, the whole batching will need to be redone as it should
>> account for variable IPC record size and use sendmmsg/recvmmsg pair -
>> same as in the vector IO. I am happy to do the honors on that one :)
> Let's see what block guys say.
Ack.
A.
>
> Thanks,
> //richard
>
Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance
On Thu, Nov 23, 2017 at 08:17:42PM +0530, Nayna Jain wrote: > Yeah, you are right, the first version of this patch sent all the > bytes together, but after hearing ddwg inputs, i.e. "The last byte was > introduced for error checking purposes (history).", I reverted back to > original to be safe. What does that mean ie error checking purposes? > It seems that the last byte was sent from the beginning (27084ef > [PATCH] tpm: driver for next generation TPM chips,), does anyone > remember the reason ? Sent from the beginning? /Jarkko
Re: [PATCH v6 01/11] intel_sgx: updated MAINTAINERS
On Sun, Nov 26, 2017 at 11:41:42AM +0100, Bjørn Mork wrote: > Joe Perches writes: > > On Sat, 2017-11-25 at 21:29 +0200, Jarkko Sakkinen wrote: > >> diff --git a/MAINTAINERS b/MAINTAINERS > > [] > >> @@ -14932,6 +14932,11 @@ L:linux...@kvack.org > >> S:Maintained > >> F:mm/zswap.c > >> > >> +INTEL SGX > >> +M:Jarkko Sakkinen > >> +L:intel-sgx-kernel-...@lists.01.org > >> +Q:https://patchwork.kernel.org/project/intel-sgx/list/ > > > > Alphabetical order please and this should > > have at least an "F:" pattern like: > > > > F: drivers/platform/x86/intel_sgx/ > > FYI: Darren already requested that when reviewing v5: > https://www.spinics.net/lists/kernel/msg2651743.html Joe, Bjørn, thank you for your feedback. I kind of left the MAINTAINERS update open because I wanted to get feedback who to add as reviewers and forgot to add "F:". I'll definitely fix this for v7. I'm sorry for ingoring it for v6. You might have noticed that v6 was not CC'd to mailing list defined in "M:". The reason for this is that I've lost the admin password for the ML so I could not reconfigure it (see tglx's complains for v5). I'll get this fixed early next week. /Jarkko
Re: regression: 4.13 cannot follow symlinks on some ext3 fs
On Sun, Nov 26, 2017 at 09:32:02AM +1100, Dave Chinner wrote: > > They don't have any whacky symlinks around, but the modern ext4 code > does try to eat these filesystems every so often. Extended operation > at ENOSPC will eventually corrupt the rootfs and crash the kernel, > and then I play the "e2fsck doesn't detect corruption, kernel does" > game to get them fixed up and working again If you have stack dumps or file system images which e2fsck doesn't detect any problems but the kernels do, please do feel free send reports to the ext4 mailing list. > I'm running with everything up to date (debian unstable) on these > VMs, they are just an old filesystem because some distros have had > reliable rolling updates for the entire life of these VMs. :P Or if you can make the VM's available and tell me how you are using/exercising them, I can try to see if I can repro the problem. I am wondering how you are running into ENOSPC on the root file systems; I take this is much more than running xfstests? Are you running some benchmarks that are logging into the root, and that's triggering the ENOSPC condition? Thanks, - Ted
Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
On Sun, Nov 26, 2017 at 5:48 AM, Ingo Molnar wrote:
>
> * Dave Hansen wrote:
>
>> On 11/10/2017 08:05 PM, Andy Lutomirski wrote:
>> > -struct tss_struct doublefault_tss __cacheline_aligned = {
>> > - .x86_tss = {
>> > - .sp0= STACK_START,
>> > - .ss0= __KERNEL_DS,
>> > - .ldt= 0,
>> ...
>> > +struct x86_hw_tss doublefault_tss __cacheline_aligned = {
>> > + .sp0= STACK_START,
>> > + .ss0= __KERNEL_DS,
>> > + .ldt= 0,
>> > + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
>>
>> FWIW, I really like the trend of renaming the hardware structures in
>> such a way that it's clear that they *are* hardware structures.
>>
>> It might also be nice to reference the relevant SDM sections on the
>> topic, or even to include a comment along the lines of how it get used.
>> This chunk from the SDM is particularly relevant:
>>
>> "The TSS holds information important to 64-bit mode and that is not
>> directly related to the task-switch mechanism."
>
> That makes sense - I've updated this patch with the following description
> added to
> struct x86_hw_tss:
I've folded this in along with all the reviews so far, and a few misc
fixes from Boris' review. I was planning to resend the whole series
today after I track down the kbuild error. Does that sound good?
Re: [PATCH v6 07/11] intel_sgx: ptrace() support
On Sat, Nov 25, 2017 at 09:29:24PM +0200, Jarkko Sakkinen wrote:
> + ptr = sgx_get_page(page->epc_page);
> + ret = __edbgrd((unsigned long)ptr + offset, data);
> + sgx_put_page(ptr);
> + if (ret) {
> + sgx_dbg(encl, "EDBGRD returned %d\n", ret);
~~
EDBGWR
/Jarkko
Re: [PATCH v6 07/11] intel_sgx: ptrace() support
On Sun, 2017-11-26 at 17:44 +0200, Jarkko Sakkinen wrote:
> On Sat, Nov 25, 2017 at 09:29:24PM +0200, Jarkko Sakkinen wrote:
> > + ptr = sgx_get_page(page->epc_page);
> > + ret = __edbgrd((unsigned long)ptr + offset, data);
^^
> > + sgx_put_page(ptr);
> > + if (ret) {
> > + sgx_dbg(encl, "EDBGRD returned %d\n", ret);
>~~
> EDBGWR
?
Re: [PATCH 24/43] x86/mm/kaiser: Mark per-cpu data structures required for entry/exit
* Thomas Gleixner wrote:
> On Fri, 24 Nov 2017, Ingo Molnar wrote:
> > diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
> > index aab4fe9f49f8..300090d1c209 100644
> > --- a/arch/x86/include/asm/desc.h
> > +++ b/arch/x86/include/asm/desc.h
> > @@ -46,7 +46,7 @@ struct gdt_page {
> > struct desc_struct gdt[GDT_ENTRIES];
> > } __attribute__((aligned(PAGE_SIZE)));
> >
> > -DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
> > +DECLARE_PER_CPU_PAGE_ALIGNED_USER_MAPPED(struct gdt_page, gdt_page);
>
> This patch is obsolete. We have the alias mappings in the cpu_entry_area
> already.
Gone in the latest WIP.x86/mm.
Thanks,
Ingo
Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
* Andy Lutomirski wrote:
> On Sun, Nov 26, 2017 at 5:48 AM, Ingo Molnar wrote:
> >
> > * Dave Hansen wrote:
> >
> >> On 11/10/2017 08:05 PM, Andy Lutomirski wrote:
> >> > -struct tss_struct doublefault_tss __cacheline_aligned = {
> >> > - .x86_tss = {
> >> > - .sp0= STACK_START,
> >> > - .ss0= __KERNEL_DS,
> >> > - .ldt= 0,
> >> ...
> >> > +struct x86_hw_tss doublefault_tss __cacheline_aligned = {
> >> > + .sp0= STACK_START,
> >> > + .ss0= __KERNEL_DS,
> >> > + .ldt= 0,
> >> > + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
> >>
> >> FWIW, I really like the trend of renaming the hardware structures in
> >> such a way that it's clear that they *are* hardware structures.
> >>
> >> It might also be nice to reference the relevant SDM sections on the
> >> topic, or even to include a comment along the lines of how it get used.
> >> This chunk from the SDM is particularly relevant:
> >>
> >> "The TSS holds information important to 64-bit mode and that is not
> >> directly related to the task-switch mechanism."
> >
> > That makes sense - I've updated this patch with the following description
> > added to
> > struct x86_hw_tss:
>
> I've folded this in along with all the reviews so far, and a few misc
> fixes from Boris' review. I was planning to resend the whole series
> today after I track down the kbuild error. Does that sound good?
Could you please do a delta to the very latest WIP.x86/mm instead?
In the latest I have included the review tags already, and all the easy-to-do
review feedback as well, so the delta should be rasonably small.
These entry bits are destined for x86/urgent real soon, so Thomas and me are
trying to pin the tree down and do delta changes only.
If it's a simple full interdiff between your latest and WIP.x86/mm that's fine
as
well, can backmerge everything accordingly.
Thanks,
Ingo
Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
* Ingo Molnar wrote: > Could you please do a delta to the very latest WIP.x86/mm instead? > > In the latest I have included the review tags already, and all the easy-to-do > review feedback as well, so the delta should be rasonably small. > > These entry bits are destined for x86/urgent real soon, so Thomas and me are > trying to pin the tree down and do delta changes only. > > If it's a simple full interdiff between your latest and WIP.x86/mm that's > fine as > well, can backmerge everything accordingly. Also feel free to include the two unwinder enhancements from you and Josh in the delta series (as two separate patches) - WIP.x86/mm won't change more today. Thanks, Ingo
Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
On Sun, Nov 26, 2017 at 8:00 AM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > >> Could you please do a delta to the very latest WIP.x86/mm instead? >> >> In the latest I have included the review tags already, and all the easy-to-do >> review feedback as well, so the delta should be rasonably small. >> >> These entry bits are destined for x86/urgent real soon, so Thomas and me are >> trying to pin the tree down and do delta changes only. >> >> If it's a simple full interdiff between your latest and WIP.x86/mm that's >> fine as >> well, can backmerge everything accordingly. > > Also feel free to include the two unwinder enhancements from you and Josh in > the > delta series (as two separate patches) - WIP.x86/mm won't change more today. I can do that. Or if you want to get testing going, you can just pick them up -- I'm not planning on touching either one of of them.
[PATCH] Removed Warning shown in checkpatch.pl for comment and white space
checkpatch.pl was showing warnings due to incorrected space at the end of line and also not using * at start of second comment line, Corrected the same and now there is zero warning Signed-off-by: Ashish Kalra --- drivers/bcma/driver_pcie2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c index b1a6e327cb23..cf889fc62ac7 100644 --- a/drivers/bcma/driver_pcie2.c +++ b/drivers/bcma/driver_pcie2.c @@ -83,7 +83,8 @@ static void bcma_core_pcie2_hw_ltr_war(struct bcma_drv_pcie2 *pcie2) bcma_core_pcie2_set_ltr_vals(pcie2); /* TODO: - si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */ +*si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); +*/ /* enable the LTR */ devstsctr2 |= PCIE2_CAP_DEVSTSCTRL2_LTRENAB; -- 2.14.1
[PATCH -next] fork.c: Move check of clone NEWIPC and SYSVSEM to copy_process
Currently this check for CLONE_NEWIPC with CLONE_SYSVSEM is done inside copy_namespaces, resulting in a handful of error paths being executed if these flags were used together. So, move this check to the beginning of copy_process, exiting earlier if the condition is true. This move is safe because copy_namespaces is called just from copy_process function. Signed-off-by: Marcos Paulo de Souza --- kernel/fork.c| 11 +++ kernel/nsproxy.c | 11 --- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 2113e252cb9d..691f9ba135fc 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1600,6 +1600,17 @@ static __latent_entropy struct task_struct *copy_process( return ERR_PTR(-EINVAL); /* +* CLONE_NEWIPC must detach from the undolist: after switching +* to a new ipc namespace, the semaphore arrays from the old +* namespace are unreachable. In clone parlance, CLONE_SYSVSEM +* means share undolist with parent, so we must forbid using +* it along with CLONE_NEWIPC. +*/ + if ((clone_flags & (CLONE_NEWIPC | CLONE_SYSVSEM)) == + (CLONE_NEWIPC | CLONE_SYSVSEM)) + return ERR_PTR(-EINVAL); + + /* * Thread groups must share signals as well, and detached threads * can only be started up within the thread group. */ diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c index f6c5d330059a..30882727dff5 100644 --- a/kernel/nsproxy.c +++ b/kernel/nsproxy.c @@ -151,17 +151,6 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk) if (!ns_capable(user_ns, CAP_SYS_ADMIN)) return -EPERM; - /* -* CLONE_NEWIPC must detach from the undolist: after switching -* to a new ipc namespace, the semaphore arrays from the old -* namespace are unreachable. In clone parlance, CLONE_SYSVSEM -* means share undolist with parent, so we must forbid using -* it along with CLONE_NEWIPC. -*/ - if ((flags & (CLONE_NEWIPC | CLONE_SYSVSEM)) == - (CLONE_NEWIPC | CLONE_SYSVSEM)) - return -EINVAL; - new_ns = create_new_namespaces(flags, tsk, user_ns, tsk->fs); if (IS_ERR(new_ns)) return PTR_ERR(new_ns); -- 2.13.6
[PATCH] mm: disable `vm.max_map_count' sysctl limit
The `vm.max_map_count' sysctl limit is IMO useless and confusing, so
this patch disables it.
- Old ELF had a limit of 64K segments, making core dumps from processes
with more mappings than that problematic, but that was fixed in March
2010 ("elf coredump: add extended numbering support").
- There are no internal data structures sized by this limit, making it
entirely artificial.
- When viewed as a limit on memory consumption, it is ineffective since
the number of mappings does not correspond directly to the amount of
memory consumed, since each mapping is variable-length.
- Reaching the limit causes various memory management system calls to
fail with ENOMEM, which is a lie. Combined with the unpredictability
of the number of mappings in a process, especially when non-trivial
memory management or heavy file mapping is used, it can be difficult
to reproduce these events and debug them. It's also confusing to get
ENOMEM when you know you have lots of free RAM.
This limit was apparently introduced in the 2.1.80 kernel (first as a
compile-time constant, later changed to a sysctl), but I haven't been
able to find any description for it in Git or the LKML archives, so I
don't know what the original motivation was.
I've kept the kernel tunable to not break the API towards user-space,
but it's a no-op now. Also the distinction between split_vma() and
__split_vma() disappears, so they are merged.
Tested on x86_64 with Fedora 26 user-space. Also built an ARM NOMMU
kernel to make sure NOMMU compiles and links cleanly.
Signed-off-by: Mikael Pettersson
---
Documentation/sysctl/vm.txt | 17 +-
Documentation/vm/ksm.txt | 4
Documentation/vm/remap_file_pages.txt | 4
fs/binfmt_elf.c | 4
include/linux/mm.h| 23 ---
kernel/sysctl.c | 3 +++
mm/madvise.c | 12 ++
mm/mmap.c | 42 ++-
mm/mremap.c | 7 --
mm/nommu.c| 3 ---
mm/util.c | 1 -
11 files changed, 13 insertions(+), 107 deletions(-)
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index b920423f88cb..0fcb511d07e6 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -35,7 +35,7 @@ Currently, these files are in /proc/sys/vm:
- laptop_mode
- legacy_va_layout
- lowmem_reserve_ratio
-- max_map_count
+- max_map_count (unused, kept for backwards compatibility)
- memory_failure_early_kill
- memory_failure_recovery
- min_free_kbytes
@@ -400,21 +400,6 @@ The minimum value is 1 (1/1 -> 100%).
==
-max_map_count:
-
-This file contains the maximum number of memory map areas a process
-may have. Memory map areas are used as a side-effect of calling
-malloc, directly by mmap, mprotect, and madvise, and also when loading
-shared libraries.
-
-While most applications need less than a thousand maps, certain
-programs, particularly malloc debuggers, may consume lots of them,
-e.g., up to one or two maps per allocation.
-
-The default value is 65536.
-
-=
-
memory_failure_early_kill:
Control how to kill processes when uncorrected memory error (typically
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt
index 6686bd267dc9..4a917f88cb11 100644
--- a/Documentation/vm/ksm.txt
+++ b/Documentation/vm/ksm.txt
@@ -38,10 +38,6 @@ the range for whenever the KSM daemon is started; even if
the range
cannot contain any pages which KSM could actually merge; even if
MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
-If a region of memory must be split into at least one new MADV_MERGEABLE
-or MADV_UNMERGEABLE region, the madvise may return ENOMEM if the process
-will exceed vm.max_map_count (see Documentation/sysctl/vm.txt).
-
Like other madvise calls, they are intended for use on mapped areas of
the user address space: they will report ENOMEM if the specified range
includes unmapped gaps (though working on the intervening mapped areas),
diff --git a/Documentation/vm/remap_file_pages.txt
b/Documentation/vm/remap_file_pages.txt
index f609142f406a..85985a89f05d 100644
--- a/Documentation/vm/remap_file_pages.txt
+++ b/Documentation/vm/remap_file_pages.txt
@@ -21,7 +21,3 @@ systems are widely available.
The syscall is deprecated and replaced it with an emulation now. The
emulation creates new VMAs instead of nonlinear mappings. It's going to
work slower for rare users of remap_file_pages() but ABI is preserved.
-
-One side effect of emulation (apart from performance) is that user can hit
-vm.max_map_count limit more easily due to additional VMAs. See comment for
-DEFAULT_MAX_MAP_COUNT for more details on the limit.
diff --git a/fs/binfmt_
Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)
On Wed, Nov 22, 2017 at 8:07 PM, Andy Lutomirski wrote:
> On Wed, Nov 22, 2017 at 4:34 PM, Dave Hansen
> wrote:
>>
>> These actions when dealing with a user address *and* the
>> PGD has _PAGE_USER set. That way, in-kernel users of low addresses
>> typically used by userspace are not accidentally poisoned.
>
> This seems sane.
>
>> +/*
>> + * Take a PGD location (pgdp) and a pgd value that needs
>> + * to be set there. Populates the shadow and returns
>> + * the resulting PGD that must be set in the kernel copy
>> + * of the page tables.
>> + */
>> +static inline pgd_t kaiser_set_shadow_pgd(pgd_t *pgdp, pgd_t pgd)
>> +{
>> +#ifdef CONFIG_KAISER
>> + if (pgd_userspace_access(pgd)) {
>> + if (pgdp_maps_userspace(pgdp)) {
>> + /*
>> +* The user/shadow page tables get the full
>> +* PGD, accessible from userspace:
>> +*/
>> + kernel_to_shadow_pgdp(pgdp)->pgd = pgd.pgd;
>> + /*
>> +* For the copy of the pgd that the kernel
>> +* uses, make it unusable to userspace. This
>> +* ensures if we get out to userspace with the
>> +* wrong CR3 value, userspace will crash
>> +* instead of running.
>> +*/
>> + pgd.pgd |= _PAGE_NX;
>> + }
>> + } else if (pgd_userspace_access(*pgdp)) {
>> + /*
>> +* We are clearing a _PAGE_USER PGD for which we
>> +* presumably populated the shadow. We must now
>> +* clear the shadow PGD entry.
>> +*/
>> + if (pgdp_maps_userspace(pgdp)) {
>> + kernel_to_shadow_pgdp(pgdp)->pgd = pgd.pgd;
>> + } else {
>> + /*
>> +* Attempted to clear a _PAGE_USER PGD which
>> +* is in the kernel porttion of the address
>> +* space. PGDs are pre-populated and we
>> +* never clear them.
>> +*/
>> + WARN_ON_ONCE(1);
>> + }
>> + } else {
>> + /*
>> +* _PAGE_USER was not set in either the PGD being set
>> +* or cleared. All kernel PGDs should be
>> +* pre-populated so this should never happen after
>> +* boot.
>> +*/
>> + }
>> +#endif
>> + /* return the copy of the PGD we want the kernel to use: */
>> + return pgd;
>> +}
>> +
>
> The more I read this code, the more I dislike "shadow". Shadow
> pagetables mean something specific in the virtualization world and,
> more importantly, the word "shadow" fails to convey *which* table it
> is. Unless I'm extra confused, mm->pgd points to the kernelmode
> tables. So can we replace the word "shadow" with "usermode"? That
> will also make the entry stuff way clearer. (Or I have it backwards,
> in which case "kernelmode" would be the right choice.) And rename the
> argument.
>
> That confusion aside, I'm trying to wrap my head around this. I think
> the description above makes sense, but I'm struggling to grok the code
> and how it matches the description. May I suggest an alternative
> implementation? (Apologies for epic whitespace damage.)
>
> /*
> * Install an entry into the usermode pgd. pgdp points to the kernelmode
> * entry whose usermode counterpart we're supposed to set. pgd is the
> * desired entry. Returns pgd, possibly modified if the actual entry
> installed
> * into the kernelmode needs different mode bits.
> */
> static inline pgd_t kaiser_set_usermode_pgd(pgd_t *pgdp, pgd_t pgd) {
> VM_BUG_ON(pgdp points to a usermode table);
>
> if (pgdp_maps_userspace(pgdp)) {
> /* Install the pgd as requested into the usermode tables. */
> kernelmode_to_usermode_pgdp(pgdp)->pgd = pgd.pgd;
>
> if (pgd_val(pgd) & _PAGE_USER) {
> /*
>* This is a normal user pgd -- the kernelmode mapping should have NX
>* set to prevent erroneous usermode execution with the kernel tables.
>*/
> return __pgd(pgd_val(pgd) | _PAGE_NX;
> } else {
> /* This is a weird mapping, e.g. EFI. Map it straight through. */
> return pgd;
> }
> } else {
> /*
> * We can get here due to vmalloc, a vmalloc fault, memory
> hot-add, or initial setup
> * of kernelmode page tables. Regardless of which particular code
> path we're in,
> * these mappings should not be automatically propagated to the
> usermode tables.
> */
> return pgd;
> }
> }
>
> As a side benefit, this shouldn't have magical interactions with the
> vsyscall page any more.
>
> Are there cases that this would get wrong?
>
Quick ping: did this get lost?
Greetings
I have important transaction for you, Please contact me with this email address: t_m...@aol.com, Regards Thomas
[PATCH] USB: serial: Correct return value on read
It's meaningless to return buf[0] on read. Because the caller of this interface checks the return value negative or not. Instead, we should return the result variable. Signed-off-by: Gimcuan Hui --- drivers/usb/serial/ark3116.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c index 3c544782f60b..bfdbc7164e7b 100644 --- a/drivers/usb/serial/ark3116.c +++ b/drivers/usb/serial/ark3116.c @@ -101,11 +101,9 @@ static int ark3116_read_reg(struct usb_serial *serial, reg, result); if (result >= 0) result = -EIO; - - return result; } - return buf[0]; + return result; } static inline int calc_divisor(int bps) -- 2.11.0
Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)
On 11/26/2017 08:10 AM, Andy Lutomirski wrote:
>> As a side benefit, this shouldn't have magical interactions with the
>> vsyscall page any more.
>>
>> Are there cases that this would get wrong?
>>
> Quick ping: did this get lost?
It does drop a warning that the other version of the code has, but
that's pretty minor.
Basically, we need two checks:
pgd_userspace_access() (aka _PAGE_USER) and
pgdp_maps_userspace()
The original code does pgd_userspace_access() in a top-level if and then
the pgdp_maps_userspace() checks at the second level. I think you are
basically suggesting that we flip that.
Logically, I'm sure we can make it work. It's just a matter of needing
to look at other things first.
BTW, this comment is, I think incorrect:
> if (pgdp_maps_userspace(pgdp)) {
...
> } else {
> /*
> * We can get here due to vmalloc, a vmalloc fault, memory
> hot-add, or initial setup
> * of kernelmode page tables. Regardless of which particular code
> path we're in,
> * these mappings should not be automatically propagated to the
> usermode tables.
> */
Since we pre-populated the entire kernel area's PGDs, I don't think
we'll ever have a valid reason to be doing a set_pgd() again on the
kernel area.
Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)
On Sun, Nov 26, 2017 at 8:24 AM, Dave Hansen
wrote:
> On 11/26/2017 08:10 AM, Andy Lutomirski wrote:
>>> As a side benefit, this shouldn't have magical interactions with the
>>> vsyscall page any more.
>>>
>>> Are there cases that this would get wrong?
>>>
>> Quick ping: did this get lost?
>
> It does drop a warning that the other version of the code has, but
> that's pretty minor.
>
> Basically, we need two checks:
>
> pgd_userspace_access() (aka _PAGE_USER) and
> pgdp_maps_userspace()
>
> The original code does pgd_userspace_access() in a top-level if and then
> the pgdp_maps_userspace() checks at the second level. I think you are
> basically suggesting that we flip that.
>
> Logically, I'm sure we can make it work. It's just a matter of needing
> to look at other things first.
>
> BTW, this comment is, I think incorrect:
>
>> if (pgdp_maps_userspace(pgdp)) {
> ...
>> } else {
>> /*
>> * We can get here due to vmalloc, a vmalloc fault, memory
>> hot-add, or initial setup
>> * of kernelmode page tables. Regardless of which particular code
>> path we're in,
>> * these mappings should not be automatically propagated to the
>> usermode tables.
>> */
>
> Since we pre-populated the entire kernel area's PGDs, I don't think
> we'll ever have a valid reason to be doing a set_pgd() again on the
> kernel area.
Right, forgot about that. So it's just initial setup, then.
Re: [PATCH v4 2/4] tpm: ignore burstcount to improve tpm_tis send() performance
[Cc'ing Dave and Leendeert] Hi Jarkko, > > It seems that the last byte was sent from the beginning (27084ef > > [PATCH] tpm: driver for next generation TPM chips,), does anyone > > remember the reason ? > > Sent from the beginning? I went through the commit logs to see if any of the patch descriptions have an explanation for sending the last byte separately. Based on commit 27084efee0c3 "[PATCH] tpm: driver for next generation TPM chips", it seems it's been there since the beginning. Dave, Leendert, Do either of you remember the reason for tpm_tis_send_data() sending the last byte separately? thanks, Mimi
[PATCH 1/2] KVM: x86: Store the microcode version in struct kvm_arch
... and read it from there when emulating accesses to
MSR_IA32_UCODE_REV. This is the first step to allow userspace to define
what's the microcode version that the guest should see.
Signed-off-by: Filippo Sironi
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1bfb99770c34..84b20139f4f1 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -776,6 +776,8 @@ struct kvm_arch {
struct mutex apic_map_lock;
struct kvm_apic_map *apic_map;
+ u32 microcode_version;
+
unsigned int tss_addr;
bool apic_access_page_done;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 34c85aa2e2d1..925c3e29cad3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2447,7 +2447,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
msr_info->data = 0;
break;
case MSR_IA32_UCODE_REV:
- msr_info->data = 0x1ULL;
+ msr_info->data = (u64)vcpu->kvm->arch.microcode_version << 32;
break;
case MSR_MTRRcap:
case 0x200 ... 0x2ff:
@@ -8121,6 +8121,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
if (type)
return -EINVAL;
+ kvm->arch.microcode_version = 0x1;
+
INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list);
INIT_LIST_HEAD(&kvm->arch.active_mmu_pages);
INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages);
--
2.7.4
[PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version
... that the guest should see.
Guest operating systems may check the microcode version to decide whether
to disable certain features that are known to be buggy up to certain
microcode versions. Address the issue by making the microcode version
that the guest should see settable.
The rationale for having userspace specifying the microcode version, rather
than having the kernel picking it, is to ensure consistency for live-migrated
instances; we don't want them to see a microcode version increase without a
reset.
Signed-off-by: Filippo Sironi
---
arch/x86/kvm/x86.c | 23 +++
include/uapi/linux/kvm.h | 3 +++
2 files changed, 26 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 925c3e29cad3..741588f27ebc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4033,6 +4033,29 @@ long kvm_arch_vm_ioctl(struct file *filp,
} u;
switch (ioctl) {
+ case KVM_GET_MICROCODE_VERSION: {
+ r = -EFAULT;
+ if (copy_to_user(argp,
+&kvm->arch.microcode_version,
+sizeof(kvm->arch.microcode_version)))
+ goto out;
+ break;
+ }
+ case KVM_SET_MICROCODE_VERSION: {
+ u32 microcode_version;
+
+ r = -EFAULT;
+ if (copy_from_user(µcode_version,
+ argp,
+ sizeof(microcode_version)))
+ goto out;
+ r = -EINVAL;
+ if (!microcode_version)
+ goto out;
+ kvm->arch.microcode_version = microcode_version;
+ r = 0;
+ break;
+ }
case KVM_SET_TSS_ADDR:
r = kvm_vm_ioctl_set_tss_addr(kvm, arg);
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 282d7613fce8..e11887758e29 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1192,6 +1192,9 @@ struct kvm_s390_ucas_mapping {
#define KVM_S390_UCAS_UNMAP _IOW(KVMIO, 0x51, struct
kvm_s390_ucas_mapping)
#define KVM_S390_VCPU_FAULT _IOW(KVMIO, 0x52, unsigned long)
+#define KVM_GET_MICROCODE_VERSION _IOR(KVMIO, 0x5e, __u32)
+#define KVM_SET_MICROCODE_VERSION _IOW(KVMIO, 0x5f, __u32)
+
/* Device model IOC */
#define KVM_CREATE_IRQCHIP_IO(KVMIO, 0x60)
#define KVM_IRQ_LINE _IOW(KVMIO, 0x61, struct kvm_irq_level)
--
2.7.4
Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
* Andy Lutomirski wrote: > On Sun, Nov 26, 2017 at 8:00 AM, Ingo Molnar wrote: > > > > * Ingo Molnar wrote: > > > >> Could you please do a delta to the very latest WIP.x86/mm instead? > >> > >> In the latest I have included the review tags already, and all the > >> easy-to-do > >> review feedback as well, so the delta should be rasonably small. > >> > >> These entry bits are destined for x86/urgent real soon, so Thomas and me > >> are > >> trying to pin the tree down and do delta changes only. > >> > >> If it's a simple full interdiff between your latest and WIP.x86/mm that's > >> fine as > >> well, can backmerge everything accordingly. > > > > Also feel free to include the two unwinder enhancements from you and Josh > > in the > > delta series (as two separate patches) - WIP.x86/mm won't change more today. > > I can do that. Or if you want to get testing going, you can just pick > them up -- I'm not planning on touching either one of of them. I was hoping for proper changelogs and SOBs for both of them ;-) Thanks, Ingo
Re: [PATCH v6 07/11] intel_sgx: ptrace() support
On Sun, Nov 26, 2017 at 07:50:05AM -0800, Joe Perches wrote:
> On Sun, 2017-11-26 at 17:44 +0200, Jarkko Sakkinen wrote:
> > On Sat, Nov 25, 2017 at 09:29:24PM +0200, Jarkko Sakkinen wrote:
> > > + ptr = sgx_get_page(page->epc_page);
> > > + ret = __edbgrd((unsigned long)ptr + offset, data);
> ^^
>
> > > + sgx_put_page(ptr);
> > > + if (ret) {
> > > + sgx_dbg(encl, "EDBGRD returned %d\n", ret);
> >~~
> >EDBGWR
>
> ?
D'oh I meant to quote this part:
ptr = sgx_get_page(page->epc_page);
ret = __edbgwr((unsigned long)ptr + offset, data);
sgx_put_page(ptr);
if (ret) {
sgx_dbg(encl, "EDBGRD returned %d\n", ret);
return -EFAULT;
}
There's a typo in sgx_dbg().
/Jarkko
Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line
On 25/11/17 10:51 PM, Julia Lawall wrote: > I don't understand at all the second sentence. Are you staying with the > same call, or moving on to other calls? Also, it would be the call that > is split over multiple lines, not the function split over multiple lines. Yes, you are correct it should be "call" instead of "function". > I think this would have been much easier with Cocccinelle where the code > is parsed and the control-flow graph is available to see whether there is > a pr_cont afterwards. But if it works, then it is surely good enough. I don't disagree at all. However, to my knowledge, not a lot of kernel developers run a set of coccinelle scripts on their change sets. The point is to catch these mistakes before the patch is submitted. Logan
Re: [PATCH v6 07/11] intel_sgx: ptrace() support
On Sat, Nov 25, 2017 at 09:29:24PM +0200, Jarkko Sakkinen wrote: > + offset = addr & PAGE_MASK; Should be addr & ~PAGE_MASK. Had fixup for this but it ended up not be squashed to the series :-( /Jarkko
Re: [PATCH v2 04/11] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
Hi Jacob,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20171124]
[cannot apply to rockchip/for-next v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jacob-Chen/Rockchip-ISP1-Driver/20171126-224713
base: git://linuxtv.org/media_tree.git master
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
>> drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:634:66: error: expected
>> identifier or '(' before '=' token
struct v4l2_async_notifier_operationsrockchip_mipidphy_async_ops = {
^
drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c: In function
'rockchip_mipidphy_media_init':
>> drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:707:24: error:
>> 'rockchip_mipidphy_async_ops' undeclared (first use in this function)
priv->notifier.ops = &rockchip_mipidphy_async_ops;
^~~
drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:707:24: note: each
undeclared identifier is reported only once for each function it appears in
At top level:
drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:593:1: warning:
'rockchip_mipidphy_notifier_complete' defined but not used [-Wunused-function]
rockchip_mipidphy_notifier_complete(struct v4l2_async_notifier *notifier)
^~~
drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:579:1: warning:
'rockchip_mipidphy_notifier_unbind' defined but not used [-Wunused-function]
rockchip_mipidphy_notifier_unbind(struct v4l2_async_notifier *notifier,
^
drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c:555:1: warning:
'rockchip_mipidphy_notifier_bound' defined but not used [-Wunused-function]
rockchip_mipidphy_notifier_bound(struct v4l2_async_notifier *notifier,
^~~~
vim +634 drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c
632
633 static const
> 634 struct v4l2_async_notifier_operationsrockchip_mipidphy_async_ops = {
635 .bound = rockchip_mipidphy_notifier_bound,
636 .unbind = rockchip_mipidphy_notifier_unbind,
637 .complete = rockchip_mipidphy_notifier_complete,
638 };
639
640 static int rockchip_mipidphy_fwnode_parse(struct device *dev,
641 struct v4l2_fwnode_endpoint *vep,
642 struct v4l2_async_subdev *asd)
643 {
644 struct sensor_async_subdev *s_asd =
645 container_of(asd, struct sensor_async_subdev,
asd);
646 struct v4l2_mbus_config *config = &s_asd->mbus;
647
648 if (vep->bus_type != V4L2_MBUS_CSI2) {
649 dev_err(dev, "Only CSI2 bus type is currently
supported\n");
650 return -EINVAL;
651 }
652
653 if (vep->base.port != 0) {
654 dev_err(dev, "The PHY has only port 0\n");
655 return -EINVAL;
656 }
657
658 config->type = V4L2_MBUS_CSI2;
659 config->flags = vep->bus.mipi_csi2.flags;
660 s_asd->lanes = vep->bus.mipi_csi2.num_data_lanes;
661
662 switch (vep->bus.mipi_csi2.num_data_lanes) {
663 case 1:
664 config->flags |= V4L2_MBUS_CSI2_1_LANE;
665 break;
666 case 2:
667 config->flags |= V4L2_MBUS_CSI2_2_LANE;
668 break;
669 case 3:
670 config->flags |= V4L2_MBUS_CSI2_3_LANE;
671 break;
672 case 4:
673 config->flags |= V4L2_MBUS_CSI2_4_LANE;
674 break;
675 default:
676 return -EINVAL;
677 }
678
679 return 0;
680 }
681
682 static int rockchip_mipidphy_media_init(struct mipidphy_priv *priv)
683 {
684 int ret;
685
686 priv->pads[MIPI_DPHY_SY_PAD_SOURCE].flags =
687 MEDIA_PAD_FL_SOURCE | MEDIA_PAD_FL_MUST_CONNECT;
688 priv->pads[MIPI_DPHY_SY_PAD_SINK].flags =
689 MEDIA_PAD_FL_SINK | MEDIA_PAD_FL_MUST_CONNEC
[PATCH v2] x86/orc: Don't bail on stack overflow
If we overflow the stack into a guard page and then try to unwind it
with ORC, it should work well: by construction, there can't be any
meaningful data in the guard page because no writes to the guard page
will have succeeded.
This patch fixes a bug that unwinding from working correctly: if the
starting register state has RSP pointing into a stack guard page, the
ORC unwinder bails out immediately. This patch fixes that: the ORC
unwinder will start the unwind.
I tested this by intentionally overflowing the task stack. The
result is an accurate call trace instead of a trace consisting
purely of '?' entries.
There are a few other bugs that are triggered if the unwinder
encounters a stack overflow after the first step, and Josh has WIP
patches to fix those as well.
Signed-off-by: Andy Lutomirski
---
Changes from v1: better changelog
I'm not going to send Josh's patch yet. He said he'd split it up
nicely, so I'll let him :)
arch/x86/kernel/unwind_orc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index a3f973b2c97a..7f6e3935666b 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -553,8 +553,18 @@ void __unwind_start(struct unwind_state *state, struct
task_struct *task,
}
if (get_stack_info((unsigned long *)state->sp, state->task,
- &state->stack_info, &state->stack_mask))
- return;
+ &state->stack_info, &state->stack_mask)) {
+ /*
+* We weren't on a valid stack. It's possible that
+* we overflowed a valid stack into a guard page.
+* See if the next page up is valid so that we can
+* generate some kind of backtrace if this happens.
+*/
+ void *next_page = (void *)PAGE_ALIGN((unsigned long)regs->sp);
+ if (get_stack_info(next_page, state->task, &state->stack_info,
+ &state->stack_mask))
+ return;
+ }
/*
* The caller can provide the address of the first frame directly
--
2.13.6
Linux 3.2.96
I'm announcing the release of the 3.2.96 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git The diff from 3.2.95 is attached to this message. Ben. Makefile| 2 +- arch/mips/ar7/clock.c | 3 + arch/mips/bcm63xx/clk.c | 3 + arch/powerpc/boot/4xx.c | 2 +- arch/powerpc/include/asm/ppc-opcode.h | 2 +- arch/powerpc/mm/hash_utils_64.c | 2 +- arch/x86/include/asm/elf.h | 5 +- arch/x86/kvm/svm.c | 1 + arch/x86/kvm/x86.c | 34 - block/blk-core.c| 2 +- drivers/ata/pata_amd.c | 1 + drivers/ata/pata_cs5536.c | 1 + drivers/base/bus.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc.c| 2 +- drivers/infiniband/core/verbs.c | 44 +- drivers/infiniband/hw/qib/qib_rc.c | 3 +- drivers/input/joystick/xpad.c | 218 drivers/input/serio/i8042-x86ia64io.h | 7 + drivers/input/tablet/gtco.c | 17 ++- drivers/media/rc/imon.c | 5 + drivers/media/video/cx231xx/cx231xx-cards.c | 2 +- drivers/media/video/em28xx/em28xx-audio.c | 2 +- drivers/media/video/uvc/uvc_ctrl.c | 7 + drivers/net/ethernet/mellanox/mlx4/fw.c | 2 +- drivers/net/usb/cdc_ether.c | 5 +- drivers/net/usb/smsc95xx.c | 11 +- drivers/pci/hotplug/shpchp_hpc.c| 2 + drivers/s390/scsi/zfcp_dbf.c| 31 +++- drivers/s390/scsi/zfcp_dbf.h| 13 +- drivers/s390/scsi/zfcp_fc.h | 6 +- drivers/s390/scsi/zfcp_fsf.c| 7 +- drivers/s390/scsi/zfcp_scsi.c | 16 +- drivers/scsi/aacraid/aachba.c | 48 +++--- drivers/scsi/mac_esp.c | 35 ++--- drivers/scsi/qla2xxx/qla_attr.c | 71 ++--- drivers/scsi/qla2xxx/qla_bsg.c | 12 +- drivers/scsi/qla2xxx/qla_def.h | 1 + drivers/scsi/qla2xxx/qla_os.c | 1 + drivers/staging/media/lirc/lirc_zilog.c | 8 +- drivers/usb/core/devio.c| 4 +- drivers/usb/core/quirks.c | 6 +- drivers/usb/serial/console.c| 1 + fs/dlm/user.c | 4 + fs/ext4/super.c | 9 ++ fs/fcntl.c | 13 +- fs/xfs/xfs_log.c| 7 - include/asm-generic/siginfo.h | 4 +- include/linux/pci_ids.h | 1 + include/linux/signal.h | 24 +-- kernel/irq/irqdesc.c| 24 +-- kernel/trace/trace_selftest.c | 2 +- mm/vmstat.c | 2 +- net/ipv6/ip6_fib.c | 17 ++- net/l2tp/l2tp_core.c| 38 +++-- net/l2tp/l2tp_core.h| 8 +- net/l2tp/l2tp_eth.c | 11 +- net/l2tp/l2tp_netlink.c | 8 +- net/l2tp/l2tp_ppp.c | 19 +-- net/mac80211/key.c | 38 - net/sctp/socket.c | 5 + 60 files changed, 631 insertions(+), 250 deletions(-) Aleksandr Bezzubikov (1): PCI: shpchp: Enable bridge bus mastering if MSI is enabled Amir Goldstein (1): xfs: fix incorrect log_flushed on fsync Andrey Korolyov (1): cs5536: add support for IDE controller variant Andy Lutomirski (1): x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps Arvind Yadav (1): media: imon: Fix null-ptr-deref in imon_probe Bart Van Assche (1): block: Relax a check in blk_start_queue() Ben Hutchings (2): mac80211: Fix null dereference in ieee80211_key_link() Linux 3.2.96 Benjamin Block (1): scsi: zfcp: add handling for FCP_RESID_OVER to the fcp ingress path Bjørn Mork (1): net: cdc_ether: fix divide by 0 on bad descriptors Brian King (1): scsi: aacraid: Fix command send race condition Cameron Gutman (2): Input: xpad - don't depend on endpoint order Input: xpad - validate USB endpoint type during probe Chad Dupuis (1): qla2xxx: Add mutex around optrom calls to serialize accesses. Christophe JAILLET (1): driver core: bus: Fix a potential double free Colin Ian King (1): media: em28xx: calculate left volume level correctly Dan Carpenter (2): scsi
Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line
On Sun, 26 Nov 2017, Logan Gunthorpe wrote: > > > On 25/11/17 10:51 PM, Julia Lawall wrote: > > I don't understand at all the second sentence. Are you staying with the > > same call, or moving on to other calls? Also, it would be the call that > > is split over multiple lines, not the function split over multiple lines. > > Yes, you are correct it should be "call" instead of "function". > > > I think this would have been much easier with Cocccinelle where the code > > is parsed and the control-flow graph is available to see whether there is > > a pr_cont afterwards. But if it works, then it is surely good enough. > > I don't disagree at all. However, to my knowledge, not a lot of kernel > developers run a set of coccinelle scripts on their change sets. The > point is to catch these mistakes before the patch is submitted. I don't know. In any case, a Coccinelle script would get run by the 0-day build testing service, which checks lots of trees. Perhaps both are useful, since Joe had some conerns about the amount of relevant context available in a patch. julia
Re: [PATCH] media: dvb_frontend: dvb_unregister_frontend must not call dvb_detach for fe->ops.release
Am Fri, 24 Nov 2017 15:02:30 +0100
schrieb Wolfgang Rohdewald :
> because ops.release was never dvb_attached.
> Which makes sense because f->ops.release does not attach anything.
>
> Now, rmmod dvb_usb_pctv452e correctly sets counters for
> stb6100/stb0899 to 0.
>
> Before, stb0899 got a counter -1, and for my 4 receivers I got 3
> OOPses like
>
> Nov 24 14:40:41 s5 kernel: [ 194.211014] WARNING: CPU: 6 PID: 3055 at
>module_put.part.45+0x132/0x1a0
> Call Trace:
> ? _stb0899_read_reg+0x100/0x100 [stb0899]
> ? _stb0899_read_reg+0x100/0x100 [stb0899]
> symbol_put_addr+0x38/0x60
> dvb_frontend_put+0x42/0x60 [dvb_core]
> ? stb0899_sleep+0x50/0x50 [stb0899]
> dvb_frontend_detach+0x7c/0x90 [dvb_core]
> dvb_usb_adapter_frontend_exit+0x57/0x80 [dvb_usb]
> dvb_usb_exit+0x39/0xb0 [dvb_usb]
> dvb_usb_device_exit+0x3f/0x60 [dvb_usb]
> pctv452e_usb_disconnect+0x6f/0x80 [dvb_usb_pctv452e]
> usb_unbind_interface+0x75/0x290
> ? _raw_spin_unlock_irqrestore+0x4a/0x80
> device_release_driver_internal+0x160/0x210
> driver_detach+0x40/0x80
> bus_remove_driver+0x5c/0xd0
> driver_unregister+0x2c/0x40
> usb_deregister+0x6c/0xf0
> pctv452e_usb_driver_exit+0x10/0xec0 [dvb_usb_pctv452e]
>
> Signed-off-by: Wolfgang Rohdewald
> ---
> drivers/media/dvb-core/dvb_frontend.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c index
> 9139d01ba7ed..c2cc794299c9 100644 ---
> a/drivers/media/dvb-core/dvb_frontend.c +++
> b/drivers/media/dvb-core/dvb_frontend.c @@ -150,7 +150,8 @@ static
> void __dvb_frontend_free(struct dvb_frontend *fe)
> dvb_free_device(fepriv->dvbdev);
>
> - dvb_frontend_invoke_release(fe, fe->ops.release);
> + if (fe->ops.release)
> + fe->ops.release(fe);
>
> kfree(fepriv);
> fe->frontend_priv = NULL;
FWIW, this patch breaks unloading for all DVB cards in my dev system,
in that attached drivers like demod and tuner drivers won't usecount
to zero anymore ("rmmod ddbridge" keeps the usecount of stv0367 and
cxd2841er up, and "rmmod budget_av" doesn't usecount the tda10023 back
to zero).
Best regards,
Daniel Scheller
--
https://github.com/herrnst
Xen PV breakage after IRQ stack code refactoring
Andy,
(Can't find the original patch in my mailbox)
This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
them NMI-safe")
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a9a8027..0d4483a 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -447,6 +447,59 @@ ENTRY(irq_entries_start)
.endr
END(irq_entries_start)
+.macro DEBUG_ENTRY_ASSERT_IRQS_OFF
+#ifdef CONFIG_DEBUG_ENTRY
+ pushfq
+ testl $X86_EFLAGS_IF, (%rsp)
+ jz .Lokay_\@
+ ud2
+.Lokay_\@:
+ addq $8, %rsp
+#endif
+.endm
+
makes Xen PV guests somewhat unhappy because IF flag will be set.
I was hoping to use ALTERNATIVE instruction but when we hit this for the
first time we haven't rewritten instructions yet. Moving check_bugs() a
bit higher helps but because this is common code I don't know how well
it will work on other architectures (and, in fact, whether it is even
safe on x86 in general, although that can be verified).
Another option is to also add a parameter to DEBUG_ENTRY_ASSERT_IRQS_OFF
(or to ENTER_IRQ_STACK) from xen_do_hypervisor_callback (which is where
the failure happens) but this looks pretty fragile in that it assumes
that xen_do_hypervisor_callback is the only place where we use this
codepath before alt instructions are set.
Any other suggestions?
-boris
Re: [PATCH] net: openvswitch: datapath: fix data type in queue_gso_packets
From: Willem de Bruijn
Date: Sat, 25 Nov 2017 16:15:01 -0500
> On Sat, Nov 25, 2017 at 2:14 PM, Gustavo A. R. Silva
> wrote:
>> gso_type is being used in binary AND operations together with SKB_GSO_UDP.
>> The issue is that variable gso_type is of type unsigned short and
>> SKB_GSO_UDP expands to more than 16 bits:
>>
>> SKB_GSO_UDP = 1 << 16
>>
>> this makes any binary AND operation between gso_type and SKB_GSO_UDP to
>> be always zero, hence making some code unreachable and likely causing
>> undesired behavior.
>>
>> Fix this by changing the data type of variable gso_type to unsigned int.
>>
>> Addresses-Coverity-ID: 1462223
>> Fixes: 0c19f846d582 ("net: accept UFO datagrams from tuntap and packet")
>> Signed-off-by: Gustavo A. R. Silva
>
> Acked-by: Willem de Bruijn
Applied and I'll queued this up with Willem's changes for -stable.
Thanks!
Re: [PATCH RFC] veth: make veth aware of gso buffer size
On Sat, 25 Nov 2017 13:26:52 -0800
Solio Sarabia wrote:
> GSO buffer size supported by underlying devices is not propagated to
> veth. In high-speed connections with hw TSO enabled, veth sends buffers
> bigger than lower device's maximum GSO, forcing sw TSO and increasing
> system CPU usage.
>
> Signed-off-by: Solio Sarabia
> ---
> Exposing gso_max_size via sysfs is not advised [0]. This patch queries
> available interfaces get this value. Reading dev_list is O(n), since it
> can be large (e.g. hundreds of containers), only a subset of interfaces
> is inspected. _Please_ advise pointers how to make veth aware of lower
> device's GSO value.
>
> In a test scenario with Hyper-V, Ubuntu VM, Docker inside VM, and NTttcp
> microworkload sending 40 Gbps from one container, this fix reduces 3x
> sender host CPU overhead, since now all TSO is done on physical NIC.
> Savings in CPU cycles benefit other use cases where veth is used, and
> the GSO buffer size is properly set.
>
> [0] https://lkml.org/lkml/2017/11/24/512
>
> drivers/net/veth.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index f5438d0..e255b51 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -298,6 +298,34 @@ static const struct net_device_ops veth_netdev_ops = {
> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
> NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
>
> +static void veth_set_gso(struct net_device *dev)
> +{
> + struct net_device *nd;
> + unsigned int size = GSO_MAX_SIZE;
> + u16 segs = GSO_MAX_SEGS;
> + unsigned int count = 0;
> + const unsigned int limit = 10;
> +
> + /* Set default gso based on available physical/synthetic devices,
> + * ignore virtual interfaces, and limit looping through dev_list
> + * as the total number of interfaces can be large.
> + */
> + read_lock(&dev_base_lock);
> + for_each_netdev(&init_net, nd) {
> + if (count >= limit)
> + break;
> + if (nd->dev.parent && nd->flags & IFF_UP) {
> + size = min(size, nd->gso_max_size);
> + segs = min(segs, nd->gso_max_segs);
> + }
> + count++;
> + }
> +
> + read_unlock(&dev_base_lock);
> + netif_set_gso_max_size(dev, size);
> + dev->gso_max_segs = size ? size - 1 : 0;
> +}
Thanks for looking for a solution.
Looking at the first 10 devices (including those not related to veth) is not
that
great a method. There maybe 100's of tunnels, and there is no guarantee of
ordering
in the device list. And what about network namespaces, looking in root namespace
is suspect as well.
The locking also looks wrong. veth_setup is called with RTNL held
(from __rtnl_link_register). Therefore acquiring dev_base_lock is not necessary.
Re: [PATCH] Removed Warning shown in checkpatch.pl for comment and white space
On Sun, Nov 26, 2017 at 09:35:50PM +0530, Ashish Kalra wrote: Hi Ashish, > checkpatch.pl was showing warnings due to incorrected space at the end > of line and also not using * at start of second comment line, Corrected > the same and now there is zero warning Your patch subject is incorrect in many ways : o It doesn't mention what driver you are cleaning. o Don't mention the tool you used in the subject, in fact I would run checkpatch.pl on your patch itself before sending. o Always write commit log in *imperative mood* Perhaps this might help you : https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes > Signed-off-by: Ashish Kalra > --- > drivers/bcma/driver_pcie2.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c > index b1a6e327cb23..cf889fc62ac7 100644 > --- a/drivers/bcma/driver_pcie2.c > +++ b/drivers/bcma/driver_pcie2.c > @@ -83,7 +83,8 @@ static void bcma_core_pcie2_hw_ltr_war(struct > bcma_drv_pcie2 *pcie2) > bcma_core_pcie2_set_ltr_vals(pcie2); > > /* TODO: > - si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); */ > + *si_core_wrapperreg(pcie2, 3, 0x60, 0x8080, 0); > + */ > > /* enable the LTR */ > devstsctr2 |= PCIE2_CAP_DEVSTSCTRL2_LTRENAB; > -- > 2.14.1 >
Re: [PATCH 12/43] x86/espfix/64: Stop assuming that pt_regs is on the entry stack
On Sun, Nov 26, 2017 at 03:05:33PM +0100, Ingo Molnar wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry_stack&id=6510485d026abdd144d170b1bc8508327acb5648 > > I have added Boris's reviewed-by tag: > > Reviewed-by: Borislav Petkov > > which I suspect applies now? Almost, looking at the patch at that URL, there's a trailing "modify" in the comment: +* we land directly at the #GP(0) vector with the stack already +* set up according to its expectations.modify ^^ which you can amend-remove. Other than that, it looks good! Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 14/43] x86/asm/64: Return to userspace from the trampoline stack
On Sun, Nov 26, 2017 at 03:18:47PM +0100, Ingo Molnar wrote: > Heh, indeed - if by 'future generations' you mean 'the guys who merge it, > a few months down the line'. ;-) ... and the poor souls who get to backport it and maybe even the guys who merged it, get to look at this after some time has passed by and then all of a sudden, they start scratching heads: "Why TF did we do that then? What were we thinking?" It happens even to the best of us. :-) And entry code is tricky as hell so hell yeah! to all the commenting. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v2 03/11] media: rkisp1: add rockchip isp1 driver
Hi Jacob, Thank you for the patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on next-20171124] [cannot apply to rockchip/for-next v4.14] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jacob-Chen/Rockchip-ISP1-Driver/20171126-224713 base: git://linuxtv.org/media_tree.git master config: mips-allmodconfig (attached as .config) compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=mips All error/warnings (new ones prefixed by >>): drivers/media//platform/rockchip/isp1/rkisp1.c: In function 'rkisp1_isp_sd_s_stream': >> drivers/media//platform/rockchip/isp1/rkisp1.c:136:6: warning: 'isp_ctrl' >> may be used uninitialized in this function [-Wmaybe-uninitialized] u32 isp_ctrl; ^~~~ >> drivers/media//platform/rockchip/isp1/rkisp1.c:209:2: warning: 'acq_mult' >> may be used uninitialized in this function [-Wmaybe-uninitialized] writel(acq_mult * in_frm->width, base + CIF_ISP_ACQ_H_SIZE); ^~~ drivers/media//platform/rockchip/isp1/rkisp1.c:139:6: note: 'acq_mult' was declared here u32 acq_mult; ^~~~ -- drivers/media//platform/rockchip/isp1/dev.c: In function 'rkisp1_runtime_suspend': drivers/media//platform/rockchip/isp1/dev.c:597:9: error: implicit declaration of function 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] return pinctrl_pm_select_sleep_state(dev); ^ drivers/media//platform/rockchip/isp1/dev.c: In function 'rkisp1_runtime_resume': >> drivers/media//platform/rockchip/isp1/dev.c:605:8: error: implicit >> declaration of function 'pinctrl_pm_select_default_state'; did you mean >> 'irq_set_default_host'? [-Werror=implicit-function-declaration] ret = pinctrl_pm_select_default_state(dev); ^~~ irq_set_default_host cc1: some warnings being treated as errors -- >> drivers/media//platform/rockchip/isp1/isp_params.c:1350:3: error: 'const >> struct v4l2_ioctl_ops' has no member named 'vidioc_enum_fmt_meta_out'; did >> you mean 'vidioc_enum_fmt_meta_cap'? .vidioc_enum_fmt_meta_out = rkisp1_params_enum_fmt_meta_out, ^~~~ vidioc_enum_fmt_meta_cap drivers/media//platform/rockchip/isp1/isp_params.c:1350:30: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .vidioc_enum_fmt_meta_out = rkisp1_params_enum_fmt_meta_out, ^~~ drivers/media//platform/rockchip/isp1/isp_params.c:1350:30: note: (near initialization for 'rkisp1_params_ioctl.vidioc_g_std') >> drivers/media//platform/rockchip/isp1/isp_params.c:1351:3: error: 'const >> struct v4l2_ioctl_ops' has no member named 'vidioc_g_fmt_meta_out'; did you >> mean 'vidioc_g_fmt_meta_cap'? .vidioc_g_fmt_meta_out = rkisp1_params_g_fmt_meta_out, ^ vidioc_g_fmt_meta_cap drivers/media//platform/rockchip/isp1/isp_params.c:1351:27: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .vidioc_g_fmt_meta_out = rkisp1_params_g_fmt_meta_out, ^~~~ drivers/media//platform/rockchip/isp1/isp_params.c:1351:27: note: (near initialization for 'rkisp1_params_ioctl.vidioc_s_std') >> drivers/media//platform/rockchip/isp1/isp_params.c:1352:3: error: 'const >> struct v4l2_ioctl_ops' has no member named 'vidioc_s_fmt_meta_out'; did you >> mean 'vidioc_s_fmt_meta_cap'? .vidioc_s_fmt_meta_out = rkisp1_params_g_fmt_meta_out, ^ vidioc_s_fmt_meta_cap drivers/media//platform/rockchip/isp1/isp_params.c:1352:27: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .vidioc_s_fmt_meta_out = rkisp1_params_g_fmt_meta_out, ^~~~ drivers/media//platform/rockchip/isp1/isp_params.c:1352:27: note: (near initialization for 'rkisp1_params_ioctl.vidioc_querystd') >> drivers/media//platform/rockchip/isp1/isp_params.c:1353:3: error: 'const >> struct v4l2_ioctl_ops' has no member named 'vid
Re: [PATCH v6 06/11] intel_sgx: driver for Intel Software Guard Extensions
> +struct sgx_encl_page {
> + unsigned long addr;
> + unsigned int flags;
> + void *epc_page;
> + struct sgx_va_page *va_page;
> + unsigned int va_offset;
> + struct list_head list;
> +};
This can be without major streches hoops packed way more. There are 12
bits free for use in the addr field. I can use low three bits for flags
and upper nine bits for va_offset.
I think I can also quite easily union epc_page and va_page fields.
With these changes the struct would shrink to:
struct sgx_encl_page {
unsigned long addr;
union {
void *epc_page;
struct sgx_va_page *va_page;
};
struct list_head list;
};
I can rework this for v7.
/Jarkko
Re: [PATCH v2] checkpatch: Add a warning for log messages that don't end in a new line
On 25/11/17 11:01 PM, Joe Perches wrote: > It doesn't really work. That's rather hyperbolic and I don't appreciate the tone. > Many of the messages aren't missing newlines. > > I only looked a the first few dozen instances, but many of > them aren't really missing newlines, but are now missing a > KERN_CONT annotation. True, and I mentioned that. However, these instances are still incorrect and deserve a warning. I don't see how any tool (even one written in Coccinelle) could determine whether the programmer intended to have a new line or intended for the next line to be a continuation. But if the developer gets a warning they'd at least look at it. Given that KERN_CONT usage is discouraged, I think warning that a new line is required is acceptable. > Most of that commit message is BS, but the net effect is > that now printks must have a KERN_ marker or a > newline is inserted before the format. Yes, that just means that all the instances that should be using KERN_CONT are now *actually* broken. It's also part of what created the mess in the first place as it makes the final new line seem to not be required. As a result, there are now plenty of places in the kernel that are inconsistent. That's why this patch is needed. > Also, this patch logic will be very confused by patch > blocks and not files. No, it's not. (With the exception of the false positives I noted due to KERN_CONTs not making it into the patch context.) I've tested this. I even created some pathological tests[1] to ensure crossing hunk boundaries and other weirdness works correctly. There may also be false negatives in extreme cases if the entire call site doesn't fit in the patch context but it's still better than nothing and will catch all newly added calls. So if you're going to make such statements I suggest you back it up with evidence. Logan [1] https://github.com/lsgunth/checkpatch-tests/blob/master/examples/test2.patch
