Re: [PATCH v2 1/2] x86/mm/KASLR: Fix the size of the direct mapping section
On 04/12/19 at 02:55pm, Baoquan He wrote:
> kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
> the maximum amount of system RAM supported. The size of the direct
> mapping section is obtained from the smaller one of the below two
> values:
>
> (actual system RAM size + padding size) vs (max system RAM size supported)
>
> This calculation is wrong since commit:
> b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52").
>
> In commit b83ce5ee91471d, __PHYSICAL_MASK_SHIFT was changed to be 52,
> regardless of whether it's using 4-level or 5-level page tables.
> It will always use 4 PB as the maximum amount of system RAM, even
> in 4-level paging mode where it should be 64 TB. Thus the size of
> the direct mapping section will always be the sum of the actual
> system RAM size plus the padding size.
>
> Even when the amount of system RAM is 64 TB, the following layout will
> still be used. Obviously KALSR will be weakened significantly.
>
>|___actual RAM___|_padding_|__the rest___ |
>064TB 74TB~120TB
~~ I could use tab, will resend to
correct this.
>
> What we want is the following:
>
>|___actual RAM___|_the rest___|
>064TB ~120TB
>
> So the code should use MAX_PHYSMEM_BITS instead. Fix it by replacing
> __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
>
> Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
> Acked-by: Kirill A. Shutemov
> Reviewed-by: Thomas Garnier
> Signed-off-by: Baoquan He
> ---
> arch/x86/mm/kaslr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> index 9a8756517504..387d4ed25d7c 100644
> --- a/arch/x86/mm/kaslr.c
> +++ b/arch/x86/mm/kaslr.c
> @@ -94,7 +94,7 @@ void __init kernel_randomize_memory(void)
> if (!kaslr_memory_enabled())
> return;
>
> - kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
> + kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
> kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
>
> /*
> --
> 2.17.2
>
Re: [PATCH] new flag COPY_FILE_RANGE_FILESIZE for copy_file_range()
On Sun, Apr 14, 2019 at 4:04 AM Darrick J. Wong wrote: > > On Sat, Apr 13, 2019 at 03:54:39PM -0500, Shawn Landden wrote: > > /me pulls out his close-reading glasses and the copy_file_range manpage... > > > If flags includes COPY_FILE_RANGE_FILESIZE then the length > > copied is the length of the file. off_in and off_out are > > ignored. len must be 0 or the file size. > > They're ignored? As in the copy operation reads the number of bytes in > the file referenced by fd_in from fd_in at its current position and is > writes that out to fd_out at its current position? I don't see why I > would want such an operation... > > ...but I can see how people could make use of a CFR_ENTIRE_FILE that > would check that both file descriptors are actually regular files, and > if so copy the entire contents of the fd_in file into the same position > in the fd_out file, and then set the fd_out file's length to match. If > @off_in or @off_out are non-NULL then they'll be updated to the new EOFs > if the copy completes succesfully and @len can be anything. > IDGI. In what way would that be helpful? Would the syscall fail if it cannot copy entire file (like clone_file_range) or return bytes copied? If latter, then user will have to call syscall again until getting 0 return value. User can already call copy_file_range with len=SSIZE_MAX and get almost the same thing. Unless the idea is to optimize for less syscalls for copying very large files?? In that case, MAX_RW_COUNT limit for this syscall would need to be relaxed. While on the subject, something that has been discussed in the past is that copy_file_range() and sendfile() of a large file are not killable, so that is that should be fixed, especially if the interface is going to be used to copy more data in-kernel. IOW, the motivation of the patch is not clear to me: > This implementation saves a call to stat() in the common case What is the real life workload where this micro optimization would have any affect? > It does not fix any race conditions, but that is possible in the future > with this interface. Then please present a plan or an implementation of how that interface can solve race conditions and if that is the only motivation for the interface than I do not see why we should merge the interface before the implementation. Please let me know if I am missing something. Thanks, Amir.
[PATCH v2 RESEND 0/2] x86/mm/KASLR: Fix the wrong size of memory sections
Resend: Fine tuning the patch log. v1->v2: Rewrite log of the two patches. No new code change. ~ v1 background: The fixes for these two bugs were carried in the earlier patchset, patch 4/6 and patch 5/6: [PATCH v4 0/6] Several patches to fix code bugs, improve documents and clean up http://lkml.kernel.org/r/20190314094645.4883-1-...@redhat.com Later, Thomas suggested posting bug fixing patches separately from those clean up patches. So send both of them in a separate patchset. For another bug fix patch 6/6, it happened on SGI UV system. Mike and Frank have sent a machine with cards to our lab and loaned to me, I am still debugging and discussing with Mike about the verification. Baoquan He (2): x86/mm/KASLR: Fix the size of the direct mapping section x86/mm/KASLR: Fix the size of vmemmap section arch/x86/mm/kaslr.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) -- 2.17.2
Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
On Sun, Apr 07, 2019 at 02:09:08PM -1000, Linus Torvalds wrote: > On Sun, Apr 7, 2019 at 10:04 AM Kirill Smelkov wrote: > > > > Fixing regression on FUSE side is my reason to do this whole work - > > that's why I care about it the most and ask. > > Yeah, we can do the actual FUSE fix, I think. Preferably through the > FUSE tree. Miklos? Linus, thanks for feedback. I'm not sure what is going on, but I'm afraid we can wait very long here. It's been already 1 week, and I was also struggling to get feedback from Miklos on my FUSE patches starting from end of February without any luck: https://lore.kernel.org/linux-fsdevel/cover.1553680185.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/12f7d0d98555ee0d174d04bb47644f65c07f035a.1553680185.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/d74b17b9d33c3dcc7a1f2fa2914fb3c4e7cda127.1553680185.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/cover.1553677194.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/d916d401a80e9834c95970d86ca71c0154e988a6.1553677194.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/e0b43507976d6ea9010f1bacaef067f18de49f1f.1553677194.git.k...@nexedi.com/ https://lore.kernel.org/linux-fsdevel/dc47c061f20c464ccf46b43822b062dca6486e90.1553637462.git.k...@nexedi.com/ I'm not sure what to do with my FUSE patches. It feels like knocking into closed door... Kirill
[PATCH v2 RESEND 1/2] x86/mm/KASLR: Fix the size of the direct mapping section
kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
the maximum amount of system RAM supported. The size of the direct
mapping section is obtained from the smaller one of the below two
values:
(actual system RAM size + padding size) vs (max system RAM size supported)
This calculation is wrong since commit:
b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52").
In commit b83ce5ee91471d, __PHYSICAL_MASK_SHIFT was changed to be 52,
regardless of whether it's using 4-level or 5-level page tables.
It will always use 4 PB as the maximum amount of system RAM, even
in 4-level paging mode where it should be 64 TB. Thus the size of
the direct mapping section will always be the sum of the actual
system RAM size plus the padding size.
Even when the amount of system RAM is 64 TB, the following layout will
still be used. Obviously KALSR will be weakened significantly.
||___actual RAM___|_padding_|__the rest___|
064TB~120TB
What we want is the following:
||___actual RAM___|_the rest__|
064TB~120TB
So the code should use MAX_PHYSMEM_BITS instead. Fix it by replacing
__PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
Acked-by: Kirill A. Shutemov
Reviewed-by: Thomas Garnier
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 9a8756517504..387d4ed25d7c 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -94,7 +94,7 @@ void __init kernel_randomize_memory(void)
if (!kaslr_memory_enabled())
return;
- kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT);
+ kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT);
kaslr_regions[1].size_tb = VMALLOC_SIZE_TB;
/*
--
2.17.2
[PATCH v2 RESEND 2/2] x86/mm/KASLR: Fix the size of vmemmap section
kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
the size of struct page is 64 Bytes, to support 4 PB system RAM in 5-level,
64 TB of vmemmap area is needed. The wrong hardcoding may cause vmemmap
stamping into the following cpu_entry_area section, if KASLR puts vmemmap
very close to cpu_entry_area, and the actual area of vmemmap is much bigger
than 1 TB.
So here calculate the actual size of vmemmap region, then align up to 1 TB
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this new methor,
the left space can be saved to join randomization to increase the entropy.
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 387d4ed25d7c..4679a0075048 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -52,7 +52,7 @@ static __initdata struct kaslr_memory_region {
} kaslr_regions[] = {
{ &page_offset_base, 0 },
{ &vmalloc_base, 0 },
- { &vmemmap_base, 1 },
+ { &vmemmap_base, 0 },
};
/* Get size in bytes used by the memory region */
@@ -78,6 +78,7 @@ void __init kernel_randomize_memory(void)
unsigned long rand, memory_tb;
struct rnd_state rand_state;
unsigned long remain_entropy;
+ unsigned long vmemmap_size;
vaddr_start = pgtable_l5_enabled() ? __PAGE_OFFSET_BASE_L5 :
__PAGE_OFFSET_BASE_L4;
vaddr = vaddr_start;
@@ -109,6 +110,14 @@ void __init kernel_randomize_memory(void)
if (memory_tb < kaslr_regions[0].size_tb)
kaslr_regions[0].size_tb = memory_tb;
+ /**
+* Calculate how many TB vmemmap region needs, and aligned to
+* 1TB boundary.
+*/
+ vmemmap_size = (kaslr_regions[0].size_tb << (TB_SHIFT - PAGE_SHIFT)) *
+ sizeof(struct page);
+ kaslr_regions[2].size_tb = DIV_ROUND_UP(vmemmap_size, 1UL << TB_SHIFT);
+
/* Calculate entropy available between regions */
remain_entropy = vaddr_end - vaddr_start;
for (i = 0; i < ARRAY_SIZE(kaslr_regions); i++)
--
2.17.2
drivers/iio/chemical/pms7003.c:315: undefined reference to `devm_iio_triggered_buffer_setup'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4443f8e6ac7755cd775c70d08be8042dc2f936cb
commit: a1d642266c147b9e34bd683bed1b7a935cdbfb8c iio: chemical: add support for
Plantower PMS7003 sensor
date: 9 weeks ago
config: x86_64-randconfig-s3-04141349 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout a1d642266c147b9e34bd683bed1b7a935cdbfb8c
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/iio/chemical/pms7003.o: In function `pms7003_probe':
>> drivers/iio/chemical/pms7003.c:315: undefined reference to
>> `devm_iio_triggered_buffer_setup'
vim +315 drivers/iio/chemical/pms7003.c
262
263 static int pms7003_probe(struct serdev_device *serdev)
264 {
265 struct pms7003_state *state;
266 struct iio_dev *indio_dev;
267 int ret;
268
269 indio_dev = devm_iio_device_alloc(&serdev->dev, sizeof(*state));
270 if (!indio_dev)
271 return -ENOMEM;
272
273 state = iio_priv(indio_dev);
274 serdev_device_set_drvdata(serdev, indio_dev);
275 state->serdev = serdev;
276 indio_dev->dev.parent = &serdev->dev;
277 indio_dev->info = &pms7003_info;
278 indio_dev->name = PMS7003_DRIVER_NAME;
279 indio_dev->channels = pms7003_channels,
280 indio_dev->num_channels = ARRAY_SIZE(pms7003_channels);
281 indio_dev->modes = INDIO_DIRECT_MODE;
282 indio_dev->available_scan_masks = pms7003_scan_masks;
283
284 mutex_init(&state->lock);
285 init_completion(&state->frame_ready);
286
287 serdev_device_set_client_ops(serdev, &pms7003_serdev_ops);
288 ret = devm_serdev_device_open(&serdev->dev, serdev);
289 if (ret)
290 return ret;
291
292 serdev_device_set_baudrate(serdev, 9600);
293 serdev_device_set_flow_control(serdev, false);
294
295 ret = serdev_device_set_parity(serdev, SERDEV_PARITY_NONE);
296 if (ret)
297 return ret;
298
299 ret = pms7003_do_cmd(state, CMD_WAKEUP);
300 if (ret) {
301 dev_err(&serdev->dev, "failed to wakeup sensor\n");
302 return ret;
303 }
304
305 ret = pms7003_do_cmd(state, CMD_ENTER_PASSIVE_MODE);
306 if (ret) {
307 dev_err(&serdev->dev, "failed to enter passive mode\n");
308 return ret;
309 }
310
311 ret = devm_add_action_or_reset(&serdev->dev, pms7003_stop,
state);
312 if (ret)
313 return ret;
314
> 315 ret = devm_iio_triggered_buffer_setup(&serdev->dev, indio_dev,
> NULL,
316pms7003_trigger_handler,
NULL);
317 if (ret)
318 return ret;
319
320 return devm_iio_device_register(&serdev->dev, indio_dev);
321 }
322
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RESEND PATCH 0/4] um: build and irq fixes
Am Donnerstag, 11. April 2019, 11:49:40 CEST schrieb Bartosz Golaszewski: > From: Bartosz Golaszewski > > Resending again - this time with tags collected. Queued for next merge window. Thanks, //richard
Re: INFO: task hung in do_exit
On Sat 2019-04-13 19:55:00, syzbot wrote: > syzbot has bisected this bug to: > > commit 430e48ecf31f4f897047f22e02abdfa75730cad8 > Author: Amitoj Kaur Chawla > Date: Thu Aug 10 16:28:09 2017 + > > leds: lm3533: constify attribute_group structure > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15f4cee320 > start commit: 8ee15f32 Merge tag 'dma-mapping-5.1-1' of git://git.infrad.. > git tree: upstream > final crash:https://syzkaller.appspot.com/x/report.txt?x=17f4cee320 Is there human around? Please take your bot on the leash, this is obviously bogus. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
WARNING: bad unlock balance in rcu_core
Hello,
syzbot found the following crash on:
HEAD commit:6d0a5984 Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15629ab720
kernel config: https://syzkaller.appspot.com/x/.config?x=4fb64439e07a1ec0
dashboard link: https://syzkaller.appspot.com/bug?extid=36baa6c2180e959e19b1
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+36baa6c2180e959e1...@syzkaller.appspotmail.com
=
WARNING: bad unlock balance detected!
5.1.0-rc4+ #66 Not tainted
-
syz-executor.1/17297 is trying to release lock (rcu_callback) at:
[] __write_once_size include/linux/compiler.h:220 [inline]
[] __rcu_reclaim kernel/rcu/rcu.h:226 [inline]
[] rcu_do_batch kernel/rcu/tree.c:2475 [inline]
[] invoke_rcu_callbacks kernel/rcu/tree.c:2788 [inline]
[] rcu_core+0x906/0x13a0 kernel/rcu/tree.c:2769
but there are no more locks to release!
other info that might help us debug this:
1 lock held by syz-executor.1/17297:
#0: 248f8dcd (&type->s_umount_key#59/1){+.+.}, at:
alloc_super+0x158/0x890 fs/super.c:228
stack backtrace:
CPU: 0 PID: 17297 Comm: syz-executor.1 Not tainted 5.1.0-rc4+ #66
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_unlock_imbalance_bug kernel/locking/lockdep.c:3754 [inline]
print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3731
__lock_release kernel/locking/lockdep.c:3970 [inline]
lock_release+0x67e/0xa00 kernel/locking/lockdep.c:4230
rcu_lock_release include/linux/rcupdate.h:215 [inline]
__rcu_reclaim kernel/rcu/rcu.h:228 [inline]
rcu_do_batch kernel/rcu/tree.c:2475 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2788 [inline]
rcu_core+0x92e/0x13a0 kernel/rcu/tree.c:2769
__do_softirq+0x266/0x95a kernel/softirq.c:293
invoke_softirq kernel/softirq.c:374 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:414
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:767
[inline]
RIP: 0010:console_unlock+0xb82/0xed0 kernel/printk/printk.c:2460
Code: 92 88 48 c1 e8 03 42 80 3c 30 00 0f 85 e4 02 00 00 48 83 3d 4f fa 37
07 00 0f 84 91 01 00 00 e8 84 f0 15 00 48 8b 7d 98 57 9d <0f> 1f 44 00 00
e9 6b ff ff ff e8 6f f0 15 00 48 8b 7d 08 c7 05 11
RSP: 0018:88805aa4f8d0 EFLAGS: 0212 ORIG_RAX: ff13
RAX: 0004 RBX: 0200 RCX: c90008209000
RDX: 000101de RSI: 815a9c2c RDI: 0212
RBP: 88805aa4f958 R08: 888099a66100 R09: fbfff11335b9
R10: fbfff11335b8 R11: 0001 R12:
R13: 84210cf0 R14: dc00 R15: 88f90710
vprintk_emit+0x280/0x6d0 kernel/printk/printk.c:1975
vprintk_default+0x28/0x30 kernel/printk/printk.c:2002
vprintk_func+0x7e/0x189 kernel/printk/printk_safe.c:398
printk+0xba/0xed kernel/printk/printk.c:2035
__ntfs_error.cold+0x91/0xc7 fs/ntfs/debug.c:103
ntfs_fill_super+0x2015/0x3150 fs/ntfs/super.c:2792
mount_bdev+0x307/0x3c0 fs/super.c:1346
ntfs_mount+0x35/0x40 fs/ntfs/super.c:3065
legacy_get_tree+0xf2/0x200 fs/fs_context.c:584
vfs_get_tree+0x123/0x450 fs/super.c:1481
do_new_mount fs/namespace.c:2622 [inline]
do_mount+0x1436/0x2c40 fs/namespace.c:2942
ksys_mount+0xdb/0x150 fs/namespace.c:3151
__do_sys_mount fs/namespace.c:3165 [inline]
__se_sys_mount fs/namespace.c:3162 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3162
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45b69a
Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 2d 8e fb ff c3 66 2e 0f
1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 0a 8e fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7f2f99d0ba88 EFLAGS: 0206 ORIG_RAX: 00a5
RAX: ffda RBX: 7f2f99d0bb40 RCX: 0045b69a
RDX: 7f2f99d0bae0 RSI: 2140 RDI: 7f2f99d0bb00
RBP: R08: 7f2f99d0bb40 R09: 7f2f99d0bae0
R10: R11: 0206 R12: 0008
R13: 004c7802 R14: 004dd850 R15:
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH 2/2] mtd: nandsim: switch to exec_op interface
On Sat, 13 Apr 2019 10:40:52 +0200
Richard Weinberger wrote:
> Stop using the legacy interface.
Thanks for converting the nandsim driver.
>
> Signed-off-by: Richard Weinberger
> ---
> drivers/mtd/nand/raw/nandsim.c | 78 --
> 1 file changed, 47 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
> index 3d80e2d23b6e..33c369f9a607 100644
> --- a/drivers/mtd/nand/raw/nandsim.c
> +++ b/drivers/mtd/nand/raw/nandsim.c
> @@ -299,6 +299,7 @@ union ns_mem {
> */
> struct nandsim {
> struct nand_chip chip;
> + struct nand_controller base;
> struct mtd_partition partitions[CONFIG_NANDSIM_MAX_PARTS];
> unsigned int nbparts;
>
> @@ -645,9 +646,6 @@ static int __init init_nandsim(struct mtd_info *mtd)
> return -EIO;
> }
>
> - /* Force mtd to not do delays */
> - chip->legacy.chip_delay = 0;
> -
> /* Initialize the NAND flash parameters */
> ns->busw = chip->options & NAND_BUSWIDTH_16 ? 16 : 8;
> ns->geom.totsz= mtd->size;
> @@ -2077,24 +2075,6 @@ static void ns_nand_write_byte(struct nand_chip *chip,
> u_char byte)
> return;
> }
>
> -static void ns_hwcontrol(struct nand_chip *chip, int cmd, unsigned int
> bitmask)
> -{
> - struct nandsim *ns = nand_get_controller_data(chip);
> -
> - ns->lines.cle = bitmask & NAND_CLE ? 1 : 0;
> - ns->lines.ale = bitmask & NAND_ALE ? 1 : 0;
> - ns->lines.ce = bitmask & NAND_NCE ? 1 : 0;
> -
> - if (cmd != NAND_CMD_NONE)
> - ns_nand_write_byte(chip, cmd);
> -}
> -
> -static int ns_device_ready(struct nand_chip *chip)
> -{
> - NS_DBG("device_ready\n");
> - return 1;
> -}
> -
> static void ns_nand_write_buf(struct nand_chip *chip, const u_char *buf,
> int len)
> {
> @@ -2146,7 +2126,7 @@ static void ns_nand_read_buf(struct nand_chip *chip,
> u_char *buf, int len)
> int i;
>
> for (i = 0; i < len; i++)
> - buf[i] = chip->legacy.read_byte(chip);
> + buf[i] = ns_nand_read_byte(chip);
>
> return;
> }
> @@ -2169,6 +2149,46 @@ static void ns_nand_read_buf(struct nand_chip *chip,
> u_char *buf, int len)
> return;
> }
>
> +static int ns_exec_op(struct nand_chip *chip, const struct nand_operation
> *op,
> + bool check_only)
> +{
> + int i;
> + unsigned int op_id;
> + const struct nand_op_instr *instr = NULL;
> + struct nandsim *ns = nand_get_controller_data(chip);
> +
> + ns->lines.ce = chip->cur_cs == -1 ? 0 : 1;
You can assume ns->lines.ce is always 1, since there's no point
executing a NAND operation if the CS pin is not asserted. BTW, in case
you ever consider supporting multi-CS chips, the CS line to select is
passed through op->cs (you should not use nand->cur_cs).
The rest of the patch looks good. Once this tiny detail is addressed you
can add
Reviewed-by: Boris Brezillon
> +
> + for (op_id = 0; op_id < op->ninstrs; op_id++) {
> + instr = &op->instrs[op_id];
> + ns->lines.cle = 0;
> + ns->lines.ale = 0;
> +
> + switch (instr->type) {
> + case NAND_OP_CMD_INSTR:
> + ns->lines.cle = 1;
> + ns_nand_write_byte(chip, instr->ctx.cmd.opcode);
> + break;
> + case NAND_OP_ADDR_INSTR:
> + ns->lines.ale = 1;
> + for (i = 0; i < instr->ctx.addr.naddrs; i++)
> + ns_nand_write_byte(chip,
> instr->ctx.addr.addrs[i]);
> + break;
> + case NAND_OP_DATA_IN_INSTR:
> + ns_nand_read_buf(chip, instr->ctx.data.buf.in,
> instr->ctx.data.len);
> + break;
> + case NAND_OP_DATA_OUT_INSTR:
> + ns_nand_write_buf(chip, instr->ctx.data.buf.out,
> instr->ctx.data.len);
> + break;
> + case NAND_OP_WAITRDY_INSTR:
> + /* we are always ready */
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int ns_attach_chip(struct nand_chip *chip)
> {
> unsigned int eccsteps, eccbytes;
> @@ -2209,6 +2229,7 @@ static int ns_attach_chip(struct nand_chip *chip)
>
> static const struct nand_controller_ops ns_controller_ops = {
> .attach_chip = ns_attach_chip,
> + .exec_op = ns_exec_op,
> };
>
> /*
> @@ -2234,14 +2255,6 @@ static int __init ns_init_module(void)
> nsmtd = nand_to_mtd(chip);
> nand_set_controller_data(chip, (void *)ns);
>
> - /*
> - * Register simulator's callbacks.
> - */
> - chip->legacy.cmd_ctrl= ns_hwcontrol;
> - chip->legacy.read_byte = ns_nand_read_byte;
> - chip->legacy.dev_ready = ns_device_ready;
> - chip->legacy.write_buf = ns_nand_writ
Re: [PATCH 1/2] mtd: nandsim: Embed struct nand_chip in struct nandsim
On Sat, 13 Apr 2019 10:40:51 +0200
Richard Weinberger wrote:
> We well need struct nand_controller soon, so more stuff need to
> be parts of struct nandsim.
> While we are here, rename "nand" to "ns" to use the same naming scheme
> everywhere in nandsim.
>
> Signed-off-by: Richard Weinberger
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/nand/raw/nandsim.c | 49 +-
> 1 file changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nandsim.c b/drivers/mtd/nand/raw/nandsim.c
> index 933d1a629c51..3d80e2d23b6e 100644
> --- a/drivers/mtd/nand/raw/nandsim.c
> +++ b/drivers/mtd/nand/raw/nandsim.c
> @@ -298,6 +298,7 @@ union ns_mem {
> * The structure which describes all the internal simulator data.
> */
> struct nandsim {
> + struct nand_chip chip;
> struct mtd_partition partitions[CONFIG_NANDSIM_MAX_PARTS];
> unsigned int nbparts;
>
> @@ -2216,7 +2217,7 @@ static const struct nand_controller_ops
> ns_controller_ops = {
> static int __init ns_init_module(void)
> {
> struct nand_chip *chip;
> - struct nandsim *nand;
> + struct nandsim *ns;
> int retval = -ENOMEM, i;
>
> if (bus_width != 8 && bus_width != 16) {
> @@ -2224,16 +2225,14 @@ static int __init ns_init_module(void)
> return -EINVAL;
> }
>
> - /* Allocate and initialize mtd_info, nand_chip and nandsim structures */
> - chip = kzalloc(sizeof(struct nand_chip) + sizeof(struct nandsim),
> -GFP_KERNEL);
> - if (!chip) {
> + ns = kzalloc(sizeof(struct nandsim), GFP_KERNEL);
> + if (!ns) {
> NS_ERR("unable to allocate core structures.\n");
> return -ENOMEM;
> }
> + chip= &ns->chip;
> nsmtd = nand_to_mtd(chip);
> - nand= (struct nandsim *)(chip + 1);
> - nand_set_controller_data(chip, (void *)nand);
> + nand_set_controller_data(chip, (void *)ns);
>
> /*
>* Register simulator's callbacks.
> @@ -2266,19 +2265,19 @@ static int __init ns_init_module(void)
>* the initial ID read command correctly
>*/
> if (id_bytes[6] != 0xFF || id_bytes[7] != 0xFF)
> - nand->geom.idbytes = 8;
> + ns->geom.idbytes = 8;
> else if (id_bytes[4] != 0xFF || id_bytes[5] != 0xFF)
> - nand->geom.idbytes = 6;
> + ns->geom.idbytes = 6;
> else if (id_bytes[2] != 0xFF || id_bytes[3] != 0xFF)
> - nand->geom.idbytes = 4;
> + ns->geom.idbytes = 4;
> else
> - nand->geom.idbytes = 2;
> - nand->regs.status = NS_STATUS_OK(nand);
> - nand->nxstate = STATE_UNKNOWN;
> - nand->options |= OPT_PAGE512; /* temporary value */
> - memcpy(nand->ids, id_bytes, sizeof(nand->ids));
> + ns->geom.idbytes = 2;
> + ns->regs.status = NS_STATUS_OK(ns);
> + ns->nxstate = STATE_UNKNOWN;
> + ns->options |= OPT_PAGE512; /* temporary value */
> + memcpy(ns->ids, id_bytes, sizeof(ns->ids));
> if (bus_width == 16) {
> - nand->busw = 16;
> + ns->busw = 16;
> chip->options |= NAND_BUSWIDTH_16;
> }
>
> @@ -2323,27 +2322,27 @@ static int __init ns_init_module(void)
> if ((retval = nand_create_bbt(chip)) != 0)
> goto err_exit;
>
> - if ((retval = parse_badblocks(nand, nsmtd)) != 0)
> + if ((retval = parse_badblocks(ns, nsmtd)) != 0)
> goto err_exit;
>
> /* Register NAND partitions */
> - retval = mtd_device_register(nsmtd, &nand->partitions[0],
> - nand->nbparts);
> + retval = mtd_device_register(nsmtd, &ns->partitions[0],
> + ns->nbparts);
> if (retval != 0)
> goto err_exit;
>
> - if ((retval = nandsim_debugfs_create(nand)) != 0)
> + if ((retval = nandsim_debugfs_create(ns)) != 0)
> goto err_exit;
>
> return 0;
>
> err_exit:
> - free_nandsim(nand);
> + free_nandsim(ns);
> nand_release(chip);
> - for (i = 0;i < ARRAY_SIZE(nand->partitions); ++i)
> - kfree(nand->partitions[i].name);
> + for (i = 0;i < ARRAY_SIZE(ns->partitions); ++i)
> + kfree(ns->partitions[i].name);
> error:
> - kfree(chip);
> + kfree(ns);
> free_lists();
>
> return retval;
> @@ -2364,7 +2363,7 @@ static void __exit ns_cleanup_module(void)
> nand_release(chip); /* Unregister driver */
> for (i = 0;i < ARRAY_SIZE(ns->partitions); ++i)
> kfree(ns->partitions[i].name);
> - kfree(mtd_to_nand(nsmtd));/* Free other structures */
> + kfree(ns);/* Free other structures */
> free_lists();
> }
>
Re: [PATCH] soundwire: cdns: Fix compilation error on arm64
On 04-04-19, 09:12, Jan Kotas wrote: > On arm64 the cadence_master.c file doesn't compile. > > readl and writel are undefined. > This patch fixes that by including io.h. And I cant verify that without hacking kconfig to force compile the lib. > > Signed-off-by: Jan Kotas > --- > drivers/soundwire/cadence_master.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/soundwire/cadence_master.c > b/drivers/soundwire/cadence_master.c > index cb6a331f4..0b5bcc209 100644 > --- a/drivers/soundwire/cadence_master.c > +++ b/drivers/soundwire/cadence_master.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include Why not add asm/io.h which is the header that actually defines readl/writel? > #include > #include > #include > -- > 2.15.0 -- ~Vinod
Re: [PATCH v3 2/5] soundwire: fix style issues
On 10-04-19, 22:16, Pierre-Louis Bossart wrote:
> Visual inspections confirmed by checkpatch.pl --strict expose a number
> of style issues, specifically parameter alignment is inconsistent as
> if different contributors used different styles. Before we restart
> support for SoundWire with Sound Open Firmware on Intel platforms,
> let's clean all this.
>
> Fix Kconfig help, spelling, SPDX format, alignment, spurious
> parentheses, bool comparisons to true/false, macro argument
> protection.
Thanks for the cleanup Pierre :)
>
> No new functionality added.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/Kconfig | 2 +-
> drivers/soundwire/bus.c| 87
> drivers/soundwire/bus.h| 16 +--
> drivers/soundwire/bus_type.c | 4 +-
> drivers/soundwire/cadence_master.c | 87
> drivers/soundwire/cadence_master.h | 22 ++--
> drivers/soundwire/intel.c | 87
> drivers/soundwire/intel.h | 4 +-
> drivers/soundwire/intel_init.c | 12 +--
> drivers/soundwire/mipi_disco.c | 116 +++--
> drivers/soundwire/slave.c | 10 +-
> drivers/soundwire/stream.c | 161 +++--
I would prefer this to be a patch per module. It doesnt help to have a
single patch for all the files!
It would be great to have cleanup done per logical group, for example
typos in a patch, aligns in another etc...
> 12 files changed, 313 insertions(+), 295 deletions(-)
>
> diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
> index 19c8efb9a5ee..84876a74874f 100644
> --- a/drivers/soundwire/Kconfig
> +++ b/drivers/soundwire/Kconfig
> @@ -4,7 +4,7 @@
>
> menuconfig SOUNDWIRE
> bool "SoundWire support"
> - ---help---
> + help
Not sure if this is a style issue, kernel seems to have 2990 instances
of this!
> if (msg->page)
> sdw_reset_page(bus, msg->dev_num);
> @@ -243,7 +244,7 @@ int sdw_transfer(struct sdw_bus *bus, struct sdw_msg *msg)
> * Caller needs to hold the msg_lock lock while calling this
> */
> int sdw_transfer_defer(struct sdw_bus *bus, struct sdw_msg *msg,
> - struct sdw_defer *defer)
> +struct sdw_defer *defer)
this does not seem aligned to me!
> int sdw_fill_msg(struct sdw_msg *msg, struct sdw_slave *slave,
> - u32 addr, size_t count, u16 dev_num, u8 flags, u8 *buf)
> + u32 addr, size_t count, u16 dev_num, u8 flags, u8 *buf)
this one too
> @@ -458,13 +458,13 @@ static int sdw_assign_device_num(struct sdw_slave
> *slave)
> mutex_unlock(&slave->bus->bus_lock);
> if (dev_num < 0) {
> dev_err(slave->bus->dev, "Get dev_num failed: %d",
> - dev_num);
> + dev_num);
It might read better if we move the log to second line along with
dev_num...
> int sdw_configure_dpn_intr(struct sdw_slave *slave,
> - int port, bool enable, int mask)
> +int port, bool enable, int mask)
not aligned
> void sdw_extract_slave_id(struct sdw_bus *bus,
> - u64 addr, struct sdw_slave_id *id);
> + u64 addr, struct sdw_slave_id *id);
>
Not aligned
> enum sdw_command_response
> cdns_xfer_msg_defer(struct sdw_bus *bus,
> - struct sdw_msg *msg, struct sdw_defer *defer)
> + struct sdw_msg *msg, struct sdw_defer *defer)
this one too..
> static int cdns_port_params(struct sdw_bus *bus,
> - struct sdw_port_params *p_params, unsigned int bank)
> + struct sdw_port_params *p_params, unsigned int bank)
here as well.. (and giving up on rest)
--
~Vinod
Re: bug disabling NX (noexec=off)
On Sat, 13 Apr 2019, Xose Vazquez Perez wrote: > [0.00] NX (Execute Disable) protection: disabled by kernel command > line option > [0.00] [ cut here ] > [0.00] attempted to set unsupported pgprot: 8163 bits: > 8000 supported: 7fff Does the below patch fix it for you? Thanks, tglx 8< diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 0029604af8a4..dd73d5d74393 100644 --- a/arch/x86/mm/ioremap.c +++ b/arch/x86/mm/ioremap.c @@ -825,7 +825,7 @@ void __init __early_set_fixmap(enum fixed_addresses idx, pte = early_ioremap_pte(addr); /* Sanitize 'prot' against any unsupported bits: */ - pgprot_val(flags) &= __default_kernel_pte_mask; + pgprot_val(flags) &= __supported_pte_mask; if (pgprot_val(flags)) set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
Re: [PATCH v3 0/5] soundwire: code cleanup
On 10-04-19, 22:16, Pierre-Louis Bossart wrote: > SoundWire support will be provided in Linux with the Sound Open > Firmware (SOF) on Intel platforms. Before we start adding the missing > pieces, there are a number of warnings and style issues reported by > checkpatch, cppcheck and Coccinelle that need to be cleaned-up. Applied, 1, 3 and 4 (5 looked good but didnt apply) Thanks > > Changes since v2: > fixed inversion of devm_kcalloc parameters, detected while rebasing > additional patches. > > Changes since v1: > added missing newlines in new patch (suggested by Joe Perches) > > Pierre-Louis Bossart (5): > soundwire: intel: fix inversion in devm_kcalloc parameters > soundwire: fix style issues > soundwire: bus: remove useless initializations > soundwire: stream: remove useless initialization of local variable > soundwire: add missing newlines in dynamic debug logs > > drivers/soundwire/Kconfig | 2 +- > drivers/soundwire/bus.c| 137 --- > drivers/soundwire/bus.h| 16 +- > drivers/soundwire/bus_type.c | 4 +- > drivers/soundwire/cadence_master.c | 99 +-- > drivers/soundwire/cadence_master.h | 22 +-- > drivers/soundwire/intel.c | 103 ++- > drivers/soundwire/intel.h | 4 +- > drivers/soundwire/intel_init.c | 12 +- > drivers/soundwire/mipi_disco.c | 116 +++-- > drivers/soundwire/slave.c | 10 +- > drivers/soundwire/stream.c | 267 +++-- > 12 files changed, 404 insertions(+), 388 deletions(-) > > -- > 2.17.1 -- ~Vinod
Re: [PATCH 0/2] soundwire: fix Kconfig select/depend issues
On 11-04-19, 14:28, Pierre-Louis Bossart wrote: > 0-day/Kbuild starts complaining about missed module dependencies and > compilation issues. Since codecs and soc drivers need to be compilable > independently, let's fix this using the following model: I have not seen a build report on this one, is this some internal Intel report or on upstream tree? > SOUNDWIRE_INTEL select --- > | > v > REGMAP_SOUNDWIRE --- select ---> SOUNDWIRE_BUS > > > Pierre-Louis Bossart (2): > regmap: soundwire: fix Kconfig select/depend issue > soundwire: fix SOUNDWIRE_BUS option > > drivers/base/regmap/Kconfig | 3 ++- > drivers/soundwire/Kconfig | 1 - > 2 files changed, 2 insertions(+), 2 deletions(-) > > -- > 2.17.1 -- ~Vinod
How are you beautiful
I hope you had a lovely night, and you having a wonderful weekend.It is my pleasure meeting you. Am sorry to bother you, i apologize for intruding upon your privacy. My name is Wesley. I`m from the State. I am currently looking for a relationship in which I feel loved. I hope you will be kind enough to tell me more about yourself, if you don't mind. I`ll be anticipating for your kind reply. I wish you a awesome day and perfect mood. With respect, Wesley.
Re: [alsa-devel] [PATCH 1/2] regmap: soundwire: fix Kconfig select/depend issue
On 12-04-19, 16:21, Takashi Iwai wrote: > On Fri, 12 Apr 2019 16:18:41 +0200, > Mark Brown wrote: > > > > On Fri, Apr 12, 2019 at 09:07:41AM -0500, Pierre-Louis Bossart wrote: > > > > > config CODEC_XYX_SDW > > >tristate "XYZ SDW Codec" > > > depends on SOUNDWIRE > > > select REGMAP_SOUNDWIRE > > > > That looks good. > > > > > config REGMAP_SOUNDWIRE > > > select SOUNDWIRE_BUS > > > > > it'd follow the typical pattern seen in sound/soc/codecs/Kconfig: > > > > IIRC the select here won't actually do anything. > > I thought it'd do select SOUNDWIRE_BUS. The depends-on here would be > ignored instead. yeah this all is bit complicated and should not be so. As Srini pointed out, we have two symbols, SOUNDWIRE as a menuconfig item which enables the subsystem and then SOUNDWIRE_BUS which compiles in the code. Unfortunately I dont seem to recall the advantages of this approach so it might be easier to drop SOUNDWIRE_BUS and then let codecs do select REGMAP_SOUNDWIRE and depends on SOUNDWIRE Thanks -- ~Vinod
Re: [PATCH] soundwire: intel: fix implicit header use of module.h/export.h
On 13-04-19, 11:12, Paul Gortmaker wrote: > These two files are implicitly relying on an instance of including > module.h from . > > Ideally, header files under include/linux shouldn't be adding > includes of other headers, in anticipation of their consumers, > but just the headers needed for the header itself to pass > parsing with CPP. > > The module.h is particularly bad in this sense, as it itself does > include a whole bunch of other headers, due to the complexity of > module support. > > Here, we make those includes explicit, in order to allow a future > removal of module.h from linux/acpi.h without causing build breakage. Applied, thanks -- ~Vinod
Re: [alsa-devel] [PATCH] soundwire: fix pm_runtime_get_sync return code checks
On 08-04-19, 12:43, Pierre-Louis Bossart wrote:
>
>
> On 4/8/19 2:12 AM, Jan Kotas wrote:
> >
> >
> > > On 5 Apr 2019, at 17:04, Pierre-Louis Bossart
> > > wrote:
> > >
> > > On 4/5/19 2:26 AM, Jan Kotas wrote:
> > > >
> > > > ret = pm_runtime_get_sync(slave->bus->dev);
> > > > - if (ret < 0)
> > > > + if (ret < 0 && ret != -EACCES)
> > > >
> > > There was a patch submitted on 3/28 by Srinivas Kandagatla who suggested
> > > an alternate solution for exactly the same code.
> > >
> > > + if (pm_runtime_enabled(slave->bus->dev)) {
> > > + ret = pm_runtime_get_sync(slave->bus->dev);
> > > + if (ret < 0)
> > > + return ret;
> > >
> > > I am far from an expert on pm_runtime but Srinivas' solution looks more
> > > elegant to me.
> >
> > Hello Pierre,
> >
> > Please take a look at this patch, that was my inspiration:
> > https://lists.linuxfoundation.org/pipermail/linux-pm/2011-June/031930.html
>
> The two patches seems to be identical:
>
> static inline bool pm_runtime_enabled(struct device *dev)
> {
> return !dev->power.disable_depth;
> }
>
> static int rpm_resume()
> [...]
> else if (dev->power.disable_depth > 0)
> retval = -EACCES;
>
>
> However I am still not clear on why this might fail.
>
> I can only think of one possible explanation: there is no explicit
> pm_runtime_enable() in the soundwire code, so maybe the expectation is that
> the pm_runtime status is inherited from the parent (in the intel case the
> PCI driver), and that's missing in non-intel configurations?
IIRC that needs to be called by the Intel driver and those patches were
not upstreamed. So we dont have fully supported PM on upstream yet!
>
> > I also took a look, and it seems the value returned by
> > pm_runtime_get_syncis simply ignored in a lot of places,
> > so checking its value may be excessive.
> But not checking seems careless at best...
--
~Vinod
Re: [PATCH v2 1/4] iio: inkern: API for reading available iio channel attribute values
On Sun, 24 Mar 2019 15:27:25 +
Jonathan Cameron wrote:
> On Sat, 23 Mar 2019 18:28:06 +0100
> Artur Rojek wrote:
>
> > Extend the inkern API with a function for reading available
> > attribute values of iio channels.
> >
> > Signed-off-by: Artur Rojek
> If this goes through a route other than IIO (otherwise
> I'll just add a signed-off-by...)
>
> Acked-by: Jonathan Cameron
Applied to the ib-jz47xx-prereq branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
I'll merge that into the togreg branch as well shortly.
Thanks,
Jonathan
>
> > ---
> >
> > Changes:
> >
> > v2: no change
> >
> > drivers/iio/inkern.c | 20
> > include/linux/iio/consumer.h | 14 ++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> > index 06ca3f7fcc44..f19dbde3c945 100644
> > --- a/drivers/iio/inkern.c
> > +++ b/drivers/iio/inkern.c
> > @@ -733,6 +733,26 @@ static int iio_channel_read_avail(struct iio_channel
> > *chan,
> > vals, type, length, info);
> > }
> >
> > +int iio_read_avail_channel_attribute(struct iio_channel *chan,
> > +const int **vals, int *type, int *length,
> > +enum iio_chan_info_enum attribute)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&chan->indio_dev->info_exist_lock);
> > + if (!chan->indio_dev->info) {
> > + ret = -ENODEV;
> > + goto err_unlock;
> > + }
> > +
> > + ret = iio_channel_read_avail(chan, vals, type, length, attribute);
> > +err_unlock:
> > + mutex_unlock(&chan->indio_dev->info_exist_lock);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(iio_read_avail_channel_attribute);
> > +
> > int iio_read_avail_channel_raw(struct iio_channel *chan,
> >const int **vals, int *length)
> > {
> > diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
> > index 9887f4f8e2a8..b2d34831ed7c 100644
> > --- a/include/linux/iio/consumer.h
> > +++ b/include/linux/iio/consumer.h
> > @@ -290,6 +290,20 @@ int iio_read_max_channel_raw(struct iio_channel *chan,
> > int *val);
> > int iio_read_avail_channel_raw(struct iio_channel *chan,
> >const int **vals, int *length);
> >
> > +/**
> > + * iio_read_avail_channel_attribute() - read available channel attribute
> > values
> > + * @chan: The channel being queried.
> > + * @vals: Available values read back.
> > + * @type: Type of values read back.
> > + * @length:Number of entries in vals.
> > + * @attribute: info attribute to be read back.
> > + *
> > + * Returns an error code, IIO_AVAIL_RANGE or IIO_AVAIL_LIST.
> > + */
> > +int iio_read_avail_channel_attribute(struct iio_channel *chan,
> > +const int **vals, int *type, int *length,
> > +enum iio_chan_info_enum attribute);
> > +
> > /**
> > * iio_get_channel_type() - get the type of a channel
> > * @channel: The channel being queried.
>
Re: [PATCH v2 2/4] iio: inkern: Convert iio_read_avail_channel_raw into a wrapper
On Sun, 24 Mar 2019 15:27:50 +
Jonathan Cameron wrote:
> On Sat, 23 Mar 2019 18:28:07 +0100
> Artur Rojek wrote:
>
> > Convert "iio_read_avail_channel_raw" over to a wrapper around
> > "iio_read_avail_channel_attribute".
> >
> > With the introduction of "iio_read_avail_channel_attribute",
> > the necessity of having a separate call to read raw channel values
> > became redundant.
> >
> > Signed-off-by: Artur Rojek
> Acked-by: Jonathan Cameron
Applied to the ib-jz47xx-battery-prereq branch of iio.git
Thanks,
Jonathan
>
> > ---
> >
> > Changes:
> >
> > v2: new patch
> >
> > drivers/iio/inkern.c | 12 ++--
> > 1 file changed, 2 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> > index f19dbde3c945..4a5eff3f18bc 100644
> > --- a/drivers/iio/inkern.c
> > +++ b/drivers/iio/inkern.c
> > @@ -759,16 +759,8 @@ int iio_read_avail_channel_raw(struct iio_channel
> > *chan,
> > int ret;
> > int type;
> >
> > - mutex_lock(&chan->indio_dev->info_exist_lock);
> > - if (!chan->indio_dev->info) {
> > - ret = -ENODEV;
> > - goto err_unlock;
> > - }
> > -
> > - ret = iio_channel_read_avail(chan,
> > -vals, &type, length, IIO_CHAN_INFO_RAW);
> > -err_unlock:
> > - mutex_unlock(&chan->indio_dev->info_exist_lock);
> > + ret = iio_read_avail_channel_attribute(chan, vals, &type, length,
> > +IIO_CHAN_INFO_RAW);
> >
> > if (ret >= 0 && type != IIO_VAL_INT)
> > /* raw values are assumed to be IIO_VAL_INT */
>
Re: [PATCH 1/3] x86/vdso: Remove unused 'mask' member
On Thu, 11 Apr 2019, Huw Davies wrote: > The 'mask' member of struct vsyscall_gtod_data is unused, so remove > it. Its use was removed in commit a51e996d48ac (x86/vdso: Enforce > 64bit clocksource). That's true, but we are moving the VDSO to generic code, so the mask will stay. Thanks, tglx
Re: [PATCH v2 4/4] power: supply: add Ingenic JZ47xx battery driver.
On Sun, 7 Apr 2019 18:52:34 +0200
Sebastian Reichel wrote:
> Hi,
>
> On Sun, Mar 24, 2019 at 03:31:37PM +, Jonathan Cameron wrote:
> > On Sat, 23 Mar 2019 18:28:09 +0100
> > Artur Rojek wrote:
> >
> > > Add a driver for battery present on Ingenic JZ47xx SoCs.
> > >
> > > Signed-off-by: Artur Rojek
> > The IIO parts look fine to me.
> > Reviewed-by: Jonathan Cameron
> >
> > Sebastian, assuming you are happy with this version,
>
> The driver itself looks ok. I'm a bit unhappy, that we already have
> jz4740-battery. This driver is much cleaner, but does not yet seem
> to be ready to replace it. Artur Rojek what are your plans regarding
> to the existing driver? Is there currently work going on migrating
> JZ47xx to DT?
>
> > do you have any preference for how we handle this series?
> >
> > Probably needs one of us to do an immutable branch with just this
> > in it. I'm happy to do so once all the relevant Acks etc are in
> > place, but don't mind if you want to!
>
> I suppose you could provide an immutable branch with just the first
> two patches in it. Then I can pull it and apply the power-supply
> patches on top.
Done. ib-jz47xx-battery-prereq branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
which is based on v5.0
I'll pull that into the togreg branch of iio.git shortly.
Thanks,
Jonathan
>
> -- Sebastian
>
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > >
> > > Changes:
> > >
> > > v2: - rework the return logic in ingenic_battery_get_property,
> > > - make index offsets point forward in ingenic_battery_set_scale,
> > > - fix spacing around scale_raw[best_idx + 1]
> > >
> > > drivers/power/supply/Kconfig | 11 ++
> > > drivers/power/supply/Makefile | 1 +
> > > drivers/power/supply/ingenic-battery.c | 180 +
> > > 3 files changed, 192 insertions(+)
> > > create mode 100644 drivers/power/supply/ingenic-battery.c
> > >
> > > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> > > index e901b9879e7e..9bfb1637ec28 100644
> > > --- a/drivers/power/supply/Kconfig
> > > +++ b/drivers/power/supply/Kconfig
> > > @@ -169,6 +169,17 @@ config BATTERY_COLLIE
> > > Say Y to enable support for the battery on the Sharp Zaurus
> > > SL-5500 (collie) models.
> > >
> > > +config BATTERY_INGENIC
> > > + tristate "Ingenic JZ47xx SoCs battery driver"
> > > + depends on MIPS || COMPILE_TEST
> > > + depends on INGENIC_ADC
> > > + help
> > > + Choose this option if you want to monitor battery status on
> > > + Ingenic JZ47xx SoC based devices.
> > > +
> > > + This driver can also be built as a module. If so, the module will be
> > > + called ingenic-battery.
> > > +
> > > config BATTERY_IPAQ_MICRO
> > > tristate "iPAQ Atmel Micro ASIC battery driver"
> > > depends on MFD_IPAQ_MICRO
> > > diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> > > index b731c2a9b695..9e2c481d0187 100644
> > > --- a/drivers/power/supply/Makefile
> > > +++ b/drivers/power/supply/Makefile
> > > @@ -34,6 +34,7 @@ obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
> > > obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
> > > obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
> > > obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
> > > +obj-$(CONFIG_BATTERY_INGENIC)+= ingenic-battery.o
> > > obj-$(CONFIG_BATTERY_IPAQ_MICRO) += ipaq_micro_battery.o
> > > obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
> > > obj-$(CONFIG_BATTERY_SBS)+= sbs-battery.o
> > > diff --git a/drivers/power/supply/ingenic-battery.c
> > > b/drivers/power/supply/ingenic-battery.c
> > > new file mode 100644
> > > index ..822aee1c7b64
> > > --- /dev/null
> > > +++ b/drivers/power/supply/ingenic-battery.c
> > > @@ -0,0 +1,180 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Battery driver for the Ingenic JZ47xx SoCs
> > > + * Copyright (c) 2019 Artur Rojek
> > > + *
> > > + * based on drivers/power/supply/jz4740-battery.c
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +struct ingenic_battery {
> > > + struct device *dev;
> > > + struct iio_channel *channel;
> > > + struct power_supply_desc desc;
> > > + struct power_supply *battery;
> > > + struct power_supply_battery_info info;
> > > +};
> > > +
> > > +static int ingenic_battery_get_property(struct power_supply *psy,
> > > + enum power_supply_property psp,
> > > + union power_supply_propval *val)
> > > +{
> > > + struct ingenic_battery *bat = power_supply_get_drvdata(psy);
> > > + struct power_supply_battery_info *info = &bat->info;
> > > + int ret;
> > > +
> > > + switch (psp) {
> > > + case POWER_SUPPLY_PROP_HEALTH:
> > > + ret = iio_read_channel_processed(bat->channel, &val->intval);
> > > + val->intval *= 1000;
> > > + if
Re: [PATCH v2] iio: imu: mpu6050: Fix FIFO layout for ICM20602
On Mon, 8 Apr 2019 14:32:00 +
Jean-Baptiste Maneyrol wrote:
> Hello,
>
> overall looks good for me.
>
> I would just prefer to change the define name for temperature to
> INV_ICM20602_SCAN_TEMP. It is the chip temperature that can be used for
> temperature compensation for both accel and gyro data.
>
> But it is really just a details.
>
> Best regards,
> Jean-Baptiste Maneyrol
Rather than go around again, I've made the change and applied the
patch to the fixes-togreg branch of iio.git. I also added a
fixes tag.
Thanks,
Jonathan
>
>
> From: Jonathan Cameron
> Sent: Sunday, April 7, 2019 13:45
> To: stev...@skydio.com
> Cc: Jean-Baptiste Maneyrol; Hartmut Knaack; Lars-Peter Clausen; Peter
> Meerwald-Stadler; Martin Kelly; Jonathan Marek; Brian Masney; Randolph
> Maaßen; Douglas Fischer; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2] iio: imu: mpu6050: Fix FIFO layout for ICM20602
> Â
> Â CAUTION: This email originated from outside of the organization. Please make
> sure the sender is who they say they are and do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
> On Tue, 2 Apr 2019 23:28:56 -0700
> stev...@skydio.com wrote:
>
> > From: Steve Moskovchenko
> >
> > The MPU6050 driver has recently gained support for the
> > ICM20602 IMU, which is very similar to MPU6xxx. However,
> > the ICM20602's FIFO data specifically includes temperature
> > readings, which were not present on MPU6xxx parts. As a
> > result, the driver will under-read the ICM20602's FIFO
> > register, causing the same (partial) sample to be returned
> > for all reads, until the FIFO overflows.
> >
> > Fix this by adding a table of scan elements specifically
> > for the ICM20602, which takes the extra temperature data
> > into consideration.
> >
> > While we're at it, fix the temperature offset and scaling
> > on ICM20602, since it uses different scale/offset constants
> > than the rest of the MPU6xxx devices.
> >
> > Signed-off-by: Steve Moskovchenko
> I'd like a reviewed-by or acked-by from Jean-Baptiste on this before
> I take it.
>
> thanks,
>
> Jonathan
>
> > ---
> > v2: Read temperature when running in accel-only mode, too.
> >
> >Â drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 46 --
> > drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 20 +-
> >Â drivers/iio/imu/inv_mpu6050/inv_mpu_ring.c |Â 3 ++
> >Â 3 files changed, 64 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > index 650de0fefb7b..fedd3f2b0135 100644
> > --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> > @@ -471,7 +471,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
> >Â Â Â return IIO_VAL_INT_PLUS_MICRO;
> >Â Â Â case IIO_TEMP:
> >Â Â Â *val = 0;
> > - *val2 = INV_MPU6050_TEMP_SCALE;
> > + if (st->chip_type == INV_ICM20602)
> > + *val2 = INV_ICM20602_TEMP_SCALE;
> > + else
> > + *val2 = INV_MPU6050_TEMP_SCALE;
> >Â
> >Â Â Â return IIO_VAL_INT_PLUS_MICRO;
> >Â Â Â default:
> > @@ -480,7 +483,10 @@ inv_mpu6050_read_raw(struct iio_dev *indio_dev,
> >Â Â Â case IIO_CHAN_INFO_OFFSET:
> >Â Â Â switch (chan->type) {
> >Â Â Â case IIO_TEMP:
> > - *val = INV_MPU6050_TEMP_OFFSET;
> > + if (st->chip_type == INV_ICM20602)
> > + *val = INV_ICM20602_TEMP_OFFSET;
> > + else
> > + *val = INV_MPU6050_TEMP_OFFSET;
> >Â
> >Â Â Â return IIO_VAL_INT;
> >Â Â Â default:
> > @@ -845,6 +851,32 @@ static const struct iio_chan_spec inv_mpu_channels[] =
> > {
> >Â Â Â INV_MPU6050_CHAN(IIO_ACCEL, IIO_MOD_Z, INV_MPU6050_SCAN_ACCL_Z),
> >Â };
> >Â
> > +static const struct iio_chan_spec inv_icm20602_channels[] = {
> > + IIO_CHAN_SOFT_TIMESTAMP(INV_ICM20602_SCAN_TIMESTAMP),
> > + {
> > + .type = IIO_TEMP,
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
> > + | BIT(IIO_CHAN_INFO_OFFSET)
> > + | BIT(IIO_CHAN_INFO_SCALE),
> > + .scan_index = INV_ICM20602_SCAN_GYRO_TEMP,
> > + .scan_type = {
> > + .sign = 's',
> > + .realbits = 16,
> > + .storagebits = 16,
> > + .shift = 0,
> > + .endianness = IIO_BE,
> > +Â },
> > + },
> > +
> > + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_X, INV_ICM20602_SCAN_GYRO_X),
> > + INV_MPU6050_CHAN(IIO_ANGL_VEL, IIO_MOD_Y, INV_ICM20602_SCAN_GYRO_Y),
>
Kconfig dependency issue on function-graph tracer and frame pointer on arm
Hello,
Recently, Naresh reported that the function-graph tracer on the latest
kernel crashes on arm. I could reproduce it and bisected. I finally found
the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
was the first bad commit.
Actually, this commit is just changing Kconfig for making kernel unwinder
choosable. However, as a side effect, this makes CONFIG_FRAME_POINTER=n
by default even if CONFIG_FUNCTION_GRAPH_TRACER=y.
(Note that function-graph tracer implementation on arm depends on
FRAME_POINTER.)
This seems odd, because the commit introduced below code
+choice
+ prompt "Choose kernel unwinder"
+ default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
+ default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
+ help
So, it seems UNWINDER_FRAME_POINTER is used if FUNCTION_GRAPH_TRACER=y.
However, it seems not working. (I guess this is a wrong syntax for Kconfig)
Moreover, since this just setting default value, there seems no direct
dependency to FRAME_POINTER from FUNCTION_GRAPH_TRACER. I guess user can
change it...
I made a fix below (which I tested). This is ugly (arch specific dependency
in generic part) but works.
It enables both of FRAME_POINTER and UNWINDER_ARM.
However I still have some questions.
- Is above choice+default a correct syntax for Kconfig? (Masahiro?)
- Can UNWINDER_ARM work with FRAME_POINTER? (Arnd?)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 5e3de28c7677..f79c54680f3b 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -160,6 +160,7 @@ config FUNCTION_GRAPH_TRACER
depends on HAVE_FUNCTION_GRAPH_TRACER
depends on FUNCTION_TRACER
depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE
+ select ARCH_WANT_FRAME_POINTERS if ARM
default y
help
Enable the kernel to trace a function at both its return
Thank you,
--
Masami Hiramatsu
Re: [PATCH 2/3] x86/vdso: Allow clock specific mult and shift values
On Thu, 11 Apr 2019, Huw Davies wrote:
CC+: Vincenzo Frascino who is working on the generic VDSO.
> This will allow clocks with different mult and shift values,
> e.g. CLOCK_MONOTONIC_RAW, to be supported in the vDSO.
>
> The coarse clocks do not require these data so the values are not
> copied for these clocks.
>
> One could add potential new values of mult and shift alongside the
> existing values in struct vsyscall_gtod_data, but it seems more
> natural to group them with the actual clock data in the basetime array
> at the expense of a few more cycles in update_vsyscall().
The few cycles are one thing. Did you verify that this does not change the
cache layout for CLOCK_MONOTONIC and CLOCK_REALTIME? Let's look:
> struct vgtod_ts {
> u64 sec;
> u64 nsec;
> + u32 mult;
> + u32 shift;
> };
>
> #define VGTOD_BASES (CLOCK_TAI + 1)
> @@ -40,8 +42,6 @@ struct vsyscall_gtod_data {
>
> int vclock_mode;
> u64 cycle_last;
> - u32 mult;
> - u32 shift;
>
> struct vgtod_ts basetime[VGTOD_BASES];
The current state is:
struct vsyscall_gtod_data {
unsigned int seq; /* 0 4 */
intvclock_mode; /* 4 4 */
u64cycle_last; /* 8 8 */
u64mask; /*16 8 */
u32mult; /*24 4 */
u32shift;/*28 4 */
struct vgtod_tsbasetime[12]; /*32 192 */
basetime[CLOCK_REALTIME] 32 .. 47
basetime[CLOCK_MONOTONIC]48 .. 63
So with your change it looks like this:
struct vsyscall_gtod_data {
unsigned int seq; /* 0 4 */
intvclock_mode; /* 4 4 */
u64cycle_last; /* 8 8 */
struct vgtod_tsbasetime[12]; /*16 288 */
which makes
basetime[CLOCK_REALTIME] 16 .. 39
basetime[CLOCK_MONOTONIC]40 .. 63
So it stays in the same cache line, but as we move the VDSO to generic
code, the mask field needs to stay and this will make basetime[CLOCK_MONOTONIC]
overlap into the next cache line.
See
https://lkml.kernel.org/r/alpine.deb.2.21.1902231727060.1...@nanos.tec.linutronix.de
for an alternate solution to this problem, which avoids this and just gives
CLOCK_MONOTONIC_RAW a separate storage space alltogether.
Thanks,
tglx
Re: WARNING in kvm_arch_vcpu_ioctl_run (3)
syzbot has bisected this bug to:
commit 706249c222f68471b6f8e9e8e9b77665c404b226
Author: Peter Zijlstra
Date: Fri Jul 24 13:06:37 2015 +
locking/static_keys: Rework update logic
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=175cc58720
start commit: 1d2ba7fe Merge tag 'fbdev-v4.19-rc7' of https://github.com..
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=14dcc58720
console output: https://syzkaller.appspot.com/x/log.txt?x=10dcc58720
kernel config: https://syzkaller.appspot.com/x/.config?x=c0af03fe452b65fb
dashboard link: https://syzkaller.appspot.com/bug?extid=760a73552f47a8cd0fd9
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=156ad23140
Reported-by: syzbot+760a73552f47a8cd0...@syzkaller.appspotmail.com
Fixes: 706249c222f6 ("locking/static_keys: Rework update logic")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
RE: [EXT] Re: [PATCHv5 4/6] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: 2019年4月12日 22:01
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: [EXT] Re: [PATCHv5 4/6] PCI: mobiveil: Add PCIe Gen4 RC driver for
> NXP Layerscape SoCs
>
> WARNING: This email was created outside of NXP. DO NOT CLICK links or
> attachments unless you recognize the sender and know the content is safe.
>
>
>
> On Fri, Apr 12, 2019 at 09:52:50AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > This PCIe controller is based on the Mobiveil GPEX IP, which is
> > compatible with the PCI Expressâ„¢ Base Specification, Revision 4.0.
> >
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > ---
> > V5:
> > - Corrected the subject.
> > - Corrected 2 typos.
> > - Updated the Copyright and driver description.
> > - Changed to use BIT(x) to define verious functions of register's bits.
> > - Unified the capitalization of error info.
> > - Changed the IRQ handler name to ls_pcie_g4_isr().
> > - Change 'irq' to 'IRQ' in error info.
> > - Trimmed some functions without functionality change.
> >
> > drivers/pci/controller/mobiveil/Kconfig | 10 +
> > drivers/pci/controller/mobiveil/Makefile | 1 +
>
> > .../controller/mobiveil/pci-layerscape-gen4.c | 256
> > ++
>
> I would probably name this "pcie-layerscape-gen4.c" ("pcie" instead of "pci"),
> since that's more typical and this really is PCIe-specific.
Yes, this can be arranged in v6.
>
> > +#define PCIE_PF_DBG 0x7fc
> > +#define PF_DBG_LTSSM_MASK0x3f
> > +#define PF_DBG_WEBIT(31)
> > +#define PF_DBG_PABR BIT(27)
> > +
> > +#define LS_PCIE_G4_LTSSM_L0 0x2d /* L0 state */
>
> Maybe rename this and move it to make it obvious that it's related to
> PF_DBG_LTSSM_MASK?
Yes, will rename it in v6.
>
> > + dev_err(dev, "Poll PABRST&PABACT timeout.\n");
>
> No need for punctuation at end of messages.
Will remove them in v6.
Thanks,
Zhiqiang
[PATCH] fs/reiserfs/journal.c: Make remove_journal_hash static
This fixes the -WDecl sparse warning in journal.c. Function was declared as static void but the definition was void. Signed-off-by: Bharath Vedartham --- fs/reiserfs/journal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c index 8a76f9d..36346dc 100644 --- a/fs/reiserfs/journal.c +++ b/fs/reiserfs/journal.c @@ -1844,7 +1844,7 @@ static int flush_used_journal_lists(struct super_block *s, * removes any nodes in table with name block and dev as bh. * only touchs the hnext and hprev pointers. */ -void remove_journal_hash(struct super_block *sb, +static void remove_journal_hash(struct super_block *sb, struct reiserfs_journal_cnode **table, struct reiserfs_journal_list *jl, unsigned long block, int remove_freed) -- 2.7.4
Re: [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface
On Mon, 8 Apr 2019 15:15:56 +0200 H. Nikolaus Schaller wrote: > Hi Jonathan, > > > Am 07.04.2019 um 14:30 schrieb Jonathan Cameron : > > > > On Sun, 31 Mar 2019 12:09:46 +0200 > > "H. Nikolaus Schaller" wrote: > > > > Hi Nikolaus, > > > > I'm probably going to repeat a few things I sent for v1 as the audience has > > expanded somewhat! > > > > Good to see this moving forwards though as there has been at least some > > demand > > for it going way back to the early days of IIO. > > > >> Some user spaces (e.g. some Android devices) use /dev/input/event* for > >> handling > >> the 3D position of the device with respect to the center of gravity > >> (earth). > >> This can be used for gaming input, auto-rotation of screens etc. > >> > >> This interface should be the standard for such use cases because it is an > >> abstraction > >> of how orientation data is acquired from sensor chips. Sensor chips may be > >> connected > >> through different interfaces and in different positions. They may also > >> have different > >> parameters. And, if a chip is replaced by a different one, the values > >> reported by > >> the device position interface should remain the same, provided the device > >> tree reflects > >> the changed chip. > >> > >> This did initially lead to input accelerometer drivers like > >> drivers/input/misc/bma150.c > >> or drivers/misc/lis3lv02d/ > >> > >> But nowadays, new accelerometer chips mostly get iio drivers and rarely > >> input drivers. > >> > >> Therefore we need something like a protocol stack which bridges raw data > >> and input devices. > >> It can be seen as a similar layering like TCP/IP vs. bare Ethernet. Or > >> keyboard > >> input events vs. raw gpio or raw USB access. > >> > >> This patch bridges the gap between raw iio data and the input device > >> abstraction > >> so that accelerometer measurements can additionally be presented as X/Y/Z > >> accelerometer > >> channels (INPUT_PROP_ACCELEROMETER) through /dev/input/event*. > >> > >> There are no special requirements or changes needed for an iio driver. > >> > >> There is no need to define a mapping (e.g. in device tree). > > This worries me, as it inherently means we end up with this interface being > > registered in cases where it makes no sense. A lot of generic distros get > > used across widely differing use cases. > > I still do not fully understand what is worrying you here. > > Do you worry about functionality, flexibility or resources or something else? Two main things: 1) Lack of generality of the approach. This is a single use trick for input devices. Why does it make sense for input devices? There are lots of other in kernel users and potential ones in the future. The ability to register additional IIO consumers like this is useful, lets make it useful to everyone. 2) To much generality of the specific usecase. I don't want to put an Input interface on accelerometers where it makes no sense. The rule of it has 2-3 axis so it must make sense isn't good enough to my mind. How does userspace know which accelerometer to use (more and more devices have multiple?) You could do something like looking at the location info from DT / ACPI in your driver and pick the 'best' but that's policy. Should be in userspace. Sure you can just use the right input driver, but the moment we do that, we need aware userspace, if that's the case why not make it aware from the start. Believe me I've been round this one a good few times and thought about it a lot. I'll take a lot of convincing that this isn't a problem that should be pushed into userspace. > > I think having them mapped always does not need much resources (except a > handful of bytes > in memory and some µs during probing) unless the event device is opened and > really used. > Only then it starts e.g. I2C traffic to read the sensors. The bytes don't really mater. The userspace ABI additions do. > > So it is just some unused file sitting around in /dev. Or 2 or could be even > 100. > For devices which have no iio accelerometers configured, there will be no > /dev/input > file. So we are discussing the rare case of devices with more than one or two > accelerometers. Well they aren't exactly rare in IIO using systems ;) > > Now, on every system there are many interfaces and files that are not used > because it makes > no sense to look at them. If I check on one of my systems, I find for example > a lot of > /dev/tty and only a very small portion is used and generic distros have no > issue with it. > > There is even /dev/iio:device0 to /dev/iio:device5 representing the raw iio > devices. > Not all of them are actively used, but they are simply there and can be > scanned for. Agreed, in the ideal case we wouldn't have had that either, but we are stuck with it. The long term plan is to allow use of IIO backends without the front end being there at all. Lots of SoC ADC users would
[PATCH v3 RESEND 2/4] memory: Kconfig: Drop dependency on MACH_JZ4780 for jz4780
Depending on MACH_JZ4780 prevent us from creating a generic kernel that works on more than one MIPS board. Instead, we just depend on MIPS being set. Signed-off-by: Paul Cercueil Reviewed-by: Boris Brezillon --- v2: No change v3: No change drivers/memory/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 2d91b00e3591..3d411575fcb6 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -122,7 +122,7 @@ config FSL_IFC config JZ4780_NEMC bool "Ingenic JZ4780 SoC NEMC driver" default y - depends on MACH_JZ4780 || COMPILE_TEST + depends on MIPS || COMPILE_TEST depends on HAS_IOMEM && OF help This driver is for the NAND/External Memory Controller (NEMC) in -- 2.11.0
[PATCH v3 RESEND 4/4] memory: jz4780_nemc: Add support for the JZ4740
Add support for the JZ4740 SoC from Ingenic.
Signed-off-by: Paul Cercueil
Reviewed-by: Boris Brezillon
---
v2: No change
v3: Support the JZ4740 instead of the JZ4725B (exact same functionality
but JZ4740 is already fully upstream)
drivers/memory/jz4780-nemc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
index 66b8b43eaeff..f3a19b9b76ac 100644
--- a/drivers/memory/jz4780-nemc.c
+++ b/drivers/memory/jz4780-nemc.c
@@ -44,9 +44,14 @@
#define NEMC_NFCSR_NFCEn(n)BITn) - 1) << 1) + 1)
#define NEMC_NFCSR_TNFEn(n)BIT(16 + (n) - 1)
+struct jz_soc_info {
+ u8 tas_tah_cycles_max;
+};
+
struct jz4780_nemc {
spinlock_t lock;
struct device *dev;
+ const struct jz_soc_info *soc_info;
void __iomem *base;
struct clk *clk;
uint32_t clk_period;
@@ -202,7 +207,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
if (of_property_read_u32(node, "ingenic,nemc-tAS", &val) == 0) {
smcr &= ~NEMC_SMCR_TAS_MASK;
cycles = jz4780_nemc_ns_to_cycles(nemc, val);
- if (cycles > 15) {
+ if (cycles > nemc->soc_info->tas_tah_cycles_max) {
dev_err(nemc->dev, "tAS %u is too high (%u cycles)\n",
val, cycles);
return false;
@@ -214,7 +219,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
if (of_property_read_u32(node, "ingenic,nemc-tAH", &val) == 0) {
smcr &= ~NEMC_SMCR_TAH_MASK;
cycles = jz4780_nemc_ns_to_cycles(nemc, val);
- if (cycles > 15) {
+ if (cycles > nemc->soc_info->tas_tah_cycles_max) {
dev_err(nemc->dev, "tAH %u is too high (%u cycles)\n",
val, cycles);
return false;
@@ -278,6 +283,10 @@ static int jz4780_nemc_probe(struct platform_device *pdev)
if (!nemc)
return -ENOMEM;
+ nemc->soc_info = device_get_match_data(dev);
+ if (!nemc->soc_info)
+ return -EINVAL;
+
spin_lock_init(&nemc->lock);
nemc->dev = dev;
@@ -370,8 +379,17 @@ static int jz4780_nemc_remove(struct platform_device *pdev)
return 0;
}
+static const struct jz_soc_info jz4740_soc_info = {
+ .tas_tah_cycles_max = 7,
+};
+
+static const struct jz_soc_info jz4780_soc_info = {
+ .tas_tah_cycles_max = 15,
+};
+
static const struct of_device_id jz4780_nemc_dt_match[] = {
- { .compatible = "ingenic,jz4780-nemc" },
+ { .compatible = "ingenic,jz4740-nemc", .data = &jz4740_soc_info, },
+ { .compatible = "ingenic,jz4780-nemc", .data = &jz4780_soc_info, },
{},
};
--
2.11.0
[PATCH v3 RESEND 1/4] dt-bindings: memory: jz4780: Add compatible string for JZ4740 SoC
Add a compatible string to support the memory controller built into the JZ4740 SoC from Ingenic. Signed-off-by: Paul Cercueil Reviewed-by: Boris Brezillon Reviewed-by: Rob Herring --- v2: No change v3: Change compatible string for jz4740 instead of j4725b .../devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt index f936b5589b19..59b8dcc118ee 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt @@ -5,6 +5,7 @@ controller in Ingenic JZ4780 Required properties: - compatible: Should be set to one of: +"ingenic,jz4740-nemc" (JZ4740) "ingenic,jz4780-nemc" (JZ4780) - reg: Should specify the NEMC controller registers location and length. - clocks: Clock for the NEMC controller. -- 2.11.0
[PATCH v3 RESEND 3/4] memory: jz4780-nemc: Reduce size of const array
The maximum value found in that array is 15, there's no need to store
these values as uint32_t, a uint8_t is enough.
Signed-off-by: Paul Cercueil
---
v2: Remove casts to uint32_t
v3: No change
drivers/memory/jz4780-nemc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
index bcf06adefc96..66b8b43eaeff 100644
--- a/drivers/memory/jz4780-nemc.c
+++ b/drivers/memory/jz4780-nemc.c
@@ -161,7 +161,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
* Conversion of tBP and tAW cycle counts to values supported by the
* hardware (round up to the next supported value).
*/
- static const uint32_t convert_tBP_tAW[] = {
+ static const u8 convert_tBP_tAW[] = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
/* 11 - 12 -> 12 cycles */
--
2.11.0
Hello Lovely!!!
It's a beautiful morning from here lovely, i hope this letter met you in the good health, Am Wesley willing to make good friends, bored just wish to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person, Please forgive my manners am not good when it comes to Internet because that is not really my field Here Being in the base that makes it very bored for me so I just think I need a friend to talk to outside to keep me going.. Hoping to read from you soon. With love, Wesley.
How are you beautiful
I hope you had a lovely night, and you having a wonderful weekend.It is my pleasure meeting you. Am sorry to bother you, i apologize for intruding upon your privacy. My name is Wesley. I`m from the State. I am currently looking for a relationship in which I feel loved. I hope you will be kind enough to tell me more about yourself, if you don't mind. I`ll be anticipating for your kind reply. I wish you a awesome day and perfect mood. With respect, Wesley.
[PATCH] proc: fixup proc-pid-vm test
Silly sizeof(pointer) vs sizeof(uint8_t[]) bug.
Fixes: e483b0208784 ("proc: test /proc/*/maps, smaps, smaps_rollup, statm")
Signed-off-by: Alexey Dobriyan
---
tools/testing/selftests/proc/proc-pid-vm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/tools/testing/selftests/proc/proc-pid-vm.c
+++ b/tools/testing/selftests/proc/proc-pid-vm.c
@@ -187,8 +187,8 @@ static int make_exe(const uint8_t *payload, size_t len)
ph.p_offset = 0;
ph.p_vaddr = VADDR;
ph.p_paddr = 0;
- ph.p_filesz = sizeof(struct elf64_hdr) + sizeof(struct elf64_phdr) +
sizeof(payload);
- ph.p_memsz = sizeof(struct elf64_hdr) + sizeof(struct elf64_phdr) +
sizeof(payload);
+ ph.p_filesz = sizeof(struct elf64_hdr) + sizeof(struct elf64_phdr) +
len;
+ ph.p_memsz = sizeof(struct elf64_hdr) + sizeof(struct elf64_phdr) + len;
ph.p_align = 4096;
fd = openat(AT_FDCWD, "/tmp", O_WRONLY|O_EXCL|O_TMPFILE, 0700);
Re: linux-next: Tree for Apr 8 (iio/adc/)
On Mon, 8 Apr 2019 09:09:37 -0700 Randy Dunlap wrote: > On 4/7/19 10:41 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20190405: > > > > on i386 or x86_64: > > modular: > ERROR: "is_stm32_timer_trigger" [drivers/iio/adc/stm32-dfsdm-adc.ko] > undefined! > > or builtin: > ld: drivers/iio/adc/stm32-dfsdm-adc.o: in function `stm32_dfsdm_postenable': > stm32-dfsdm-adc.c:(.text+0x878): undefined reference to > `is_stm32_timer_trigger' > > > Full i386 randconfig file is attached. > Thanks Randy. So two possible fixes for this one. We can do what is done for the stm32-adc driver and select IIO_STM_TIMER_TRIGGER or we can add a stub for this function in the header to make it return false if that driver isn't built. I personally favour the stub option but would like Fabrice to say what makes more sense. So Fabrice, which of the above? If you are busy and don't get back in the next day or two, I'll add the stub. Thanks, Jonathan
[PATCH] proc: fix map_files test on F29
F29 bans mapping first 64KB even for root making test fail.
Iterate from address 0 until mmap() works.
Gentoo (root):
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
Gentoo (non-root):
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EPERM
(Operation not permitted)
mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1000
F29 (root):
openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x2000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x3000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x4000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x5000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x6000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x7000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x8000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x9000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xa000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xb000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xc000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xd000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xe000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0xf000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
(Permission denied)
mmap(0x1, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1
Now all proc tests succeed on F29 if run as root, at last!
Signed-off-by: Alexey Dobriyan
---
tools/testing/selftests/proc/proc-self-map-files-002.c | 20 -
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/tools/testing/selftests/proc/proc-self-map-files-002.c
+++ b/tools/testing/selftests/proc/proc-self-map-files-002.c
@@ -46,12 +46,9 @@ static void fail(const char *fmt, unsigned long a, unsigned
long b)
int main(void)
{
- const unsigned int PAGE_SIZE = sysconf(_SC_PAGESIZE);
-#ifdef __arm__
- unsigned long va = 2 * PAGE_SIZE;
-#else
- unsigned long va = 0;
-#endif
+ const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
+ const unsigned long va_max = 1UL << 32;
+ unsigned long va;
void *p;
int fd;
unsigned long a, b;
@@ -60,10 +57,13 @@ int main(void)
if (fd == -1)
return 1;
- p = mmap((void *)va, PAGE_SIZE, PROT_NONE,
MAP_PRIVATE|MAP_FILE|MAP_FIXED, fd, 0);
- if (p == MAP_FAILED) {
- if (errno == EPERM)
- return 4;
+ for (va = 0; va < va_max; va += PAGE_SIZE) {
+ p = mmap((void *)va, PAGE_SIZE, PROT_NONE,
MAP_PRIVATE|MAP_FILE|MAP_FIXED, fd, 0);
+ if (p == (void *)va)
+ break;
+ }
+ if (va == va_max) {
+ fprintf(stderr, "error: mmap doesn't like you\n");
return 1;
}
[PATCH v3 1/2] dt-bindings: power: supply: Add charge-status-gpios property
Add documentation for the "charge-status-gpios" property.
Update the "gpios" property with a valid example.
Signed-off-by: Artur Rojek
Reviewed-by: Rob Herring
---
Changes:
v2: - add a better description for the "status-gpios" property,
- add valid examples for the "gpios" and "status-gpios" properties
v3: rename the "status-gpios" property to "charge-status-gpios"
.../devicetree/bindings/power/supply/gpio-charger.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
index adbb5dc5b6e9..30349332f051 100644
--- a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt
@@ -14,12 +14,16 @@ Required properties :
usb-cdp (USB charging downstream port)
usb-aca (USB accessory charger adapter)
+Optional properties:
+ - charge-status-gpios: GPIO indicating whether a battery is charging.
+
Example:
usb_charger: charger {
compatible = "gpio-charger";
charger-type = "usb-sdp";
- gpios = <&gpf0 2 0 0 0>;
+ gpios = <&gpd 28 GPIO_ACTIVE_LOW>;
+ charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>;
}
battery {
--
2.21.0
[PATCH v3 2/2] power: supply: gpio-charger: Add support for charger status.
Introduce optional support of POWER_SUPPLY_PROP_STATUS for chargers
which provide charging status GPIO.
Signed-off-by: Artur Rojek
---
Changes:
v2: no change
v3: rename "status_irq" and "status" fields to "charge_status_irq"
and "charge_status" accordingly
drivers/power/supply/gpio-charger.c | 57 +++--
1 file changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/power/supply/gpio-charger.c
b/drivers/power/supply/gpio-charger.c
index 7e4f11d5a230..f99e8f1eef23 100644
--- a/drivers/power/supply/gpio-charger.c
+++ b/drivers/power/supply/gpio-charger.c
@@ -29,11 +29,13 @@
struct gpio_charger {
unsigned int irq;
+ unsigned int charge_status_irq;
bool wakeup_enabled;
struct power_supply *charger;
struct power_supply_desc charger_desc;
struct gpio_desc *gpiod;
+ struct gpio_desc *charge_status;
};
static irqreturn_t gpio_charger_irq(int irq, void *devid)
@@ -59,6 +61,12 @@ static int gpio_charger_get_property(struct power_supply
*psy,
case POWER_SUPPLY_PROP_ONLINE:
val->intval = gpiod_get_value_cansleep(gpio_charger->gpiod);
break;
+ case POWER_SUPPLY_PROP_STATUS:
+ if (gpiod_get_value_cansleep(gpio_charger->charge_status))
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else
+ val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
default:
return -EINVAL;
}
@@ -93,8 +101,29 @@ static enum power_supply_type gpio_charger_get_type(struct
device *dev)
return POWER_SUPPLY_TYPE_UNKNOWN;
}
+static int gpio_charger_get_irq(struct device *dev, void *dev_id,
+ struct gpio_desc *gpio)
+{
+ int ret, irq = gpiod_to_irq(gpio);
+
+ if (irq > 0) {
+ ret = devm_request_any_context_irq(dev, irq, gpio_charger_irq,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ dev_name(dev),
+ dev_id);
+ if (ret < 0) {
+ dev_warn(dev, "Failed to request irq: %d\n", ret);
+ irq = 0;
+ }
+ }
+
+ return irq;
+}
+
static enum power_supply_property gpio_charger_properties[] = {
POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS /* Must always be last in the array. */
};
static int gpio_charger_probe(struct platform_device *pdev)
@@ -104,8 +133,10 @@ static int gpio_charger_probe(struct platform_device *pdev)
struct power_supply_config psy_cfg = {};
struct gpio_charger *gpio_charger;
struct power_supply_desc *charger_desc;
+ struct gpio_desc *charge_status;
+ int charge_status_irq;
unsigned long flags;
- int irq, ret;
+ int ret;
if (!pdata && !dev->of_node) {
dev_err(dev, "No platform data\n");
@@ -151,9 +182,17 @@ static int gpio_charger_probe(struct platform_device *pdev)
return PTR_ERR(gpio_charger->gpiod);
}
+ charge_status = devm_gpiod_get_optional(dev, "charge-status", GPIOD_IN);
+ gpio_charger->charge_status = charge_status;
+ if (IS_ERR(gpio_charger->charge_status))
+ return PTR_ERR(gpio_charger->charge_status);
+
charger_desc = &gpio_charger->charger_desc;
charger_desc->properties = gpio_charger_properties;
charger_desc->num_properties = ARRAY_SIZE(gpio_charger_properties);
+ /* Remove POWER_SUPPLY_PROP_STATUS from the supported properties. */
+ if (!gpio_charger->charge_status)
+ charger_desc->num_properties -= 1;
charger_desc->get_property = gpio_charger_get_property;
psy_cfg.of_node = dev->of_node;
@@ -180,16 +219,12 @@ static int gpio_charger_probe(struct platform_device
*pdev)
return ret;
}
- irq = gpiod_to_irq(gpio_charger->gpiod);
- if (irq > 0) {
- ret = devm_request_any_context_irq(dev, irq, gpio_charger_irq,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
- dev_name(dev), gpio_charger->charger);
- if (ret < 0)
- dev_warn(dev, "Failed to request irq: %d\n", ret);
- else
- gpio_charger->irq = irq;
- }
+ gpio_charger->irq = gpio_charger_get_irq(dev, gpio_charger->charger,
+gpio_charger->gpiod);
+
+ charge_status_irq = gpio_charger_get_irq(dev, gpio_charger->charger,
+gpio_charger->charge_status);
+ gpio_charger->charge_status_irq = charge_status_irq;
platform_set_drvdata(pdev, gpio_charger);
[PATCH 1/2] regulator: max8998: Constify regulator_ops
These regulator_ops variables never need to be modified, make them const so
compiler can put them to .rodata.
Signed-off-by: Axel Lin
---
drivers/regulator/max8998.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 271bb736f3f5..43b69ebd086b 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -427,7 +427,7 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
return 0;
}
-static struct regulator_ops max8998_ldo_ops = {
+static const struct regulator_ops max8998_ldo_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = max8998_ldo_is_enabled,
@@ -437,7 +437,7 @@ static struct regulator_ops max8998_ldo_ops = {
.set_voltage_sel= max8998_set_voltage_ldo_sel,
};
-static struct regulator_ops max8998_buck_ops = {
+static const struct regulator_ops max8998_buck_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = max8998_ldo_is_enabled,
@@ -448,7 +448,7 @@ static struct regulator_ops max8998_buck_ops = {
.set_voltage_time_sel = max8998_set_voltage_buck_time_sel,
};
-static struct regulator_ops max8998_others_ops = {
+static const struct regulator_ops max8998_others_ops = {
.is_enabled = max8998_ldo_is_enabled,
.enable = max8998_ldo_enable,
.disable= max8998_ldo_disable,
--
2.17.1
[PATCH 2/2] regulator: max8998: Factor out struct voltage_map_desc
The struct voltage_map_desc is used for storing min/max/step fileds, and
then setup the min_uV, uV_step and n_voltages fields for regulator_desc.
Introduce MAX8998_LINEAR_REG/MAX8998_OTHERS_REG macro to setup these filds
directly in regulator_desc to simplify the code.
Signed-off-by: Axel Lin
---
drivers/regulator/max8998.c | 294 +++-
1 file changed, 56 insertions(+), 238 deletions(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 43b69ebd086b..60599c3bb845 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -33,72 +33,6 @@ struct max8998_data {
unsigned intbuck2_idx;
};
-struct voltage_map_desc {
- int min;
- int max;
- int step;
-};
-
-/* Voltage maps in uV*/
-static const struct voltage_map_desc ldo23_voltage_map_desc = {
- .min = 80, .step = 5, .max = 130,
-};
-static const struct voltage_map_desc ldo456711_voltage_map_desc = {
- .min = 160, .step = 10, .max = 360,
-};
-static const struct voltage_map_desc ldo8_voltage_map_desc = {
- .min = 300, .step = 10, .max = 360,
-};
-static const struct voltage_map_desc ldo9_voltage_map_desc = {
- .min = 280, .step = 10, .max = 310,
-};
-static const struct voltage_map_desc ldo10_voltage_map_desc = {
- .min = 95, .step = 5, .max = 130,
-};
-static const struct voltage_map_desc ldo1213_voltage_map_desc = {
- .min = 80, .step = 10, .max = 330,
-};
-static const struct voltage_map_desc ldo1415_voltage_map_desc = {
- .min = 120, .step = 10, .max = 330,
-};
-static const struct voltage_map_desc ldo1617_voltage_map_desc = {
- .min = 160, .step = 10, .max = 360,
-};
-static const struct voltage_map_desc buck12_voltage_map_desc = {
- .min = 75, .step = 25000, .max = 1525000,
-};
-static const struct voltage_map_desc buck3_voltage_map_desc = {
- .min = 160, .step = 10, .max = 360,
-};
-static const struct voltage_map_desc buck4_voltage_map_desc = {
- .min = 80, .step = 10, .max = 230,
-};
-
-static const struct voltage_map_desc *ldo_voltage_map[] = {
- NULL,
- NULL,
- &ldo23_voltage_map_desc,/* LDO2 */
- &ldo23_voltage_map_desc,/* LDO3 */
- &ldo456711_voltage_map_desc,/* LDO4 */
- &ldo456711_voltage_map_desc,/* LDO5 */
- &ldo456711_voltage_map_desc,/* LDO6 */
- &ldo456711_voltage_map_desc,/* LDO7 */
- &ldo8_voltage_map_desc, /* LDO8 */
- &ldo9_voltage_map_desc, /* LDO9 */
- &ldo10_voltage_map_desc,/* LDO10 */
- &ldo456711_voltage_map_desc,/* LDO11 */
- &ldo1213_voltage_map_desc, /* LDO12 */
- &ldo1213_voltage_map_desc, /* LDO13 */
- &ldo1415_voltage_map_desc, /* LDO14 */
- &ldo1415_voltage_map_desc, /* LDO15 */
- &ldo1617_voltage_map_desc, /* LDO16 */
- &ldo1617_voltage_map_desc, /* LDO17 */
- &buck12_voltage_map_desc, /* BUCK1 */
- &buck12_voltage_map_desc, /* BUCK2 */
- &buck3_voltage_map_desc,/* BUCK3 */
- &buck4_voltage_map_desc,/* BUCK4 */
-};
-
static int max8998_get_enable_register(struct regulator_dev *rdev,
int *reg, int *shift)
{
@@ -400,7 +334,6 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
{
struct max8998_data *max8998 = rdev_get_drvdata(rdev);
struct i2c_client *i2c = max8998->iodev->i2c;
- const struct voltage_map_desc *desc;
int buck = rdev_get_id(rdev);
u8 val = 0;
int difference, ret;
@@ -408,8 +341,6 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
if (buck < MAX8998_BUCK1 || buck > MAX8998_BUCK4)
return -EINVAL;
- desc = ldo_voltage_map[buck];
-
/* Voltage stabilization */
ret = max8998_read_reg(i2c, MAX8998_REG_ONOFF4, &val);
if (ret)
@@ -420,7 +351,7 @@ static int max8998_set_voltage_buck_time_sel(struct
regulator_dev *rdev,
if (max8998->iodev->type == TYPE_MAX8998 && !(val & MAX8998_ENRAMP))
return 0;
- difference = (new_selector - old_selector) * desc->step / 1000;
+ difference = (new_selector - old_selector) * rdev->desc->uV_step / 1000;
if (difference > 0)
return DIV_ROUND_UP(difference, (val & 0x0f) + 1);
@@ -454,158 +385,53 @@ static const struct regulator_ops max8998_others_ops = {
.disable= max8998_ldo_disable,
};
-static struct regulator_desc regulators[] = {
- {
- .name = "LDO2",
- .id = MAX8998_LDO2,
- .ops= &max8998_ldo_ops,
- .type = REGULATOR_VOLTAGE,
- .ow
Re: [PATCH][next] iio: temperature: max31856: fix uninitialized error return
On Wed, 10 Apr 2019 19:23:51 +0100
Colin King wrote:
> From: Colin Ian King
>
> Currently if mask is neither CHAN_INFO_RAW or CHAN_INFO_SCALE then
> then an uninitialized error return 'ret' is returned. Fix this by
> adding a default case that ensures -EINVAL is returned for this
> specific case.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Signed-off-by: Colin Ian King
Thanks Colin,
Dan / smatch caught this one as well, but as you sent a patch
yours gets applied.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/temperature/max31856.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iio/temperature/max31856.c
> b/drivers/iio/temperature/max31856.c
> index 6b67d6b95cf9..f184ba5601d9 100644
> --- a/drivers/iio/temperature/max31856.c
> +++ b/drivers/iio/temperature/max31856.c
> @@ -210,6 +210,9 @@ static int max31856_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT_PLUS_MICRO;
> }
> break;
> + default:
> + ret = -EINVAL;
> + break;
> }
>
> return ret;
Re: [PATCH] iio: dac: ad5758: Modifications for new revision
On Tue, 9 Apr 2019 16:35:21 +0300
Mircea Caprioru wrote:
> This patch will ensure compatibility with the new revision of the AD5758
> dac converter. The modifications consist of removing the fault_prot_switch
> function since this option is no longer available, and enabling the
> ENABLE_PPC_BUFFERS bit in ADC_CONFIG register before setting the PPC
> current mode.
>
> Signed-off-by: Mircea Caprioru
Hi Mircea,
Talk me through the implications of this change.
1. Any changes to functionality that might break users of the older revisions?
2. Any userspace visible changes?
3. Do we want to think about back porting to older kernels?
4. Should we support this explicitly by detecting or describing the
hardware revision in some fashion?
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad5758.c | 55 +---
> 1 file changed, 18 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5758.c b/drivers/iio/dac/ad5758.c
> index 2bdf1b0aee06..a513c70faefa 100644
> --- a/drivers/iio/dac/ad5758.c
> +++ b/drivers/iio/dac/ad5758.c
> @@ -72,8 +72,6 @@
> #define AD5758_DCDC_CONFIG1_DCDC_VPROG_MODE(x) (((x) & 0x1F) << 0)
> #define AD5758_DCDC_CONFIG1_DCDC_MODE_MSKGENMASK(6, 5)
> #define AD5758_DCDC_CONFIG1_DCDC_MODE_MODE(x)(((x) & 0x3) << 5)
> -#define AD5758_DCDC_CONFIG1_PROT_SW_EN_MSK BIT(7)
> -#define AD5758_DCDC_CONFIG1_PROT_SW_EN_MODE(x) (((x) & 0x1) << 7)
>
> /* AD5758_DCDC_CONFIG2 */
> #define AD5758_DCDC_CONFIG2_ILIMIT_MSK GENMASK(3, 1)
> @@ -84,6 +82,10 @@
> /* AD5758_DIGITAL_DIAG_RESULTS */
> #define AD5758_CAL_MEM_UNREFRESHED_MSK BIT(15)
>
> +/* AD5758_ADC_CONFIG */
> +#define AD5758_ADC_CONFIG_PPC_BUF_EN(x) (((x) & 0x1) << 11)
> +#define AD5758_ADC_CONFIG_PPC_BUF_MSKBIT(11)
> +
> #define AD5758_WR_FLAG_MSK(x)(0x80 | ((x) & 0x1F))
>
> #define AD5758_FULL_SCALE_MICRO 6553500ULL
> @@ -315,6 +317,18 @@ static int ad5758_set_dc_dc_conv_mode(struct
> ad5758_state *st,
> {
> int ret;
>
> + /*
> + * The ENABLE_PPC_BUFFERS bit must be set prior to enabling PPC current
> + * mode.
> + */
> + if (mode == AD5758_DCDC_MODE_PPC_CURRENT) {
> + ret = ad5758_spi_write_mask(st, AD5758_ADC_CONFIG,
> + AD5758_ADC_CONFIG_PPC_BUF_MSK,
> + AD5758_ADC_CONFIG_PPC_BUF_EN(1));
> + if (ret < 0)
> + return ret;
> + }
> +
> ret = ad5758_spi_write_mask(st, AD5758_DCDC_CONFIG1,
> AD5758_DCDC_CONFIG1_DCDC_MODE_MSK,
> AD5758_DCDC_CONFIG1_DCDC_MODE_MODE(mode));
> @@ -444,23 +458,6 @@ static int ad5758_set_out_range(struct ad5758_state *st,
> int range)
>AD5758_CAL_MEM_UNREFRESHED_MSK);
> }
>
> -static int ad5758_fault_prot_switch_en(struct ad5758_state *st, bool enable)
> -{
> - int ret;
> -
> - ret = ad5758_spi_write_mask(st, AD5758_DCDC_CONFIG1,
> - AD5758_DCDC_CONFIG1_PROT_SW_EN_MSK,
> - AD5758_DCDC_CONFIG1_PROT_SW_EN_MODE(enable));
> - if (ret < 0)
> - return ret;
> - /*
> - * Poll the BUSY_3WI bit in the DCDC_CONFIG2 register until it is 0.
> - * This allows the 3-wire interface communication to complete.
> - */
> - return ad5758_wait_for_task_complete(st, AD5758_DCDC_CONFIG2,
> - AD5758_DCDC_CONFIG2_BUSY_3WI_MSK);
> -}
> -
> static int ad5758_internal_buffers_en(struct ad5758_state *st, bool enable)
> {
> int ret;
> @@ -585,8 +582,8 @@ static ssize_t ad5758_write_powerdown(struct iio_dev
> *indio_dev,
> {
> struct ad5758_state *st = iio_priv(indio_dev);
> bool pwr_down;
> - unsigned int dcdc_config1_mode, dc_dc_mode, dac_config_mode, val;
> - unsigned long int dcdc_config1_msk, dac_config_msk;
> + unsigned int dc_dc_mode, dac_config_mode, val;
> + unsigned long int dac_config_msk;
> int ret;
>
> ret = kstrtobool(buf, &pwr_down);
> @@ -602,17 +599,6 @@ static ssize_t ad5758_write_powerdown(struct iio_dev
> *indio_dev,
> val = 1;
> }
>
> - dcdc_config1_mode = AD5758_DCDC_CONFIG1_DCDC_MODE_MODE(dc_dc_mode) |
> - AD5758_DCDC_CONFIG1_PROT_SW_EN_MODE(val);
> - dcdc_config1_msk = AD5758_DCDC_CONFIG1_DCDC_MODE_MSK |
> -AD5758_DCDC_CONFIG1_PROT_SW_EN_MSK;
> -
> - ret = ad5758_spi_write_mask(st, AD5758_DCDC_CONFIG1,
> - dcdc_config1_msk,
> - dcdc_config1_mode);
> - if (ret < 0)
> - goto err_unlock;
> -
> dac_config_mode = AD5758_DAC_CONFIG_OUT_EN_MODE(val) |
> AD5758_DAC_CONFIG_INT_EN_MODE(val);
> dac_config_msk = AD5758_DAC_CONFIG_OUT_EN_MSK |
> @@
Re: [PATCH 1/3] srf04.c: add maxbotix ultrasonic sensors
On Tue, 9 Apr 2019 21:10:22 +0200
Andreas Klinger wrote:
> add Maxbotix LV ultrasonic sensor types mb1000, mb1010, mb1020, mb1030
> and mb1040
>
> add a configuration struct with the different trigger pulse lengths
>
> Signed-off-by: Andreas Klinger
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/proximity/srf04.c | 38 +-
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c
> index 09c7b9c095b0..1bad4018d1aa 100644
> --- a/drivers/iio/proximity/srf04.c
> +++ b/drivers/iio/proximity/srf04.c
> @@ -23,7 +23,7 @@
> * trig: --+ +--
> * ^ ^
> * |<->|
> - * udelay(10)
> + * udelay(trigger_pulse_us)
> *
> * ultra +-+ +-+ +-+
> * sonic | | | | | |
> @@ -48,6 +48,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -56,6 +57,10 @@
> #include
> #include
>
> +struct srf04_cfg {
> + unsigned long trigger_pulse_us;
> +};
> +
> struct srf04_data {
> struct device *dev;
> struct gpio_desc*gpiod_trig;
> @@ -66,6 +71,15 @@ struct srf04_data {
> ktime_t ts_falling;
> struct completion rising;
> struct completion falling;
> + const struct srf04_cfg *cfg;
> +};
> +
> +static const struct srf04_cfg srf04_cfg = {
> + .trigger_pulse_us = 10,
> +};
> +
> +static const struct srf04_cfg mb_lv_cfg = {
> + .trigger_pulse_us = 20,
> };
>
> static irqreturn_t srf04_handle_irq(int irq, void *dev_id)
> @@ -102,7 +116,7 @@ static int srf04_read(struct srf04_data *data)
> reinit_completion(&data->falling);
>
> gpiod_set_value(data->gpiod_trig, 1);
> - udelay(10);
> + udelay(data->cfg->trigger_pulse_us);
> gpiod_set_value(data->gpiod_trig, 0);
>
> /* it cannot take more than 20 ms */
> @@ -215,6 +229,18 @@ static const struct iio_chan_spec srf04_chan_spec[] = {
> },
> };
>
> +static const struct of_device_id of_srf04_match[] = {
> + { .compatible = "devantech,srf04", .data = &srf04_cfg},
> + { .compatible = "maxbotix,mb1000", .data = &mb_lv_cfg},
> + { .compatible = "maxbotix,mb1010", .data = &mb_lv_cfg},
> + { .compatible = "maxbotix,mb1020", .data = &mb_lv_cfg},
> + { .compatible = "maxbotix,mb1030", .data = &mb_lv_cfg},
> + { .compatible = "maxbotix,mb1040", .data = &mb_lv_cfg},
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, of_srf04_match);
> +
> static int srf04_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -230,6 +256,7 @@ static int srf04_probe(struct platform_device *pdev)
>
> data = iio_priv(indio_dev);
> data->dev = dev;
> + data->cfg = of_match_device(of_srf04_match, dev)->data;
>
> mutex_init(&data->lock);
> init_completion(&data->rising);
> @@ -280,13 +307,6 @@ static int srf04_probe(struct platform_device *pdev)
> return devm_iio_device_register(dev, indio_dev);
> }
>
> -static const struct of_device_id of_srf04_match[] = {
> - { .compatible = "devantech,srf04", },
> - {},
> -};
> -
> -MODULE_DEVICE_TABLE(of, of_srf04_match);
> -
> static struct platform_driver srf04_driver = {
> .probe = srf04_probe,
> .driver = {
Re: [PATCH 2/3] devantech-srf04.yaml: add Maxbotix ultrasonic iio proximity sensors
On Tue, 9 Apr 2019 16:08:02 -0500 Rob Herring wrote: > On Tue, Apr 9, 2019 at 2:11 PM Andreas Klinger wrote: > > > > add compatibles for Maxbotix ultrasonic iio sensor types to yaml > > documentation > > > > Signed-off-by: Andreas Klinger > > --- > > .../bindings/iio/proximity/devantech-srf04.yaml| 25 > > ++ > > 1 file changed, 16 insertions(+), 9 deletions(-) > > In the future, 'dt-bindings: iio: ...' for the subject please. > > Reviewed-by: Rob Herring Applied and subject tidied up. Thanks, Jonathan
Re: [PATCH 3/3] Kconfig: change configuration of srf04 ultrasonic iio sensor
On Tue, 9 Apr 2019 21:11:28 +0200 Andreas Klinger wrote: > reword configuration option for SRF04 > > list supported types in help text > > Signed-off-by: Andreas Klinger Applied and pushed out as testing for the autobuilders to play with it. thanks, Jonathan > --- > drivers/iio/proximity/Kconfig | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig > index 12a3d3d40a91..e9f254ae3892 100644 > --- a/drivers/iio/proximity/Kconfig > +++ b/drivers/iio/proximity/Kconfig > @@ -68,12 +68,19 @@ config RFD77402 > module will be called rfd77402. > > config SRF04 > - tristate "Devantech SRF04 ultrasonic ranger sensor" > + tristate "GPIO bitbanged ultrasonic ranger sensor (SRF04, MB1000)" > depends on GPIOLIB > help > - Say Y here to build a driver for Devantech SRF04 ultrasonic > + Say Y here to build a driver for GPIO bitbanged ultrasonic > ranger sensor. This driver can be used to measure the distance > of objects. It is using two GPIOs. > + Actually Supported types are: > + - Devantech SRF04 > + - Maxbotix mb1000 > + - Maxbotix mb1010 > + - Maxbotix mb1020 > + - Maxbotix mb1030 > + - Maxbotix mb1040 > > To compile this driver as a module, choose M here: the > module will be called srf04.
Re: [PATCH 1/5] pinctrl: pistachio: fix leaked of_node references
> @@ -1367,6 +1367,7 @@ static int pistachio_gpio_register(struct
> pistachio_pinctrl *pctl)
> if (!of_find_property(child, "gpio-controller", NULL)) {
> dev_err(pctl->dev,
> "No gpio-controller property for bank %u\n", i);
> + of_node_put(child);
> ret = -ENODEV;
> goto err;
> }
> @@ -1374,6 +1375,7 @@ static int pistachio_gpio_register(struct
> pistachio_pinctrl *pctl)
> irq = irq_of_parse_and_map(child, 0);
> if (irq < 0) {
> dev_err(pctl->dev, "No IRQ for bank %u: %d\n", i, irq);
> + of_node_put(child);
> ret = irq;
> goto err;
> }
Would you like to move such duplicate statements (and other function calls)
to additional jump targets for the desired exception handling?
Regards,
Markus
Re: Kconfig dependency issue on function-graph tracer and frame pointer on arm
On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> Hello,
>
> Recently, Naresh reported that the function-graph tracer on the latest
> kernel crashes on arm. I could reproduce it and bisected. I finally found
> the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> was the first bad commit.
I don't think that littering the rest of the kernel Kconfig with ARM
specific stuff is really a viable solution to this.
If we examine the current situation, we have:
- THUMB2_KERNEL selecting ARM_UNWIND when enabled.
- UNWINDER_FRAME_POINTER disabled if THUMB2_KERNEL is enabled, provided
we're not using Clang. This leaves UNWINDER_ARM as the only choice,
which also selects ARM_UNWIND.
- The default choice is dependent on the settings of AEABI and
FUNCTION_GRAPH_TRACER.
- HAVE_FUNCTION_GRAPH_TRACER is disabled if THUMB2_KERNEL is enabled.
which seems to be _way_ too messy.
Looking back before this commit, the function graph tracer never had a
strong dependence on frame pointers being enabled in the kernel, but it
seems the code relies upon them (see ftrace_return_to_handler() in
kernel/trace/ and return_to_handler in arch/arm/kernel/entry-frace.S).
There is also the __ftrace_graph_caller macro which seems to rely on it.
Since Clang does not support frame pointers, we shouldn't even offer
the function graph tracer for Clang compilers, so let's do that with
the first hunk of the patch below.
The subsequent hunks remove the defaulting of the choice according to
the function graph tracer - this is not a "hint" where the user can
still choose either option irrespective of the state of the function
graph tracer. They should only be able to select the frame pointer
option in that case.
Another way forward would be for someone to put the work in to making
the function graph tracer work without frame pointers.
So, how about this:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 850b4805e2d1..9aed25a6019b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -73,7 +73,7 @@ config ARM
select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7)
&& MMU
select HAVE_EXIT_THREAD
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
- select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
+ select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
select HAVE_FUNCTION_TRACER if !XIP_KERNEL
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K ||
CPU_V7)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6d6e0330930b..e388af4594a6 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -47,8 +47,8 @@ config DEBUG_WX
choice
prompt "Choose kernel unwinder"
- default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
- default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
+ default UNWINDER_ARM if AEABI
+ default UNWINDER_FRAME_POINTER if !AEABI
help
This determines which method will be used for unwinding kernel stack
traces for panics, oopses, bugs, warnings, perf, /proc//stack,
@@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
config UNWINDER_ARM
bool "ARM EABI stack unwinder"
- depends on AEABI
+ depends on AEABI && !FUNCTION_GRAPH_TRACER
select ARM_UNWIND
help
This option enables stack unwinding support in the kernel
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH] quota: remvoe redundant variable assignment
The assignment of variable ret is redundant because the value of ret is 0 after calling v2_read_header() in normal case. Signed-off-by: Chengguang Xu --- fs/quota/quota_v2.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/quota/quota_v2.c b/fs/quota/quota_v2.c index a73e5b34db41..25d36607be6e 100644 --- a/fs/quota/quota_v2.c +++ b/fs/quota/quota_v2.c @@ -158,7 +158,6 @@ static int v2_read_file_info(struct super_block *sb, int type) qinfo->dqi_entry_size = sizeof(struct v2r1_disk_dqblk); qinfo->dqi_ops = &v2r1_qtree_ops; } - ret = 0; out: up_read(&dqopt->dqio_sem); return ret; -- 2.17.2
Re: [EXT] Re: [PATCH] iio: accell: mma8452: free iio trigger pointer when cleanup
On Mon, 8 Apr 2019 02:07:24 + Anson Huang wrote: > Hi, Jonathan > > Best Regards! > Anson Huang > > > -Original Message- > > From: Jonathan Cameron [mailto:ji...@kernel.org] > > Sent: 2019年4月7日 18:40 > > To: Anson Huang > > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; Leonard > > Crestez ; gust...@embeddedor.com; > > mart...@posteo.de; rtres...@electromag.com.au; linux-...@vger.kernel.org; > > linux-kernel@vger.kernel.org; dl-linux-imx > > Subject: [EXT] Re: [PATCH] iio: accell: mma8452: free iio trigger pointer > > when > > cleanup > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > > attachments unless you recognize the sender and know the content is safe. > > > > > > > > On Thu, 4 Apr 2019 08:02:05 + > > Anson Huang wrote: > > > > > When mma8452 is built as module, once it is insmod and rmmod, below > > > kernel dump will show out, the root cause is module being put twice if > > > iio trigger pointer is NOT NULL, this patch frees iio trigger pointer > > > after iio trigger is unregistered to avoid below kernel > > > dump: > > > > > > [ cut here ] > > > WARNING: CPU: 3 PID: 270 at kernel/module.c:1145 > > module_put+0xd0/0x188 > > > Modules linked in: mma8452(-) > > > CPU: 3 PID: 270 Comm: rmmod Not tainted > > > 5.1.0-rc3-next-20190403-00022-g5ede0c9-dirty #1596 Hardware name: > > > Freescale i.MX6 Quad/DualLite (Device Tree) [] > > > (unwind_backtrace) from [] (show_stack+0x10/0x14) > > > [] (show_stack) from [] (dump_stack+0xd8/0x10c) > > > [] (dump_stack) from [] (__warn+0xf8/0x124) > > > [] (__warn) from [] > > (warn_slowpath_null+0x3c/0x48) > > > [] (warn_slowpath_null) from [] > > > (module_put+0xd0/0x188) [] (module_put) from [] > > > (iio_device_unregister_trigger_consumer+0x18/0x24) > > > [] (iio_device_unregister_trigger_consumer) from > > > [] (iio_dev_release+0x20/0) [] (iio_dev_release) > > > from [] (device_release+0x24/0x8c) [] > > > (device_release) from [] (kobject_put+0x74/0xd4) > > > [] (kobject_put) from [] > > > (release_nodes+0x16c/0x1f0) [] (release_nodes) from > > > [] (device_release_driver_internal+0xec/0x1a0) > > > [] (device_release_driver_internal) from [] > > > (driver_detach+0x44/0x80) [] (driver_detach) from > > > [] (bus_remove_driver+0x4c/0xa0) [] > > > (bus_remove_driver) from [] (sys_delete_module+0x130/0x1dc) > > > [] (sys_delete_module) from [] > > (ret_fast_syscall+0x0/0x28) Exception stack(0xe8d87fa8 to 0xe8d87ff0) > > > 7fa0: 0001ffc0 38616d6d be87bbf0 0880 > > > be87be98 > > > 7fc0: 0001ffc0 38616d6d 00323534 0081 000a9744 be87bf81 000a9790 > > > > > > 7fe0: be87bbe8 be87bbd8 0001fe18 b6e381a0 irq event stamp: 4017 > > > hardirqs last enabled at (4035): [] > > > console_unlock+0x400/0x630 hardirqs last disabled at (4052): > > > [] console_unlock+0x80/0x630 softirqs last enabled at > > > (4050): [] __do_softirq+0x458/0x554 softirqs last disabled > > > at (4069): [] irq_exit+0x130/0x180 ---[ end trace > > > a7ba8f1823b1e073 ]--- > > > > > > Signed-off-by: Anson Huang > > Good fine, but the fix is not in the best place. The key thing is that any > > assignment inside a driver to iio_dev->trig should be done with > > iio_trigger_get. > > > > indio_dev->trig = iio_trigger_get(trig). The intent is to avoid this exact > > double > > free, but also handle it correctly if we are using devm_ for all the > > handling. > > > > I just did a grep and there are quite a few drivers not doing this though > > so it's > > one we should be more careful about. > > > > Hmm. Anyone fancy doing an audit of existing drivers and checking which > > ones have this problem? Some seem to do exactly what you have here, but > > that isn't a the best pattern to encourage. > > > > For this one would you mind trying with the iio_trigger_get approach and if > > I'm not missing something, send a v2 fixing it that way? > > With below patch to use iio_trigger_get, looks like try_release_module_ref() > will return 1 > and cause try_stop_module() return fail and we will see " rmmod: can't unload > 'mma8452': Resource temporarily unavailable ", > > As the module ref count check is before > iio_device_unregister_trigger_consumer() is called which > will do iio_trigger_put(), so looks like there is still something wrong with > the module ref count? Hmm. Drivers that grab their own triggers are a bit of a pain. We need the infrastructure to try to prevent trigger drivers going away, but it can cause self references. For this particular driver the validation is only that the trigger is not used with a different device. You can use a different trigger with this device I believe? As such, we shouldn't really be setting this default at all. However, removing it now will break userspace that is assuming the default trigger is set. (setting a trigger should always be a userspace decision, rather than hard coded unless there is a cle
Re: [PATCH] drivers/iio/gyro/mpu3050-core.c: This patch fix the following checkpatch warning.
On Fri, 12 Apr 2019 13:09:23 +0300 Mohan Kumar wrote: > As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for > up to 20ms. so use usleep_range. > > Signed-off-by: Mohan Kumar Please resend, ccing the linux-...@vger.kernel.org mailing list. Thanks, Jonathan > --- > drivers/iio/gyro/mpu3050-core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c > index 85b7ac4..0a40616 100644 > --- a/drivers/iio/gyro/mpu3050-core.c > +++ b/drivers/iio/gyro/mpu3050-core.c > @@ -865,7 +865,7 @@ static int mpu3050_power_up(struct mpu3050 *mpu3050) > dev_err(mpu3050->dev, "error setting power mode\n"); > return ret; > } > - msleep(10); > + usleep_range(1, 2); > > return 0; > }
Re: [1/3] x86: Update DEBUG_TLBFLUSH options description.
On Fri, Apr 12, 2019 at 01:14:54PM -0700, Atish Patra wrote: > On 4/10/19 11:56 PM, Christoph Hellwig wrote: > > Given that this option enables generic code (which you reuse for RISC-V > > later in this series) please also move the config option to > > mm/Kconfig, proabbly keyed off another ARCH_HAVE_DEBUG_TLBFLUSH > > symbol that the architecture can select. > > > > Sure. And when you do that, instead of deleting the help text, make it generic. Otherwise, there's no explanation anymore, how that option is supposed to be used through tlb_flushall_shift. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 01/12] arm-cci: add missing of_node_put after of_device_is_available
> @@ -538,8 +538,10 @@ static int cci_probe(void)
> struct resource res;
>
> np = of_find_matching_node(NULL, arm_cci_matches);
> - if (!of_device_is_available(np))
> + if (!of_device_is_available(np)) {
> + of_node_put(np);
> return -ENODEV;
> + }
>
> ret = of_address_to_resource(np, 0, &res);
> if (!ret) {
How do you think about to move this function call to an additional jump target
for the desired exception handling?
Regards,
Markus
Re: [RFC patch 21/41] proc: Simplify task stack retrieval
On Wed, Apr 10, 2019 at 12:28:15PM +0200, Thomas Gleixner wrote:
> @@ -430,20 +429,16 @@ static int proc_pid_stack(struct seq_fil
> if (!entries)
> return -ENOMEM;
>
> - trace.nr_entries= 0;
> - trace.max_entries = MAX_STACK_TRACE_DEPTH;
> - trace.entries = entries;
> - trace.skip = 0;
> -
> err = lock_trace(task);
> if (!err) {
> - unsigned int i;
> + unsigned int i, nent;
>
> - save_stack_trace_tsk(task, &trace);
> + nent = stack_trace_save_tsk(task, entries,
> + MAX_STACK_TRACE_DEPTH, 0);
>
> - for (i = 0; i < trace.nr_entries; i++) {
> + for (i = 0; i < nent; i++)
> seq_printf(m, "[<0>] %pB\n", (void *)entries[i]);
> - }
> +
I only object to {} removal. The rule of mandatory {} that new languages
have adopted is pretty cool. Otherwise
Reviewed-by: Alexey Dobriyan
Re: Kconfig dependency issue on function-graph tracer and frame pointer on arm
On Sun, 14 Apr 2019 14:34:58 +0100
Russell King - ARM Linux admin wrote:
> On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> > Hello,
> >
> > Recently, Naresh reported that the function-graph tracer on the latest
> > kernel crashes on arm. I could reproduce it and bisected. I finally found
> > the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> > was the first bad commit.
>
> I don't think that littering the rest of the kernel Kconfig with ARM
> specific stuff is really a viable solution to this.
>
> If we examine the current situation, we have:
>
> - THUMB2_KERNEL selecting ARM_UNWIND when enabled.
> - UNWINDER_FRAME_POINTER disabled if THUMB2_KERNEL is enabled, provided
> we're not using Clang. This leaves UNWINDER_ARM as the only choice,
> which also selects ARM_UNWIND.
> - The default choice is dependent on the settings of AEABI and
> FUNCTION_GRAPH_TRACER.
> - HAVE_FUNCTION_GRAPH_TRACER is disabled if THUMB2_KERNEL is enabled.
>
> which seems to be _way_ too messy.
>
> Looking back before this commit, the function graph tracer never had a
> strong dependence on frame pointers being enabled in the kernel, but it
> seems the code relies upon them (see ftrace_return_to_handler() in
> kernel/trace/ and return_to_handler in arch/arm/kernel/entry-frace.S).
> There is also the __ftrace_graph_caller macro which seems to rely on it.
Yes, so I think similar bug is hiding in other LTS kernels. It should
have a dependency to FRAME_POINTER on arm.
> Since Clang does not support frame pointers, we shouldn't even offer
> the function graph tracer for Clang compilers, so let's do that with
> the first hunk of the patch below.
>
> The subsequent hunks remove the defaulting of the choice according to
> the function graph tracer - this is not a "hint" where the user can
> still choose either option irrespective of the state of the function
> graph tracer. They should only be able to select the frame pointer
> option in that case.
Agreed. Using default for making dependency is wrong.
>
> Another way forward would be for someone to put the work in to making
> the function graph tracer work without frame pointers.
Yes, we eventually need that. But for fixing current released kernel
(this bug is in v5.0 series), I think Kconfig fix is needed.
>
> So, how about this:
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 850b4805e2d1..9aed25a6019b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -73,7 +73,7 @@ config ARM
> select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7)
> && MMU
> select HAVE_EXIT_THREAD
> select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> - select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
> + select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> select HAVE_GCC_PLUGINS
> select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K ||
> CPU_V7)
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 6d6e0330930b..e388af4594a6 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -47,8 +47,8 @@ config DEBUG_WX
>
> choice
> prompt "Choose kernel unwinder"
> - default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
> - default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
> + default UNWINDER_ARM if AEABI
> + default UNWINDER_FRAME_POINTER if !AEABI
If UNWINDER_ARM depends on ARM EABI, would we really need this "if !AEABI"?
(I doubt we need these default...)
> help
> This determines which method will be used for unwinding kernel stack
> traces for panics, oopses, bugs, warnings, perf, /proc//stack,
> @@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
>
> config UNWINDER_ARM
> bool "ARM EABI stack unwinder"
> - depends on AEABI
> + depends on AEABI && !FUNCTION_GRAPH_TRACER
Hmm, AFAIK, FUNCTION_GRAPH_TRACER only depends on FRAME_POINTER, but not
UNWINDER_FRAME_POINTER. So can user still choose UNWINDER_ARM even if
FUNCTION_GRAPH_TRACER=y ? (Of course that may not be a meaningful option)
Thank you,
> select ARM_UNWIND
> help
> This option enables stack unwinding support in the kernel
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
--
Masami Hiramatsu
Re: [PATCH] proc: fix map_files test on F29
On 4/14/19 5:36 AM, Alexey Dobriyan wrote:
> F29 bans mapping first 64KB even for root making test fail.
so there is an F29-only patch that prevents that?
something that is not in mainline?
thanks.
> Iterate from address 0 until mmap() works.
>
> Gentoo (root):
>
> openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
> mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
>
> Gentoo (non-root):
>
> openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
> mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EPERM
> (Operation not permitted)
> mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1000
>
> F29 (root):
>
> openat(AT_FDCWD, "/dev/zero", O_RDONLY) = 3
> mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x1000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x2000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x3000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x4000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x5000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x6000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x7000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x8000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x9000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xa000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xb000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xc000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xd000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xe000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0xf000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = -1 EACCES
> (Permission denied)
> mmap(0x1, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1
>
> Now all proc tests succeed on F29 if run as root, at last!
>
> Signed-off-by: Alexey Dobriyan
> ---
>
> tools/testing/selftests/proc/proc-self-map-files-002.c | 20
> -
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> --- a/tools/testing/selftests/proc/proc-self-map-files-002.c
> +++ b/tools/testing/selftests/proc/proc-self-map-files-002.c
> @@ -46,12 +46,9 @@ static void fail(const char *fmt, unsigned long a,
> unsigned long b)
>
> int main(void)
> {
> - const unsigned int PAGE_SIZE = sysconf(_SC_PAGESIZE);
> -#ifdef __arm__
> - unsigned long va = 2 * PAGE_SIZE;
> -#else
> - unsigned long va = 0;
> -#endif
> + const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
> + const unsigned long va_max = 1UL << 32;
> + unsigned long va;
> void *p;
> int fd;
> unsigned long a, b;
> @@ -60,10 +57,13 @@ int main(void)
> if (fd == -1)
> return 1;
>
> - p = mmap((void *)va, PAGE_SIZE, PROT_NONE,
> MAP_PRIVATE|MAP_FILE|MAP_FIXED, fd, 0);
> - if (p == MAP_FAILED) {
> - if (errno == EPERM)
> - return 4;
> + for (va = 0; va < va_max; va += PAGE_SIZE) {
> + p = mmap((void *)va, PAGE_SIZE, PROT_NONE,
> MAP_PRIVATE|MAP_FILE|MAP_FIXED, fd, 0);
> + if (p == (void *)va)
> + break;
> + }
> + if (va == va_max) {
> + fprintf(stderr, "error: mmap doesn't like you\n");
> return 1;
> }
>
>
--
~Randy
Re: [PATCH RE-SEND] clk: tegra: Don't enable already enabled PLLs
04.03.2019 16:42, Dmitry Osipenko пишет: > 04.03.2019 11:18, Peter De Schrijver пишет: >> On Wed, Feb 27, 2019 at 06:15:04PM +0300, Dmitry Osipenko wrote: >>> 24.02.2019 18:32, Dmitry Osipenko пишет: Initially Common Clock Framework isn't aware of the clock-enable status, this results in enabling of clocks that were enabled by bootloader. This is not a big deal for a regular clock-gates, but for PLL's it may have some unpleasant consequences. Thus re-enabling PLLX (the main CPU parent clock) may result in extra long period of PLL re-locking. Signed-off-by: Dmitry Osipenko --- >>> >>> Peter (and everyone else), yours r-b and ACK will be appreciated since you >>> kinda already took a look at this patch in the past and were okay with it >>> (IIRC, we had some brief discussion on the #tegra IRC a few months ago), >>> thanks. >>> >> >> Acked-By: Peter De Schrijver >> > > Awesome, thanks again! > Hello Stephen and Michael, Could you please pick up this patch to get it into linux-next to get some more testing exposure before it will hit upstream? Thanks in advance.
Re: Kconfig dependency issue on function-graph tracer and frame pointer on arm
On Sun, Apr 14, 2019 at 11:52:38PM +0900, Masami Hiramatsu wrote:
> On Sun, 14 Apr 2019 14:34:58 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> > > Hello,
> > >
> > > Recently, Naresh reported that the function-graph tracer on the latest
> > > kernel crashes on arm. I could reproduce it and bisected. I finally found
> > > the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> > > was the first bad commit.
> >
> > I don't think that littering the rest of the kernel Kconfig with ARM
> > specific stuff is really a viable solution to this.
> >
> > If we examine the current situation, we have:
> >
> > - THUMB2_KERNEL selecting ARM_UNWIND when enabled.
> > - UNWINDER_FRAME_POINTER disabled if THUMB2_KERNEL is enabled, provided
> > we're not using Clang. This leaves UNWINDER_ARM as the only choice,
> > which also selects ARM_UNWIND.
> > - The default choice is dependent on the settings of AEABI and
> > FUNCTION_GRAPH_TRACER.
> > - HAVE_FUNCTION_GRAPH_TRACER is disabled if THUMB2_KERNEL is enabled.
> >
> > which seems to be _way_ too messy.
> >
> > Looking back before this commit, the function graph tracer never had a
> > strong dependence on frame pointers being enabled in the kernel, but it
> > seems the code relies upon them (see ftrace_return_to_handler() in
> > kernel/trace/ and return_to_handler in arch/arm/kernel/entry-frace.S).
> > There is also the __ftrace_graph_caller macro which seems to rely on it.
>
> Yes, so I think similar bug is hiding in other LTS kernels. It should
> have a dependency to FRAME_POINTER on arm.
>
> > Since Clang does not support frame pointers, we shouldn't even offer
> > the function graph tracer for Clang compilers, so let's do that with
> > the first hunk of the patch below.
> >
> > The subsequent hunks remove the defaulting of the choice according to
> > the function graph tracer - this is not a "hint" where the user can
> > still choose either option irrespective of the state of the function
> > graph tracer. They should only be able to select the frame pointer
> > option in that case.
>
> Agreed. Using default for making dependency is wrong.
>
> >
> > Another way forward would be for someone to put the work in to making
> > the function graph tracer work without frame pointers.
>
> Yes, we eventually need that. But for fixing current released kernel
> (this bug is in v5.0 series), I think Kconfig fix is needed.
>
> >
> > So, how about this:
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 850b4805e2d1..9aed25a6019b 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -73,7 +73,7 @@ config ARM
> > select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7)
> > && MMU
> > select HAVE_EXIT_THREAD
> > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > - select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
> > + select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > select HAVE_GCC_PLUGINS
> > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K ||
> > CPU_V7)
> > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > index 6d6e0330930b..e388af4594a6 100644
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@ -47,8 +47,8 @@ config DEBUG_WX
> >
> > choice
> > prompt "Choose kernel unwinder"
> > - default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
> > - default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
> > + default UNWINDER_ARM if AEABI
> > + default UNWINDER_FRAME_POINTER if !AEABI
>
> If UNWINDER_ARM depends on ARM EABI, would we really need this "if !AEABI"?
> (I doubt we need these default...)
>
> > help
> > This determines which method will be used for unwinding kernel stack
> > traces for panics, oopses, bugs, warnings, perf, /proc//stack,
> > @@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
> >
> > config UNWINDER_ARM
> > bool "ARM EABI stack unwinder"
> > - depends on AEABI
> > + depends on AEABI && !FUNCTION_GRAPH_TRACER
>
> Hmm, AFAIK, FUNCTION_GRAPH_TRACER only depends on FRAME_POINTER, but not
> UNWINDER_FRAME_POINTER. So can user still choose UNWINDER_ARM even if
> FUNCTION_GRAPH_TRACER=y ? (Of course that may not be a meaningful option)
The UNWINDER_* options do not control anything except whether
FRAME_POINTER is enabled or not. FRAME_POINTER controls not only
whether we build with frame pointers, but also how we unwind.
If both ARM_UNWIND and FRAME_POINTER are set, the kernel will
fail to link due to a multiple definition of unwind_frame().
The UNWINDER_* symbols were added in the commit you referenced
merely to select which of ARM_UNWIND or FRAME_POINTER are
enabled.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 6
[PATCH] staging: android: vsoc: fix copy_from_user overrun
The `np->permission' structure is smaller than the `np' structure but
sizeof(*np) worth of data is copied in there. Fix the size passed to
copy_from_user() to avoid overrun.
Fixes: 3d2ec9dcd5539d42 ("staging: Android: Add 'vsoc' driver for cuttlefish.")
Signed-off-by: Vincent Stehlé
Cc: Greg Kroah-Hartman
---
drivers/staging/android/vsoc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 8a75bd27c4133..00a1ec7b91549 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -259,7 +259,8 @@ do_create_fd_scoped_permission(struct vsoc_device_region
*region_p,
atomic_t *owner_ptr = NULL;
struct vsoc_device_region *managed_region_p;
- if (copy_from_user(&np->permission, &arg->perm, sizeof(*np)) ||
+ if (copy_from_user(&np->permission,
+ &arg->perm, sizeof(np->permission)) ||
copy_from_user(&managed_fd,
&arg->managed_region_fd, sizeof(managed_fd))) {
return -EFAULT;
--
2.20.1
Re: [PATCH 04/12] phy: tegra: add missing of_node_put after of_device_is_available
> @@ -260,8 +260,10 @@ tegra_xusb_pad_create(struct tegra_xusb_
> int err;
>
> np = tegra_xusb_find_pad_node(padctl, soc->name);
> - if (!np || !of_device_is_available(np))
> + if (!np || !of_device_is_available(np)) {
> + of_node_put(np);
> return NULL;
> + }
>
> pad = soc->ops->probe(padctl, soc, np);
> if (IS_ERR(pad)) {
How do you think about to move this function call to an additional jump target
for the desired exception handling?
Regards,
Markus
[GIT PULL 1/3] ARM: dts: exynos: Changes for v5.2
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.2 for you to fetch changes up to 8cc76b1c75722196fb3d7ffe67cbfeb721a7b0e3: ARM: dts: exynos: Remove console argument from bootargs (2019-04-10 18:13:31 +0200) Samsung DTS ARM changes for v5.2 1. Use proper ADC on Exynos4412. 2. Extend the Exynos5420 Arndale Octa board with: CPU cooling maps, unused regulators, ADC and UHS-I SD card support. Beside that adjust regulators to proper level and add always-on when needed. 3. Extend the Exynos5260: high speed I2C and proper external interrupts. Also fix shared external interrupt line and use better PLL for MMC clocks. 4. Fix audio recording (broken around v5.1) and microphone recording (since v4.14) on Exynos5422 Odroid XU3 boards. 5. Minor cleanups (stdout-path and bootargs). Benjamin Drung (1): ARM: dts: exynos: Fix spelling mistake of EXYNOS5420 Krzysztof Kozlowski (13): ARM: dts: exynos: Use ADC for Exynos4x12 on Exynos4412 ARM: dts: exynos: Document regulator used by ADC on Odroid U3 ARM: dts: exynos: Use stdout path property on Arndale Octa board ARM: dts: exynos: Add unused PMIC regulators on Arndale Octa board ARM: dts: exynos: Add CPU cooling on Arndale Octa ARM: dts: exynos: Order nodes alphabetically in Arndale Octa ARM: dts: exynos: Enable ADC on Arndale Octa ARM: dts: exynos: Adjust ldo23 and ldo27 to lower levels on Arndale Octa ARM: dts: exynos: Add support for UHS-I SD cards on Arndale Octa ARM: dts: exynos: Extend the eMMC node on Arndale Octa ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa ARM: dts: exynos: Use stdout-path property instead of console in bootargs ARM: dts: exynos: Remove console argument from bootargs Stuart Menefy (4): ARM: dts: exynos: Use bustop PLL as the source for MMC clocks on Exynos5260 ARM: dts: exynos: Add high speed I2C ports for Exynos5260 ARM: dts: exynos: Add interrupts for dedicated EINTs on Exynos5260 ARM: dts: exynos: Fix interrupt for shared EINTs on Exynos5260 Sylwester Nawrocki (2): ARM: dts: exynos: Fix audio routing on Odroid XU3 ARM: dts: exynos: Fix audio (microphone) routing on Odroid XU3 arch/arm/boot/dts/exynos4210-origen.dts | 4 +- arch/arm/boot/dts/exynos4210-smdkv310.dts | 4 +- arch/arm/boot/dts/exynos4210-trats.dts| 4 +- arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 + arch/arm/boot/dts/exynos4412-origen.dts | 3 +- arch/arm/boot/dts/exynos4412-smdk4412.dts | 4 +- arch/arm/boot/dts/exynos4412-trats2.dts | 3 +- arch/arm/boot/dts/exynos4412.dtsi | 2 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 3 +- arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 16 + arch/arm/boot/dts/exynos5260-xyref5260.dts| 2 +- arch/arm/boot/dts/exynos5260.dtsi | 82 - arch/arm/boot/dts/exynos5410-smdk5410.dts | 2 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 364 +- arch/arm/boot/dts/exynos5420-smdk5420.dts | 3 +- arch/arm/boot/dts/exynos5420.dtsi | 2 +- arch/arm/boot/dts/exynos5422-odroidxu3-audio.dtsi | 5 +- 18 files changed, 477 insertions(+), 35 deletions(-)
[GIT PULL 2/3] arm64: dts: exynos: Changes for v5.2
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.2 for you to fetch changes up to 77fc46976e0bfcd78d30fb4c9f0169752b4339c9: arm64: dts: exynos: Add SlimSSS to Exynos5433 (2019-03-20 19:29:57 +0100) Samsung DTS ARM64 changes for v5.2 1. Use proper clock rates for GSCALER module on TM2 boards. 2. Add clocks for local paths on DECON and GSCALER modules of Exynos5433. 3. Add Slim SecuritySubSystem to Exynos5433. Andrzej Hajda (2): arm64: dts: exynos: configure GSCALER related clocks on TM2 arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs of Exynos5433 Kamil Konieczny (1): arm64: dts: exynos: Add SlimSSS to Exynos5433 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 ++-- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 34 +++--- 3 files changed, 34 insertions(+), 12 deletions(-)
[GIT PULL 3/3] ARM: samsung: Changes for v5.2
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-5.2 for you to fetch changes up to 7676e667c841375b41d9438b559756141aa93d0e: ARM: s3c64xx: Tidy up handling of regulator GPIO lookups (2019-04-14 12:53:03 +0200) Samsung mach/soc changes for v5.2 1. Cleanup in mach code. 2. Add necessary fixes for Suspend to RAM on Exynos5422 boards (tested with Odroid XU3/XU4/HC1 family). Finally this brings a working S2R on these Odroid boards (still other drivers might have some issues but mach code seems to be finished). 3. Require MCPM for Exynos542x boards because otherwise not all of cores will come online. 4. GPIO regulator cleanup on S3C6410 Craig. Charles Keepax (1): ARM: s3c64xx: Tidy up handling of regulator GPIO lookups Joonyoung Shim (1): ARM: exynos: Add CPU state management for Exynos542x under secure firmware Marek Szyprowski (5): ARM: exynos: Move Exynos542x CPU state reset to pm_prepare() ARM: exynos: Add Exynos SMC values for secure memory write ARM: exynos: Fix undefined instruction during Exynos5422 resume ARM: exynos: Fix infinite loops on CPU powerup failure ARM: exynos: Set MCPM as mandatory for Exynos542x/5800 SoCs Wen Yang (1): ARM: exynos: Fix a leaked reference by adding missing of_node_put arch/arm/configs/exynos_defconfig| 1 - arch/arm/configs/multi_v7_defconfig | 1 - arch/arm/mach-exynos/Kconfig | 12 ++- arch/arm/mach-exynos/Makefile| 2 +- arch/arm/mach-exynos/common.h| 1 + arch/arm/mach-exynos/exynos.c| 3 ++ arch/arm/mach-exynos/firmware.c | 1 + arch/arm/mach-exynos/mcpm-exynos.c | 13 +++- arch/arm/mach-exynos/platsmp.c | 9 - arch/arm/mach-exynos/smc.h | 7 arch/arm/mach-exynos/suspend.c | 49 arch/arm/mach-s3c64xx/mach-crag6410-module.c | 14 ++-- 12 files changed, 89 insertions(+), 24 deletions(-)
[RESEND PATCH] drivers/iio/gyro/mpu3050-core.c: This patch fix the following checkpatch warning.
As per Documentation/timers/timers-howto.txt Msleep < 20ms can sleep for up to 20ms. so use usleep_range. Signed-off-by: Mohan Kumar --- drivers/iio/gyro/mpu3050-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c index 85b7ac4..0a40616 100644 --- a/drivers/iio/gyro/mpu3050-core.c +++ b/drivers/iio/gyro/mpu3050-core.c @@ -865,7 +865,7 @@ static int mpu3050_power_up(struct mpu3050 *mpu3050) dev_err(mpu3050->dev, "error setting power mode\n"); return ret; } - msleep(10); + usleep_range(1, 2); return 0; } -- 2.7.4
[patch V3 00/32] x86: Add guard pages to exception and interrupt stacks
Hi!
This is an updated version of the guard page series:
V1: https://lkml.kernel.org/r/20190331214020.836098...@linutronix.de
V2: https://lkml.kernel.org/r/20190405150658.237064...@linutronix.de
Changes vs. V2:
- Fixed the broken stack trace storage in slub
- Adjust the guard page ordering and fix the top macro (Sean)
- Fix an off by one in the debug stack check (Sean)
- Rename ISTACK_ prefix to ESTACK_ (Josh)
- Collected Acked/Reviewed-by tags
The lot is also available from tip:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/stackguards
310a7f5b0b42 ("x86/irq/64: Remove stack overflow debug code")
Thanks,
tglx
8<-
Documentation/x86/kernel-stacks | 13 +++-
arch/x86/Kconfig |2
arch/x86/entry/entry_64.S | 16 ++---
arch/x86/include/asm/cpu_entry_area.h | 69 +--
arch/x86/include/asm/debugreg.h |2
arch/x86/include/asm/irq.h|6 --
arch/x86/include/asm/page_32_types.h |8 +-
arch/x86/include/asm/page_64_types.h | 16 ++---
arch/x86/include/asm/processor.h | 43 +-
arch/x86/include/asm/smp.h|2
arch/x86/include/asm/stackprotector.h |6 +-
arch/x86/include/asm/stacktrace.h |2
arch/x86/kernel/asm-offsets_64.c |4 +
arch/x86/kernel/cpu/common.c | 60 +++-
arch/x86/kernel/dumpstack_32.c|8 +-
arch/x86/kernel/dumpstack_64.c| 99 +++---
arch/x86/kernel/head_64.S |2
arch/x86/kernel/idt.c | 19 +++---
arch/x86/kernel/irq_32.c | 41 +++---
arch/x86/kernel/irq_64.c | 89 +++---
arch/x86/kernel/irqinit.c |4 -
arch/x86/kernel/nmi.c | 20 ++
arch/x86/kernel/setup_percpu.c|5 -
arch/x86/kernel/smpboot.c | 15 -
arch/x86/kernel/vmlinux.lds.S |7 +-
arch/x86/mm/cpu_entry_area.c | 64 +++--
arch/x86/mm/fault.c |3 -
arch/x86/tools/relocs.c |2
arch/x86/xen/smp_pv.c |4 +
arch/x86/xen/xen-head.S | 10 +--
drivers/xen/events/events_base.c |1
mm/slab.c | 30 --
32 files changed, 382 insertions(+), 290 deletions(-)
How are you beautiful
I hope you had a lovely night, and you having a wonderful weekend.It is my pleasure meeting you. Am sorry to bother you, i apologize for intruding upon your privacy. My name is Wesley. I`m from the State. I am currently looking for a relationship in which I feel loved. I hope you will be kind enough to tell me more about yourself, if you don't mind. I`ll be anticipating for your kind reply. I wish you a awesome day and perfect mood. With respect, Wesley.
Re: [PATCH] proc: fix map_files test on F29
On Sun, Apr 14, 2019 at 08:24:53AM -0700, Randy Dunlap wrote: > On 4/14/19 5:36 AM, Alexey Dobriyan wrote: > > F29 bans mapping first 64KB even for root making test fail. > > so there is an F29-only patch that prevents that? > something that is not in mainline? Ehh, no. F29 ships stable kernels actually. Test assumes mmap(0, MAP_FIXED) succeeds as root. F29 uses SELinux to ban that.
[patch V3 01/32] mm/slab: Fix broken stack trace storage
kstack_end() is broken on interrupt stacks as they are not guaranteed to be
sized THREAD_SIZE and THREAD_SIZE aligned.
Use the stack tracer instead. Remove the pointless pointer increment at the
end of the function while at it.
Fixes: 98eb235b7feb ("[PATCH] page unmapping debug") - History tree
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Pekka Enberg
Cc: linux...@kvack.org
---
mm/slab.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1470,33 +1470,29 @@ static bool is_debug_pagealloc_cache(str
static void store_stackinfo(struct kmem_cache *cachep, unsigned long *addr,
unsigned long caller)
{
- int size = cachep->object_size;
+ int size = cachep->object_size / sizeof(unsigned long);
addr = (unsigned long *)&((char *)addr)[obj_offset(cachep)];
- if (size < 5 * sizeof(unsigned long))
+ if (size < 5)
return;
*addr++ = 0x12345678;
*addr++ = caller;
*addr++ = smp_processor_id();
- size -= 3 * sizeof(unsigned long);
+#ifdef CONFIG_STACKTRACE
{
- unsigned long *sptr = &caller;
- unsigned long svalue;
-
- while (!kstack_end(sptr)) {
- svalue = *sptr++;
- if (kernel_text_address(svalue)) {
- *addr++ = svalue;
- size -= sizeof(unsigned long);
- if (size <= sizeof(unsigned long))
- break;
- }
- }
+ struct stack_trace trace = {
+ .max_entries= size - 4;
+ .entries= addr;
+ .skip = 3;
+ };
+ save_stack_trace(&trace);
+ addr += trace.nr_entries;
}
- *addr++ = 0x87654321;
+#endif
+ *addr = 0x87654321;
}
static void slab_kernel_map(struct kmem_cache *cachep, void *objp,
[patch V3 08/32] x86/exceptions: Remove unused stack defines on 32bit
Nothing requires those for 32bit builds. Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/page_32_types.h |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) --- a/arch/x86/include/asm/page_32_types.h +++ b/arch/x86/include/asm/page_32_types.h @@ -22,11 +22,7 @@ #define THREAD_SIZE_ORDER 1 #define THREAD_SIZE(PAGE_SIZE << THREAD_SIZE_ORDER) -#define DOUBLEFAULT_STACK 1 -#define NMI_STACK 0 -#define DEBUG_STACK 0 -#define MCE_STACK 0 -#define N_EXCEPTION_STACKS 1 +#define N_EXCEPTION_STACKS 1 #ifdef CONFIG_X86_PAE /*
[patch V3 04/32] x86/irq/64: Remove a hardcoded irq_stack_union access
From: Andy Lutomirski stack_overflow_check() is using both irq_stack_ptr and irq_stack_union to find the IRQ stack. That's going to break when vmapped irq stacks are introduced. Change it to just use irq_stack_ptr. Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Reviewed-by: Sean Christopherson --- arch/x86/kernel/irq_64.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/kernel/irq_64.c +++ b/arch/x86/kernel/irq_64.c @@ -55,9 +55,8 @@ static inline void stack_overflow_check( regs->sp <= curbase + THREAD_SIZE) return; - irq_stack_top = (u64)this_cpu_ptr(irq_stack_union.irq_stack) + - STACK_TOP_MARGIN; irq_stack_bottom = (u64)__this_cpu_read(irq_stack_ptr); + irq_stack_top = irq_stack_bottom - IRQ_STACK_SIZE + STACK_TOP_MARGIN; if (regs->sp >= irq_stack_top && regs->sp <= irq_stack_bottom) return;
[patch V3 21/32] x86/exceptions: Split debug IST stack
The debug IST stack is actually two separate debug stacks to handle #DB recursion. This is required because the CPU starts always at top of stack on exception entry, which means on #DB recursion the second #DB would overwrite the stack of the first. The low level entry code therefore adjusts the top of stack on entry so a secondary #DB starts from a different stack page. But the stack pages are adjacent without a guard page between them. Split the debug stack into 3 stacks which are separated by guard pages. The 3rd stack is never mapped into the cpu_entry_area and is only there to catch triple #DB nesting: --- top of DB_stack <- Initial stack --- end of DB_stack guard page --- top of DB1_stack <- Top of stack after entering first #DB --- end of DB1_stack guard page --- top of DB2_stack <- Top of stack after entering second #DB --- end of DB2_stack guard page If DB2 would not act as the final guard hole, a second #DB would point the top of #DB stack to the stack below #DB1 which would be valid and not catch the not so desired triple nesting. The backing store does not allocate any memory for DB2 and its guard page as it is not going to be mapped into the cpu_entry_area. - Adjust the low level entry code so it adjusts top of #DB with the offset between the stacks instead of exception stack size. - Make the dumpstack code aware of the new stacks. - Adjust the in_debug_stack() implementation and move it into the NMI code where it belongs. As this is NMI hotpath code, it just checks the full area between top of DB_stack and bottom of DB1_stack without checking for the guard page. That's correct because the NMI cannot hit a stackpointer pointing to the guard page between DB and DB1 stack. Even if it would, then the NMI operation still is unaffected, but the resume of the debug exception on the topmost DB stack will crash by touching the guard page. Suggested-by: Andy Lutomirski Signed-off-by: Thomas Gleixner --- V2 -> V3: Fix off by one in in_debug_stack() --- Documentation/x86/kernel-stacks |7 ++- arch/x86/entry/entry_64.S |8 arch/x86/include/asm/cpu_entry_area.h | 14 ++ arch/x86/include/asm/debugreg.h |2 -- arch/x86/include/asm/page_64_types.h |3 --- arch/x86/kernel/asm-offsets_64.c |2 ++ arch/x86/kernel/cpu/common.c | 11 --- arch/x86/kernel/dumpstack_64.c| 12 arch/x86/kernel/nmi.c | 20 +++- arch/x86/mm/cpu_entry_area.c |4 +++- 10 files changed, 52 insertions(+), 31 deletions(-) --- a/Documentation/x86/kernel-stacks +++ b/Documentation/x86/kernel-stacks @@ -76,7 +76,7 @@ The currently assigned IST stacks are :- middle of switching stacks. Using IST for NMI events avoids making assumptions about the previous state of the kernel stack. -* ESTACK_DB. DEBUG_STKSZ +* ESTACK_DB. EXCEPTION_STKSZ (PAGE_SIZE). Used for hardware debug interrupts (interrupt 1) and for software debug interrupts (INT3). @@ -86,6 +86,11 @@ The currently assigned IST stacks are :- avoids making assumptions about the previous state of the kernel stack. + To handle nested #DB correctly there exist two instances of DB stacks. On + #DB entry the IST stackpointer for #DB is switched to the second instance + so a nested #DB starts from a clean stack. The nested #DB switches to + the IST stackpointer to a guard hole to catch triple nesting. + * ESTACK_MCE. EXCEPTION_STKSZ (PAGE_SIZE). Used for interrupt 18 - Machine Check Exception (#MC). --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -879,7 +879,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work * @paranoid == 2 is special: the stub will never switch stacks. This is for * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS. */ -.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 +.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 ist_offset=0 ENTRY(\sym) UNWIND_HINT_IRET_REGS offset=\has_error_code*8 @@ -925,13 +925,13 @@ ENTRY(\sym) .endif .if \shift_ist != -1 - subq$EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist) + subq$\ist_offset, CPU_TSS_IST(\shift_ist) .endif call\do_sym .if \shift_ist != -1 - addq$EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist) + addq$\ist_offset, CPU_TSS_IST(\shift_ist) .endif /* these procedures expect "no swapgs" flag in ebx */ @@ -1129,7 +1129,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \ hv_stimer0_callback_vector hv_stimer0_vector_handler #endif /* CONFIG_HYPERV */ -idtentry debug do_debughas_error_code=0 paranoid=1 shift_ist=IST_INDEX_DB +idtentry debug do
[patch V3 20/32] x86/exceptions: Enable IST guard pages
All usage sites which expected that the exception stacks in the CPU entry
area are mapped linearly are fixed up. Enable guard pages between the
IST stacks.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/cpu_entry_area.h |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/x86/include/asm/cpu_entry_area.h
+++ b/arch/x86/include/asm/cpu_entry_area.h
@@ -26,13 +26,9 @@ struct exception_stacks {
ESTACKS_MEMBERS(0)
};
-/*
- * The effective cpu entry area mapping with guard pages. Guard size is
- * zero until the code which makes assumptions about linear mappings is
- * cleaned up.
- */
+/* The effective cpu entry area mapping with guard pages. */
struct cea_exception_stacks {
- ESTACKS_MEMBERS(0)
+ ESTACKS_MEMBERS(PAGE_SIZE)
};
/*
[patch V3 26/32] x86/irq/64: Rename irq_stack_ptr to hardirq_stack_ptr
Preparatory patch to share code with 32bit.
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/entry_64.S|2 +-
arch/x86/include/asm/processor.h |2 +-
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/kernel/dumpstack_64.c |2 +-
arch/x86/kernel/irq_64.c |2 +-
arch/x86/kernel/setup_percpu.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -431,7 +431,7 @@ END(irq_entries_start)
*/
movq\old_rsp, PER_CPU_VAR(irq_stack_union + IRQ_STACK_SIZE - 8)
- movqPER_CPU_VAR(irq_stack_ptr), %rsp
+ movqPER_CPU_VAR(hardirq_stack_ptr), %rsp
#ifdef CONFIG_DEBUG_ENTRY
/*
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -396,7 +396,7 @@ static inline unsigned long cpu_kernelmo
return (unsigned long)per_cpu(irq_stack_union.gs_base, cpu);
}
-DECLARE_PER_CPU(char *, irq_stack_ptr);
+DECLARE_PER_CPU(char *, hardirq_stack_ptr);
DECLARE_PER_CPU(unsigned int, irq_count);
extern asmlinkage void ignore_sysret(void);
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1510,7 +1510,7 @@ DEFINE_PER_CPU(struct task_struct *, cur
&init_task;
EXPORT_PER_CPU_SYMBOL(current_task);
-DEFINE_PER_CPU(char *, irq_stack_ptr) =
+DEFINE_PER_CPU(char *, hardirq_stack_ptr) =
init_per_cpu_var(irq_stack_union.irq_stack) + IRQ_STACK_SIZE;
DEFINE_PER_CPU(unsigned int, irq_count) __visible = -1;
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -120,7 +120,7 @@ static bool in_exception_stack(unsigned
static bool in_irq_stack(unsigned long *stack, struct stack_info *info)
{
- unsigned long *end = (unsigned long *)this_cpu_read(irq_stack_ptr);
+ unsigned long *end = (unsigned long
*)this_cpu_read(hardirq_stack_ptr);
unsigned long *begin = end - (IRQ_STACK_SIZE / sizeof(long));
/*
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -56,7 +56,7 @@ static inline void stack_overflow_check(
regs->sp <= curbase + THREAD_SIZE)
return;
- irq_stack_top = (u64)__this_cpu_read(irq_stack_ptr);
+ irq_stack_top = (u64)__this_cpu_read(hardirq_stack_ptr);
irq_stack_bottom = irq_stack_top - IRQ_STACK_SIZE + STACK_MARGIN;
if (regs->sp >= irq_stack_bottom && regs->sp <= irq_stack_top)
return;
--- a/arch/x86/kernel/setup_percpu.c
+++ b/arch/x86/kernel/setup_percpu.c
@@ -245,7 +245,7 @@ void __init setup_per_cpu_areas(void)
early_per_cpu_map(x86_cpu_to_logical_apicid, cpu);
#endif
#ifdef CONFIG_X86_64
- per_cpu(irq_stack_ptr, cpu) =
+ per_cpu(hardirq_stack_ptr, cpu) =
per_cpu(irq_stack_union.irq_stack, cpu) +
IRQ_STACK_SIZE;
#endif
[patch V3 05/32] x86/irq/64: Sanitize the top/bottom confusion
On x86 stacks go top to bottom, but the stack overflow check uses it the
other way round, which is just confusing. Clean it up and sanitize the
warning string a bit.
Signed-off-by: Thomas Gleixner
Reviewed-by: Sean Christopherson
---
arch/x86/kernel/irq_64.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -42,7 +42,7 @@ int sysctl_panic_on_stackoverflow;
static inline void stack_overflow_check(struct pt_regs *regs)
{
#ifdef CONFIG_DEBUG_STACKOVERFLOW
-#define STACK_TOP_MARGIN 128
+#define STACK_MARGIN 128
struct orig_ist *oist;
u64 irq_stack_top, irq_stack_bottom;
u64 estack_top, estack_bottom;
@@ -51,25 +51,25 @@ static inline void stack_overflow_check(
if (user_mode(regs))
return;
- if (regs->sp >= curbase + sizeof(struct pt_regs) + STACK_TOP_MARGIN &&
+ if (regs->sp >= curbase + sizeof(struct pt_regs) + STACK_MARGIN &&
regs->sp <= curbase + THREAD_SIZE)
return;
- irq_stack_bottom = (u64)__this_cpu_read(irq_stack_ptr);
- irq_stack_top = irq_stack_bottom - IRQ_STACK_SIZE + STACK_TOP_MARGIN;
- if (regs->sp >= irq_stack_top && regs->sp <= irq_stack_bottom)
+ irq_stack_top = (u64)__this_cpu_read(irq_stack_ptr);
+ irq_stack_bottom = irq_stack_top - IRQ_STACK_SIZE + STACK_MARGIN;
+ if (regs->sp >= irq_stack_bottom && regs->sp <= irq_stack_top)
return;
oist = this_cpu_ptr(&orig_ist);
- estack_bottom = (u64)oist->ist[DEBUG_STACK];
- estack_top = estack_bottom - DEBUG_STKSZ + STACK_TOP_MARGIN;
- if (regs->sp >= estack_top && regs->sp <= estack_bottom)
+ estack_top = (u64)oist->ist[DEBUG_STACK];
+ estack_bottom = estack_top - DEBUG_STKSZ + STACK_MARGIN;
+ if (regs->sp >= estack_bottom && regs->sp <= estack_top)
return;
- WARN_ONCE(1, "do_IRQ(): %s has overflown the kernel stack
(cur:%Lx,sp:%lx,irq stk top-bottom:%Lx-%Lx,exception stk
top-bottom:%Lx-%Lx,ip:%pF)\n",
+ WARN_ONCE(1, "do_IRQ(): %s has overflown the kernel stack
(cur:%Lx,sp:%lx, irq stack:%Lx-%Lx, exception stack: %Lx-%Lx, ip:%pF)\n",
current->comm, curbase, regs->sp,
- irq_stack_top, irq_stack_bottom,
- estack_top, estack_bottom, (void *)regs->ip);
+ irq_stack_bottom, irq_stack_top,
+ estack_bottom, estack_top, (void *)regs->ip);
if (sysctl_panic_on_stackoverflow)
panic("low stack detected by irq handler - check messages\n");
[patch V3 15/32] x86/irq/64: Use cpu entry area instead of orig_ist
The orig_ist[] array is a shadow copy of the IST array in the TSS. The
reason why it exists is that older kernels used two TSS variants with
different pointers into the debug stack. orig_ist[] contains the real
starting points.
There is no point anymore to do so because the same information can be
retrieved using the base address of the cpu entry area mapping and the
offsets of the various exception stacks.
No functional change. Preparation for removing orig_ist.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/irq_64.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -18,6 +18,8 @@
#include
#include
#include
+
+#include
#include
#include
@@ -43,10 +45,9 @@ static inline void stack_overflow_check(
{
#ifdef CONFIG_DEBUG_STACKOVERFLOW
#define STACK_MARGIN 128
- struct orig_ist *oist;
- u64 irq_stack_top, irq_stack_bottom;
- u64 estack_top, estack_bottom;
+ u64 irq_stack_top, irq_stack_bottom, estack_top, estack_bottom;
u64 curbase = (u64)task_stack_page(current);
+ struct cea_exception_stacks *estacks;
if (user_mode(regs))
return;
@@ -60,9 +61,9 @@ static inline void stack_overflow_check(
if (regs->sp >= irq_stack_bottom && regs->sp <= irq_stack_top)
return;
- oist = this_cpu_ptr(&orig_ist);
- estack_top = (u64)oist->ist[ESTACK_DB];
- estack_bottom = estack_top - DEBUG_STKSZ + STACK_MARGIN;
+ estacks = __this_cpu_read(cea_exception_stacks);
+ estack_top = CEA_ESTACK_TOP(estacks, DB);
+ estack_bottom = CEA_ESTACK_BOT(estacks, DB) + STACK_MARGIN;
if (regs->sp >= estack_bottom && regs->sp <= estack_top)
return;
[patch V3 03/32] x86/dumpstack: Fix off-by-one errors in stack identification
From: Andy Lutomirski The get_stack_info() function is off-by-one when checking whether an address is on a IRQ stack or a IST stack. This prevents a overflowed IRQ or IST stack from being dumped properly. [ tglx: Do the same for 32-bit ] Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Reviewed-by: Sean Christopherson Cc: Josh Poimboeuf --- arch/x86/kernel/dumpstack_32.c |4 ++-- arch/x86/kernel/dumpstack_64.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/dumpstack_32.c +++ b/arch/x86/kernel/dumpstack_32.c @@ -41,7 +41,7 @@ static bool in_hardirq_stack(unsigned lo * This is a software stack, so 'end' can be a valid stack pointer. * It just means the stack is empty. */ - if (stack <= begin || stack > end) + if (stack < begin || stack > end) return false; info->type = STACK_TYPE_IRQ; @@ -66,7 +66,7 @@ static bool in_softirq_stack(unsigned lo * This is a software stack, so 'end' can be a valid stack pointer. * It just means the stack is empty. */ - if (stack <= begin || stack > end) + if (stack < begin || stack > end) return false; info->type = STACK_TYPE_SOFTIRQ; --- a/arch/x86/kernel/dumpstack_64.c +++ b/arch/x86/kernel/dumpstack_64.c @@ -65,7 +65,7 @@ static bool in_exception_stack(unsigned begin = end - (exception_stack_sizes[k] / sizeof(long)); regs = (struct pt_regs *)end - 1; - if (stack <= begin || stack >= end) + if (stack < begin || stack >= end) continue; info->type = STACK_TYPE_EXCEPTION + k; @@ -88,7 +88,7 @@ static bool in_irq_stack(unsigned long * * This is a software stack, so 'end' can be a valid stack pointer. * It just means the stack is empty. */ - if (stack <= begin || stack > end) + if (stack < begin || stack >= end) return false; info->type = STACK_TYPE_IRQ;
[patch V3 18/32] x86/cpu: Remove orig_ist array
All users gone.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h |9 -
arch/x86/kernel/cpu/common.c |6 --
2 files changed, 15 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -374,16 +374,7 @@ DECLARE_PER_CPU(unsigned long, cpu_curre
#define cpu_current_top_of_stack cpu_tss_rw.x86_tss.sp1
#endif
-/*
- * Save the original ist values for checking stack pointers during debugging
- */
-struct orig_ist {
- unsigned long ist[7];
-};
-
#ifdef CONFIG_X86_64
-DECLARE_PER_CPU(struct orig_ist, orig_ist);
-
union irq_stack_union {
char irq_stack[IRQ_STACK_SIZE];
/*
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1549,12 +1549,6 @@ void syscall_init(void)
X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
}
-/*
- * Copies of the original ist values from the tss are only accessed during
- * debugging, no special alignment required.
- */
-DEFINE_PER_CPU(struct orig_ist, orig_ist);
-
static DEFINE_PER_CPU(unsigned long, debug_stack_addr);
DEFINE_PER_CPU(int, debug_stack_usage);
[patch V3 24/32] x86/irq/32: Make irq stack a character array
There is no reason to have an u32 array in struct irq_stack. The only
purpose of the array is to size the struct properly.
Preparatory change for sharing struct irq_stack with 64-bit.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -422,7 +422,7 @@ DECLARE_PER_CPU_ALIGNED(struct stack_can
* per-CPU IRQ handling stacks
*/
struct irq_stack {
- u32 stack[IRQ_STACK_SIZE / sizeof(u32)];
+ charstack[IRQ_STACK_SIZE];
} __aligned(IRQ_STACK_SIZE);
DECLARE_PER_CPU(struct irq_stack *, hardirq_stack);
[patch V3 19/32] x86/exceptions: Disconnect IST index and stack order
The entry order of the TSS.IST array and the order of the stack
storage/mapping are not required to be the same.
With the upcoming split of the debug stack this is going to fall apart as
the number of TSS.IST array entries stays the same while the actual stacks
are increasing.
Make them separate so that code like dumpstack can just utilize the mapping
order. The IST index is solely required for the actual TSS.IST array
initialization.
Signed-off-by: Thomas Gleixner
---
V2 -> V3: s/ISTACK_/ESTACK/
---
arch/x86/entry/entry_64.S |2 +-
arch/x86/include/asm/cpu_entry_area.h | 11 +++
arch/x86/include/asm/page_64_types.h |9 -
arch/x86/include/asm/stacktrace.h |2 ++
arch/x86/kernel/cpu/common.c | 10 +-
arch/x86/kernel/idt.c |8
6 files changed, 27 insertions(+), 15 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1129,7 +1129,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
hv_stimer0_callback_vector hv_stimer0_vector_handler
#endif /* CONFIG_HYPERV */
-idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=ESTACK_DB
+idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=IST_INDEX_DB
idtentry int3 do_int3 has_error_code=0
idtentry stack_segment do_stack_segmenthas_error_code=1
--- a/arch/x86/include/asm/cpu_entry_area.h
+++ b/arch/x86/include/asm/cpu_entry_area.h
@@ -35,6 +35,17 @@ struct cea_exception_stacks {
ESTACKS_MEMBERS(0)
};
+/*
+ * The exception stack ordering in [cea_]exception_stacks
+ */
+enum exception_stack_ordering {
+ ESTACK_DF,
+ ESTACK_NMI,
+ ESTACK_DB,
+ ESTACK_MCE,
+ N_EXCEPTION_STACKS
+};
+
#define CEA_ESTACK_SIZE(st)\
sizeof(((struct cea_exception_stacks *)0)->st## _stack)
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -27,11 +27,10 @@
/*
* The index for the tss.ist[] array. The hardware limit is 7 entries.
*/
-#defineESTACK_DF 0
-#defineESTACK_NMI 1
-#defineESTACK_DB 2
-#defineESTACK_MCE 3
-#defineN_EXCEPTION_STACKS 4
+#defineIST_INDEX_DF0
+#defineIST_INDEX_NMI 1
+#defineIST_INDEX_DB2
+#defineIST_INDEX_MCE 3
/*
* Set __PAGE_OFFSET to the most negative possible address +
--- a/arch/x86/include/asm/stacktrace.h
+++ b/arch/x86/include/asm/stacktrace.h
@@ -9,6 +9,8 @@
#include
#include
+
+#include
#include
enum stack_type {
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1731,11 +1731,11 @@ void cpu_init(void)
* set up and load the per-CPU TSS
*/
if (!t->x86_tss.ist[0]) {
- t->x86_tss.ist[ESTACK_DF] = __this_cpu_ist_top_va(DF);
- t->x86_tss.ist[ESTACK_NMI] = __this_cpu_ist_top_va(NMI);
- t->x86_tss.ist[ESTACK_DB] = __this_cpu_ist_top_va(DB);
- t->x86_tss.ist[ESTACK_MCE] = __this_cpu_ist_top_va(MCE);
- per_cpu(debug_stack_addr, cpu) = t->x86_tss.ist[ESTACK_DB];
+ t->x86_tss.ist[IST_INDEX_DF] = __this_cpu_ist_top_va(DF);
+ t->x86_tss.ist[IST_INDEX_NMI] = __this_cpu_ist_top_va(NMI);
+ t->x86_tss.ist[IST_INDEX_DB] = __this_cpu_ist_top_va(DB);
+ t->x86_tss.ist[IST_INDEX_MCE] = __this_cpu_ist_top_va(MCE);
+ per_cpu(debug_stack_addr, cpu) = t->x86_tss.ist[IST_INDEX_DB];
}
t->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET;
--- a/arch/x86/kernel/idt.c
+++ b/arch/x86/kernel/idt.c
@@ -183,11 +183,11 @@ gate_desc debug_idt_table[IDT_ENTRIES] _
* cpu_init() when the TSS has been initialized.
*/
static const __initconst struct idt_data ist_idts[] = {
- ISTG(X86_TRAP_DB, debug, ESTACK_DB),
- ISTG(X86_TRAP_NMI, nmi,ESTACK_NMI),
- ISTG(X86_TRAP_DF, double_fault, ESTACK_DF),
+ ISTG(X86_TRAP_DB, debug, IST_INDEX_DB),
+ ISTG(X86_TRAP_NMI, nmi,IST_INDEX_NMI),
+ ISTG(X86_TRAP_DF, double_fault, IST_INDEX_DF),
#ifdef CONFIG_X86_MCE
- ISTG(X86_TRAP_MC, &machine_check, ESTACK_MCE),
+ ISTG(X86_TRAP_MC, &machine_check, IST_INDEX_MCE),
#endif
};
[patch V3 13/32] x86/cpu_entry_area: Provide exception stack accessor
Store a pointer to the per cpu entry area exception stack mappings to allow
fast retrieval.
Required for converting various places from using the shadow IST array to
directly doing address calculations on the actual mapping address.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/cpu_entry_area.h |4
arch/x86/mm/cpu_entry_area.c |4
2 files changed, 8 insertions(+)
--- a/arch/x86/include/asm/cpu_entry_area.h
+++ b/arch/x86/include/asm/cpu_entry_area.h
@@ -98,6 +98,7 @@ struct cpu_entry_area {
#define CPU_ENTRY_AREA_TOT_SIZE(CPU_ENTRY_AREA_SIZE * NR_CPUS)
DECLARE_PER_CPU(struct cpu_entry_area *, cpu_entry_area);
+DECLARE_PER_CPU(struct cea_exception_stacks *, cea_exception_stacks);
extern void setup_cpu_entry_areas(void);
extern void cea_set_pte(void *cea_vaddr, phys_addr_t pa, pgprot_t flags);
@@ -117,4 +118,7 @@ static inline struct entry_stack *cpu_en
return &get_cpu_entry_area(cpu)->entry_stack_page.stack;
}
+#define __this_cpu_ist_top_va(name)\
+ CEA_ESTACK_TOP(__this_cpu_read(cea_exception_stacks), name)
+
#endif
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -14,6 +14,7 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(struc
#ifdef CONFIG_X86_64
static DEFINE_PER_CPU_PAGE_ALIGNED(struct exception_stacks, exception_stacks);
+DEFINE_PER_CPU(struct cea_exception_stacks*, cea_exception_stacks);
#endif
struct cpu_entry_area *get_cpu_entry_area(int cpu)
@@ -92,6 +93,9 @@ static void __init percpu_setup_exceptio
unsigned int npages;
BUILD_BUG_ON(sizeof(exception_stacks) % PAGE_SIZE != 0);
+
+ per_cpu(cea_exception_stacks, cpu) = &cea->estacks;
+
/*
* The exceptions stack mappings in the per cpu area are protected
* by guard pages so each stack must be mapped separately.
[patch V3 31/32] x86/irq/64: Remap the IRQ stack with guard pages
From: Andy Lutomirski
The IRQ stack lives in percpu space, so an IRQ handler that overflows it
will overwrite other data structures.
Use vmap() to remap the IRQ stack so that it will have the usual guard
pages that vmap/vmalloc allocations have. With this the kernel will panic
immediately on an IRQ stack overflow.
[ tglx: Move the map code to a proper place and invoke it only when a CPU
is about to be brought online. No point in installing the map at
early boot for all possible CPUs. Fail the CPU bringup if the vmap
fails as done for all other preparatory stages in cpu hotplug. ]
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/irq_64.c | 30 ++
1 file changed, 30 insertions(+)
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -91,6 +91,35 @@ bool handle_irq(struct irq_desc *desc, s
return true;
}
+#ifdef CONFIG_VMAP_STACK
+/*
+ * VMAP the backing store with guard pages
+ */
+static int map_irq_stack(unsigned int cpu)
+{
+ char *stack = (char *)per_cpu_ptr(&irq_stack_backing_store, cpu);
+ struct page *pages[IRQ_STACK_SIZE / PAGE_SIZE];
+ void *va;
+ int i;
+
+ for (i = 0; i < IRQ_STACK_SIZE / PAGE_SIZE; i++) {
+ phys_addr_t pa = per_cpu_ptr_to_phys(stack + (i << PAGE_SHIFT));
+
+ pages[i] = pfn_to_page(pa >> PAGE_SHIFT);
+ }
+
+ va = vmap(pages, IRQ_STACK_SIZE / PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
+ if (!va)
+ return -ENOMEM;
+
+ per_cpu(hardirq_stack_ptr, cpu) = va + IRQ_STACK_SIZE;
+ return 0;
+}
+#else
+/*
+ * If VMAP stacks are disabled due to KASAN, just use the per cpu
+ * backing store without guard pages.
+ */
static int map_irq_stack(unsigned int cpu)
{
void *va = per_cpu_ptr(&irq_stack_backing_store, cpu);
@@ -98,6 +127,7 @@ static int map_irq_stack(unsigned int cp
per_cpu(hardirq_stack_ptr, cpu) = va + IRQ_STACK_SIZE;
return 0;
}
+#endif
int irq_init_percpu_irqstack(unsigned int cpu)
{
[patch V3 32/32] x86/irq/64: Remove stack overflow debug code
All stack types on x86 64-bit have guard pages now.
So there is no point in executing probabilistic overflow checks as the
guard pages are a accurate and reliable overflow prevention.
Signed-off-by: Thomas Gleixner
---
arch/x86/Kconfig |2 -
arch/x86/kernel/irq_64.c | 56 ---
2 files changed, 1 insertion(+), 57 deletions(-)
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -14,6 +14,7 @@ config X86_32
select ARCH_WANT_IPC_PARSE_VERSION
select CLKSRC_I8253
select CLONE_BACKWARDS
+ select HAVE_DEBUG_STACKOVERFLOW
select MODULES_USE_ELF_REL
select OLD_SIGACTION
@@ -138,7 +139,6 @@ config X86
select HAVE_COPY_THREAD_TLS
select HAVE_C_RECORDMCOUNT
select HAVE_DEBUG_KMEMLEAK
- select HAVE_DEBUG_STACKOVERFLOW
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -26,64 +26,8 @@
DEFINE_PER_CPU_PAGE_ALIGNED(struct irq_stack, irq_stack_backing_store)
__visible;
DECLARE_INIT_PER_CPU(irq_stack_backing_store);
-int sysctl_panic_on_stackoverflow;
-
-/*
- * Probabilistic stack overflow check:
- *
- * Regular device interrupts can enter on the following stacks:
- *
- * - User stack
- *
- * - Kernel task stack
- *
- * - Interrupt stack if a device driver reenables interrupts
- * which should only happen in really old drivers.
- *
- * - Debug IST stack
- *
- * All other contexts are invalid.
- */
-static inline void stack_overflow_check(struct pt_regs *regs)
-{
-#ifdef CONFIG_DEBUG_STACKOVERFLOW
-#define STACK_MARGIN 128
- u64 irq_stack_top, irq_stack_bottom, estack_top, estack_bottom;
- u64 curbase = (u64)task_stack_page(current);
- struct cea_exception_stacks *estacks;
-
- if (user_mode(regs))
- return;
-
- if (regs->sp >= curbase + sizeof(struct pt_regs) + STACK_MARGIN &&
- regs->sp <= curbase + THREAD_SIZE)
- return;
-
- irq_stack_top = (u64)__this_cpu_read(hardirq_stack_ptr);
- irq_stack_bottom = irq_stack_top - IRQ_STACK_SIZE + STACK_MARGIN;
- if (regs->sp >= irq_stack_bottom && regs->sp <= irq_stack_top)
- return;
-
- estacks = __this_cpu_read(cea_exception_stacks);
- estack_top = CEA_ESTACK_TOP(estacks, DB);
- estack_bottom = CEA_ESTACK_BOT(estacks, DB) + STACK_MARGIN;
- if (regs->sp >= estack_bottom && regs->sp <= estack_top)
- return;
-
- WARN_ONCE(1, "do_IRQ(): %s has overflown the kernel stack
(cur:%Lx,sp:%lx, irq stack:%Lx-%Lx, exception stack: %Lx-%Lx, ip:%pF)\n",
- current->comm, curbase, regs->sp,
- irq_stack_bottom, irq_stack_top,
- estack_bottom, estack_top, (void *)regs->ip);
-
- if (sysctl_panic_on_stackoverflow)
- panic("low stack detected by irq handler - check messages\n");
-#endif
-}
-
bool handle_irq(struct irq_desc *desc, struct pt_regs *regs)
{
- stack_overflow_check(regs);
-
if (IS_ERR_OR_NULL(desc))
return false;
How are you beautiful
I hope you had a lovely night, and you having a wonderful weekend.It is my pleasure meeting you. Am sorry to bother you, i apologize for intruding upon your privacy. My name is Wesley. I`m from the State. I am currently looking for a relationship in which I feel loved. I hope you will be kind enough to tell me more about yourself, if you don't mind. I`ll be anticipating for your kind reply. I wish you a awesome day and perfect mood. With respect, Wesley.
[patch V3 28/32] x86/irq/32: Handle irq stack allocation failure proper
irq_ctx_init() crashes hard on page allocation failures. While that's ok
during early boot, it's just wrong in the CPU hotplug bringup code.
Check the page allocation failure and return -ENOMEM and handle it at the
call sites. On early boot the only way out is to BUG(), but on CPU hotplug
there is no reason to crash, so just abort the operation.
Rename the function to something more sensible while at it.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq.h |4 ++--
arch/x86/include/asm/smp.h |2 +-
arch/x86/kernel/irq_32.c | 34 +-
arch/x86/kernel/irqinit.c |2 +-
arch/x86/kernel/smpboot.c | 15 ---
arch/x86/xen/smp_pv.c |4 +++-
6 files changed, 36 insertions(+), 25 deletions(-)
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -17,9 +17,9 @@ static inline int irq_canonicalize(int i
}
#ifdef CONFIG_X86_32
-extern void irq_ctx_init(int cpu);
+extern int irq_init_percpu_irqstack(unsigned int cpu);
#else
-# define irq_ctx_init(cpu) do { } while (0)
+static inline int irq_init_percpu_irqstack(unsigned int cpu) { return 0; }
#endif
#define __ARCH_HAS_DO_SOFTIRQ
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -131,7 +131,7 @@ void native_smp_prepare_boot_cpu(void);
void native_smp_prepare_cpus(unsigned int max_cpus);
void calculate_max_logical_packages(void);
void native_smp_cpus_done(unsigned int max_cpus);
-void common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
+int common_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_up(unsigned int cpunum, struct task_struct *tidle);
int native_cpu_disable(void);
int common_cpu_die(unsigned int cpu);
--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
@@ -107,28 +107,28 @@ static inline int execute_on_irq_stack(i
}
/*
- * allocate per-cpu stacks for hardirq and for softirq processing
+ * Allocate per-cpu stacks for hardirq and softirq processing
*/
-void irq_ctx_init(int cpu)
+int irq_init_percpu_irqstack(unsigned int cpu)
{
- struct irq_stack *irqstk;
+ int node = cpu_to_node(cpu);
+ struct page *ph, *ps;
if (per_cpu(hardirq_stack_ptr, cpu))
- return;
+ return 0;
- irqstk = page_address(alloc_pages_node(cpu_to_node(cpu),
- THREADINFO_GFP,
- THREAD_SIZE_ORDER));
- per_cpu(hardirq_stack_ptr, cpu) = irqstk;
-
- irqstk = page_address(alloc_pages_node(cpu_to_node(cpu),
- THREADINFO_GFP,
- THREAD_SIZE_ORDER));
- per_cpu(softirq_stack_ptr, cpu) = irqstk;
-
- pr_debug("CPU %u irqstacks, hard=%p soft=%p\n",
-cpu, per_cpu(hardirq_stack_ptr, cpu),
-per_cpu(softirq_stack_ptr, cpu));
+ ph = alloc_pages_node(node, THREADINFO_GFP, THREAD_SIZE_ORDER);
+ if (!ph)
+ return -ENOMEM;
+ ps = alloc_pages_node(node, THREADINFO_GFP, THREAD_SIZE_ORDER);
+ if (!ps) {
+ __free_pages(ph, THREAD_SIZE_ORDER);
+ return -ENOMEM;
+ }
+
+ per_cpu(hardirq_stack_ptr, cpu) = page_address(ph);
+ per_cpu(softirq_stack_ptr, cpu) = page_address(ps);
+ return 0;
}
void do_softirq_own_stack(void)
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -91,7 +91,7 @@ void __init init_IRQ(void)
for (i = 0; i < nr_legacy_irqs(); i++)
per_cpu(vector_irq, 0)[ISA_IRQ_VECTOR(i)] = irq_to_desc(i);
- irq_ctx_init(smp_processor_id());
+ BUG_ON(irq_init_percpu_irqstack(smp_processor_id()));
x86_init.irqs.intr_init();
}
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -935,20 +935,27 @@ wakeup_cpu_via_init_nmi(int cpu, unsigne
return boot_error;
}
-void common_cpu_up(unsigned int cpu, struct task_struct *idle)
+int common_cpu_up(unsigned int cpu, struct task_struct *idle)
{
+ int ret;
+
/* Just in case we booted with a single CPU. */
alternatives_enable_smp();
per_cpu(current_task, cpu) = idle;
+ /* Initialize the interrupt stack(s) */
+ ret = irq_init_percpu_irqstack(cpu);
+ if (ret)
+ return ret;
+
#ifdef CONFIG_X86_32
/* Stack for startup_32 can be just as for start_secondary onwards */
- irq_ctx_init(cpu);
per_cpu(cpu_current_top_of_stack, cpu) = task_top_of_stack(idle);
#else
initial_gs = per_cpu_offset(cpu);
#endif
+ return 0;
}
/*
@@ -1106,7 +1113,9 @@ int native_cpu_up(unsigned int cpu, stru
/* the FPU context is blank, nobody can own it */
per_cpu(fpu_fpregs_owner_ctx, cpu) = NULL;
- common_cpu_up(cpu, tidle);
+ err = common_cpu_up(cpu, tidle);
+ if (err)
+ return err;
err = do_boot_
[patch V3 22/32] x86/dumpstack/64: Speedup in_exception_stack()
The current implementation of in_exception_stack() iterates over the
exception stacks array. Most of the time this is an useless exercise, but
even for the actual use cases (perf and ftrace) it takes at least 2
iterations to get to the NMI stack.
As the exception stacks and the guard pages are page aligned the loop can
be avoided completely.
Add a initial check whether the stack pointer is inside the full exception
stack area and leave early if not.
Create a lookup table which describes the stack area. The table index is
the page offset from the beginning of the exception stacks. So for any
given stack pointer the page offset is computed and a lookup in the
description table is performed. If it is inside a guard page, return. If
not, use the descriptor to fill in the info structure.
The table is filled at compile time and for the !KASAN case the interesting
page descriptors exactly fit into a single cache line. Just the last guard
page descriptor is in the next cacheline, but that should not be accessed
in the regular case.
Signed-off-by: Thomas Gleixner
Acked-by: Josh Poimboeuf
---
V2: Simplify the macro maze
---
arch/x86/kernel/dumpstack_64.c | 90 +
1 file changed, 55 insertions(+), 35 deletions(-)
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -50,52 +50,72 @@ const char *stack_type_name(enum stack_t
return NULL;
}
-struct estack_layout {
- unsigned intbegin;
- unsigned intend;
+/**
+ * struct estack_pages - Page descriptor for exception stacks
+ * @offs: Offset from the start of the exception stack area
+ * @size: Size of the exception stack
+ * @type: Type to store in the stack_info struct
+ */
+struct estack_pages {
+ u32 offs;
+ u16 size;
+ u16 type;
};
-#defineESTACK_ENTRY(x) {
\
- .begin = offsetof(struct cea_exception_stacks, x## _stack), \
- .end= offsetof(struct cea_exception_stacks, x## _stack_guard) \
- }
-
-static const struct estack_layout layout[] = {
- [ ESTACK_DF ] = ESTACK_ENTRY(DF),
- [ ESTACK_NMI] = ESTACK_ENTRY(NMI),
- [ ESTACK_DB2] = { .begin = 0, .end = 0},
- [ ESTACK_DB1] = ESTACK_ENTRY(DB1),
- [ ESTACK_DB ] = ESTACK_ENTRY(DB),
- [ ESTACK_MCE] = ESTACK_ENTRY(MCE),
+#define EPAGERANGE(st) \
+ [PFN_DOWN(CEA_ESTACK_OFFS(st)) ... \
+PFN_DOWN(CEA_ESTACK_OFFS(st) + CEA_ESTACK_SIZE(st) - 1)] = { \
+ .offs = CEA_ESTACK_OFFS(st), \
+ .size = CEA_ESTACK_SIZE(st), \
+ .type = STACK_TYPE_EXCEPTION + ESTACK_ ##st, }
+
+/*
+ * Array of exception stack page descriptors. If the stack is larger than
+ * PAGE_SIZE, all pages covering a particular stack will have the same
+ * info. The guard pages including the not mapped DB2 stack are zeroed
+ * out.
+ */
+static const
+struct estack_pages estack_pages[CEA_ESTACK_PAGES] cacheline_aligned = {
+ EPAGERANGE(DF),
+ EPAGERANGE(NMI),
+ EPAGERANGE(DB1),
+ EPAGERANGE(DB),
+ EPAGERANGE(MCE),
};
static bool in_exception_stack(unsigned long *stack, struct stack_info *info)
{
- unsigned long estacks, begin, end, stk = (unsigned long)stack;
+ unsigned long begin, end, stk = (unsigned long)stack;
+ const struct estack_pages *ep;
struct pt_regs *regs;
unsigned int k;
BUILD_BUG_ON(N_EXCEPTION_STACKS != 6);
- estacks = (unsigned long)__this_cpu_read(cea_exception_stacks);
-
- for (k = 0; k < N_EXCEPTION_STACKS; k++) {
- begin = estacks + layout[k].begin;
- end = estacks + layout[k].end;
- regs = (struct pt_regs *)end - 1;
-
- if (stk < begin || stk >= end)
- continue;
-
- info->type = STACK_TYPE_EXCEPTION + k;
- info->begin = (unsigned long *)begin;
- info->end = (unsigned long *)end;
- info->next_sp = (unsigned long *)regs->sp;
-
- return true;
- }
-
- return false;
+ begin = (unsigned long)__this_cpu_read(cea_exception_stacks);
+ end = begin + sizeof(struct cea_exception_stacks);
+ /* Bail if @stack is outside the exception stack area. */
+ if (stk < begin || stk >= end)
+ return false;
+
+ /* Calc page offset from start of exception stacks */
+ k = (stk - begin) >> PAGE_SHIFT;
+ /* Lookup the page descriptor */
+ ep = &estack_pages[k];
+ /* Guard page? */
+ if (!ep->size)
+ return false;
+
+ begin += (unsigned long)ep->offs;
+ end = begin + (unsigned long)ep->size;
+
[patch V3 29/32] x86/irq/64: Init hardirq_stack_ptr during CPU hotplug
Preparatory change for distangling the irq stack union as a prerequisite
for irq stacks with guard pages.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq.h |4
arch/x86/kernel/cpu/common.c |4 +---
arch/x86/kernel/irq_64.c | 15 +++
3 files changed, 16 insertions(+), 7 deletions(-)
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -16,11 +16,7 @@ static inline int irq_canonicalize(int i
return ((irq == 2) ? 9 : irq);
}
-#ifdef CONFIG_X86_32
extern int irq_init_percpu_irqstack(unsigned int cpu);
-#else
-static inline int irq_init_percpu_irqstack(unsigned int cpu) { return 0; }
-#endif
#define __ARCH_HAS_DO_SOFTIRQ
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1510,9 +1510,7 @@ DEFINE_PER_CPU(struct task_struct *, cur
&init_task;
EXPORT_PER_CPU_SYMBOL(current_task);
-DEFINE_PER_CPU(char *, hardirq_stack_ptr) =
- init_per_cpu_var(irq_stack_union.irq_stack) + IRQ_STACK_SIZE;
-
+DEFINE_PER_CPU(char *, hardirq_stack_ptr);
DEFINE_PER_CPU(unsigned int, irq_count) __visible = -1;
DEFINE_PER_CPU(int, __preempt_count) = INIT_PREEMPT_COUNT;
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -87,3 +87,18 @@ bool handle_irq(struct irq_desc *desc, s
generic_handle_irq_desc(desc);
return true;
}
+
+static int map_irq_stack(unsigned int cpu)
+{
+ void *va = per_cpu_ptr(irq_stack_union.irq_stack, cpu);
+
+ per_cpu(hardirq_stack_ptr, cpu) = va + IRQ_STACK_SIZE;
+ return 0;
+}
+
+int irq_init_percpu_irqstack(unsigned int cpu)
+{
+ if (per_cpu(hardirq_stack_ptr, cpu))
+ return 0;
+ return map_irq_stack(cpu);
+}
[patch V3 23/32] x86/irq/32: Define IRQ_STACK_SIZE
On 32-bit IRQ_STACK_SIZE is the same as THREAD_SIZE.
To allow sharing struct irq_stack with 32-bit, define IRQ_STACK_SIZE for
32-bit and use of for struct irq_stack.
No functional change.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/page_32_types.h |2 ++
arch/x86/include/asm/processor.h |4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -22,6 +22,8 @@
#define THREAD_SIZE_ORDER 1
#define THREAD_SIZE(PAGE_SIZE << THREAD_SIZE_ORDER)
+#define IRQ_STACK_SIZE THREAD_SIZE
+
#define N_EXCEPTION_STACKS 1
#ifdef CONFIG_X86_PAE
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -422,8 +422,8 @@ DECLARE_PER_CPU_ALIGNED(struct stack_can
* per-CPU IRQ handling stacks
*/
struct irq_stack {
- u32 stack[THREAD_SIZE/sizeof(u32)];
-} __aligned(THREAD_SIZE);
+ u32 stack[IRQ_STACK_SIZE / sizeof(u32)];
+} __aligned(IRQ_STACK_SIZE);
DECLARE_PER_CPU(struct irq_stack *, hardirq_stack);
DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
[patch V3 17/32] x86/cpu: Prepare TSS.IST setup for guard pages
Convert the TSS.IST setup code to use the cpu entry area information
directly instead of assuming a linear mapping of the IST stacks.
The store to orig_ist[] is no longer required as there are no users
anymore.
This is the last preparatory step for IST guard pages.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/common.c | 35 +++
1 file changed, 7 insertions(+), 28 deletions(-)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -507,19 +507,6 @@ void load_percpu_segment(int cpu)
DEFINE_PER_CPU(struct cpu_entry_area *, cpu_entry_area);
#endif
-#ifdef CONFIG_X86_64
-/*
- * Special IST stacks which the CPU switches to when it calls
- * an IST-marked descriptor entry. Up to 7 stacks (hardware
- * limit), all of them are 4K, except the debug stack which
- * is 8K.
- */
-static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
- [0 ... N_EXCEPTION_STACKS - 1]= EXCEPTION_STKSZ,
- [ESTACK_DB] = DEBUG_STKSZ
-};
-#endif
-
/* Load the original GDT from the per-cpu structure */
void load_direct_gdt(int cpu)
{
@@ -1690,17 +1677,14 @@ static void setup_getcpu(int cpu)
* initialized (naturally) in the bootstrap process, such as the GDT
* and IDT. We reload them nevertheless, this function acts as a
* 'CPU state barrier', nothing should get across.
- * A lot of state is already set up in PDA init for 64 bit
*/
#ifdef CONFIG_X86_64
void cpu_init(void)
{
- struct orig_ist *oist;
+ int cpu = raw_smp_processor_id();
struct task_struct *me;
struct tss_struct *t;
- unsigned long v;
- int cpu = raw_smp_processor_id();
int i;
wait_for_master_cpu(cpu);
@@ -1715,7 +1699,6 @@ void cpu_init(void)
load_ucode_ap();
t = &per_cpu(cpu_tss_rw, cpu);
- oist = &per_cpu(orig_ist, cpu);
#ifdef CONFIG_NUMA
if (this_cpu_read(numa_node) == 0 &&
@@ -1753,16 +1736,12 @@ void cpu_init(void)
/*
* set up and load the per-CPU TSS
*/
- if (!oist->ist[0]) {
- char *estacks = (char *)&get_cpu_entry_area(cpu)->estacks;
-
- for (v = 0; v < N_EXCEPTION_STACKS; v++) {
- estacks += exception_stack_sizes[v];
- oist->ist[v] = t->x86_tss.ist[v] =
- (unsigned long)estacks;
- if (v == ESTACK_DB)
- per_cpu(debug_stack_addr, cpu) = (unsigned
long)estacks;
- }
+ if (!t->x86_tss.ist[0]) {
+ t->x86_tss.ist[ESTACK_DF] = __this_cpu_ist_top_va(DF);
+ t->x86_tss.ist[ESTACK_NMI] = __this_cpu_ist_top_va(NMI);
+ t->x86_tss.ist[ESTACK_DB] = __this_cpu_ist_top_va(DB);
+ t->x86_tss.ist[ESTACK_MCE] = __this_cpu_ist_top_va(MCE);
+ per_cpu(debug_stack_addr, cpu) = t->x86_tss.ist[ESTACK_DB];
}
t->x86_tss.io_bitmap_base = IO_BITMAP_OFFSET;
[patch V3 12/32] x86/cpu_entry_area: Prepare for IST guard pages
To allow guard pages between the IST stacks each stack needs to be mapped
individually.
Signed-off-by: Thomas Gleixner
---
arch/x86/mm/cpu_entry_area.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -77,6 +77,34 @@ static void __init percpu_setup_debug_st
#endif
}
+#ifdef CONFIG_X86_64
+
+#define cea_map_stack(name) do { \
+ npages = sizeof(estacks->name## _stack) / PAGE_SIZE;\
+ cea_map_percpu_pages(cea->estacks.name## _stack,\
+ estacks->name## _stack, npages, PAGE_KERNEL); \
+ } while (0)
+
+static void __init percpu_setup_exception_stacks(unsigned int cpu)
+{
+ struct exception_stacks *estacks = per_cpu_ptr(&exception_stacks, cpu);
+ struct cpu_entry_area *cea = get_cpu_entry_area(cpu);
+ unsigned int npages;
+
+ BUILD_BUG_ON(sizeof(exception_stacks) % PAGE_SIZE != 0);
+ /*
+* The exceptions stack mappings in the per cpu area are protected
+* by guard pages so each stack must be mapped separately.
+*/
+ cea_map_stack(DF);
+ cea_map_stack(NMI);
+ cea_map_stack(DB);
+ cea_map_stack(MCE);
+}
+#else
+static inline void percpu_setup_exception_stacks(unsigned int cpu) {}
+#endif
+
/* Setup the fixmap mappings only once per-processor */
static void __init setup_cpu_entry_area(unsigned int cpu)
{
@@ -134,13 +162,8 @@ static void __init setup_cpu_entry_area(
per_cpu(cpu_entry_area, cpu) = cea;
#endif
-#ifdef CONFIG_X86_64
- BUILD_BUG_ON(sizeof(exception_stacks) % PAGE_SIZE != 0);
- BUILD_BUG_ON(sizeof(exception_stacks) !=
-sizeof(((struct cpu_entry_area *)0)->estacks));
- cea_map_percpu_pages(&cea->estacks, &per_cpu(exception_stacks, cpu),
-sizeof(exception_stacks) / PAGE_SIZE, PAGE_KERNEL);
-#endif
+ percpu_setup_exception_stacks(cpu);
+
percpu_setup_debug_store(cpu);
}
[patch V3 07/32] x86/64: Remove stale CURRENT_MASK
Nothing uses that and before people get the wrong ideas, get rid of it. Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/page_64_types.h |1 - 1 file changed, 1 deletion(-) --- a/arch/x86/include/asm/page_64_types.h +++ b/arch/x86/include/asm/page_64_types.h @@ -14,7 +14,6 @@ #define THREAD_SIZE_ORDER (2 + KASAN_STACK_ORDER) #define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER) -#define CURRENT_MASK (~(THREAD_SIZE - 1)) #define EXCEPTION_STACK_ORDER (0 + KASAN_STACK_ORDER) #define EXCEPTION_STKSZ (PAGE_SIZE << EXCEPTION_STACK_ORDER)
[patch V3 00/32] x86: Add guard pages to exception and interrupt stacks
Hi!
This is an updated version of the guard page series:
V1: https://lkml.kernel.org/r/20190331214020.836098...@linutronix.de
V2: https://lkml.kernel.org/r/20190405150658.237064...@linutronix.de
Changes vs. V2:
- Fixed the broken stack trace storage in slub
- Adjust the guard page ordering and fix the top macro (Sean)
- Fix an off by one in the debug stack check (Sean)
- Rename ISTACK_ prefix to ESTACK_ (Josh)
- Collected Acked/Reviewed-by tags
The lot is also available from tip:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/stackguards
310a7f5b0b42 ("x86/irq/64: Remove stack overflow debug code")
Thanks,
tglx
8<-
Documentation/x86/kernel-stacks | 13 +++-
arch/x86/Kconfig |2
arch/x86/entry/entry_64.S | 16 ++---
arch/x86/include/asm/cpu_entry_area.h | 69 +--
arch/x86/include/asm/debugreg.h |2
arch/x86/include/asm/irq.h|6 --
arch/x86/include/asm/page_32_types.h |8 +-
arch/x86/include/asm/page_64_types.h | 16 ++---
arch/x86/include/asm/processor.h | 43 +-
arch/x86/include/asm/smp.h|2
arch/x86/include/asm/stackprotector.h |6 +-
arch/x86/include/asm/stacktrace.h |2
arch/x86/kernel/asm-offsets_64.c |4 +
arch/x86/kernel/cpu/common.c | 60 +++-
arch/x86/kernel/dumpstack_32.c|8 +-
arch/x86/kernel/dumpstack_64.c| 99 +++---
arch/x86/kernel/head_64.S |2
arch/x86/kernel/idt.c | 19 +++---
arch/x86/kernel/irq_32.c | 41 +++---
arch/x86/kernel/irq_64.c | 89 +++---
arch/x86/kernel/irqinit.c |4 -
arch/x86/kernel/nmi.c | 20 ++
arch/x86/kernel/setup_percpu.c|5 -
arch/x86/kernel/smpboot.c | 15 -
arch/x86/kernel/vmlinux.lds.S |7 +-
arch/x86/mm/cpu_entry_area.c | 64 +++--
arch/x86/mm/fault.c |3 -
arch/x86/tools/relocs.c |2
arch/x86/xen/smp_pv.c |4 +
arch/x86/xen/xen-head.S | 10 +--
drivers/xen/events/events_base.c |1
mm/slab.c | 30 --
32 files changed, 382 insertions(+), 290 deletions(-)
[patch V3 25/32] x86/irq/32: Rename hard/softirq_stack to hard/softirq_stack_ptr
The percpu storage holds a pointer to the stack not the stack
itself. Rename it before sharing struct irq_stack with 64-bit.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/processor.h |4 ++--
arch/x86/kernel/dumpstack_32.c |4 ++--
arch/x86/kernel/irq_32.c | 19 ++-
3 files changed, 14 insertions(+), 13 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -425,8 +425,8 @@ struct irq_stack {
charstack[IRQ_STACK_SIZE];
} __aligned(IRQ_STACK_SIZE);
-DECLARE_PER_CPU(struct irq_stack *, hardirq_stack);
-DECLARE_PER_CPU(struct irq_stack *, softirq_stack);
+DECLARE_PER_CPU(struct irq_stack *, hardirq_stack_ptr);
+DECLARE_PER_CPU(struct irq_stack *, softirq_stack_ptr);
#endif /* X86_64 */
extern unsigned int fpu_kernel_xstate_size;
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -34,7 +34,7 @@ const char *stack_type_name(enum stack_t
static bool in_hardirq_stack(unsigned long *stack, struct stack_info *info)
{
- unsigned long *begin = (unsigned long *)this_cpu_read(hardirq_stack);
+ unsigned long *begin = (unsigned long
*)this_cpu_read(hardirq_stack_ptr);
unsigned long *end = begin + (THREAD_SIZE / sizeof(long));
/*
@@ -59,7 +59,7 @@ static bool in_hardirq_stack(unsigned lo
static bool in_softirq_stack(unsigned long *stack, struct stack_info *info)
{
- unsigned long *begin = (unsigned long *)this_cpu_read(softirq_stack);
+ unsigned long *begin = (unsigned long
*)this_cpu_read(softirq_stack_ptr);
unsigned long *end = begin + (THREAD_SIZE / sizeof(long));
/*
--- a/arch/x86/kernel/irq_32.c
+++ b/arch/x86/kernel/irq_32.c
@@ -51,8 +51,8 @@ static inline int check_stack_overflow(v
static inline void print_stack_overflow(void) { }
#endif
-DEFINE_PER_CPU(struct irq_stack *, hardirq_stack);
-DEFINE_PER_CPU(struct irq_stack *, softirq_stack);
+DEFINE_PER_CPU(struct irq_stack *, hardirq_stack_ptr);
+DEFINE_PER_CPU(struct irq_stack *, softirq_stack_ptr);
static void call_on_stack(void *func, void *stack)
{
@@ -76,7 +76,7 @@ static inline int execute_on_irq_stack(i
u32 *isp, *prev_esp, arg1;
curstk = (struct irq_stack *) current_stack();
- irqstk = __this_cpu_read(hardirq_stack);
+ irqstk = __this_cpu_read(hardirq_stack_ptr);
/*
* this is where we switch to the IRQ stack. However, if we are
@@ -113,21 +113,22 @@ void irq_ctx_init(int cpu)
{
struct irq_stack *irqstk;
- if (per_cpu(hardirq_stack, cpu))
+ if (per_cpu(hardirq_stack_ptr, cpu))
return;
irqstk = page_address(alloc_pages_node(cpu_to_node(cpu),
THREADINFO_GFP,
THREAD_SIZE_ORDER));
- per_cpu(hardirq_stack, cpu) = irqstk;
+ per_cpu(hardirq_stack_ptr, cpu) = irqstk;
irqstk = page_address(alloc_pages_node(cpu_to_node(cpu),
THREADINFO_GFP,
THREAD_SIZE_ORDER));
- per_cpu(softirq_stack, cpu) = irqstk;
+ per_cpu(softirq_stack_ptr, cpu) = irqstk;
- printk(KERN_DEBUG "CPU %u irqstacks, hard=%p soft=%p\n",
- cpu, per_cpu(hardirq_stack, cpu), per_cpu(softirq_stack, cpu));
+ pr_debug("CPU %u irqstacks, hard=%p soft=%p\n",
+cpu, per_cpu(hardirq_stack_ptr, cpu),
+per_cpu(softirq_stack_ptr, cpu));
}
void do_softirq_own_stack(void)
@@ -135,7 +136,7 @@ void do_softirq_own_stack(void)
struct irq_stack *irqstk;
u32 *isp, *prev_esp;
- irqstk = __this_cpu_read(softirq_stack);
+ irqstk = __this_cpu_read(softirq_stack_ptr);
/* build the stack frame on the softirq stack */
isp = (u32 *) ((char *)irqstk + sizeof(*irqstk));
[patch V3 30/32] x86/irq/64: Split the IRQ stack into its own pages
From: Andy Lutomirski
Currently the IRQ stack is hardcoded as the first page of the percpu area,
and the stack canary lives on the IRQ stack. The former gets in the way of
adding an IRQ stack guard page, and the latter is a potential weakness in
the stack canary mechanism.
Split the IRQ stack into its own private percpu pages.
[ tglx: Make 64 and 32 bit share struct irq_stack ]
Signed-off-by: Andy Lutomirski
Signed-off-by: Thomas Gleixner
---
arch/x86/entry/entry_64.S |4 ++--
arch/x86/include/asm/processor.h | 32 ++--
arch/x86/include/asm/stackprotector.h |6 +++---
arch/x86/kernel/asm-offsets_64.c |2 +-
arch/x86/kernel/cpu/common.c |8
arch/x86/kernel/head_64.S |2 +-
arch/x86/kernel/irq_64.c |5 -
arch/x86/kernel/setup_percpu.c|5 -
arch/x86/kernel/vmlinux.lds.S |7 ---
arch/x86/tools/relocs.c |2 +-
arch/x86/xen/xen-head.S | 10 +-
11 files changed, 39 insertions(+), 44 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -298,7 +298,7 @@ ENTRY(__switch_to_asm)
#ifdef CONFIG_STACKPROTECTOR
movqTASK_stack_canary(%rsi), %rbx
- movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+ movq%rbx, PER_CPU_VAR(fixed_percpu_data) + stack_canary_offset
#endif
#ifdef CONFIG_RETPOLINE
@@ -430,7 +430,7 @@ END(irq_entries_start)
* it before we actually move ourselves to the IRQ stack.
*/
- movq\old_rsp, PER_CPU_VAR(irq_stack_union + IRQ_STACK_SIZE - 8)
+ movq\old_rsp, PER_CPU_VAR(irq_stack_backing_store + IRQ_STACK_SIZE
- 8)
movqPER_CPU_VAR(hardirq_stack_ptr), %rsp
#ifdef CONFIG_DEBUG_ENTRY
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -367,6 +367,13 @@ DECLARE_PER_CPU_PAGE_ALIGNED(struct tss_
#define __KERNEL_TSS_LIMIT \
(IO_BITMAP_OFFSET + IO_BITMAP_BYTES + sizeof(unsigned long) - 1)
+/* Per CPU interrupt stacks */
+struct irq_stack {
+ charstack[IRQ_STACK_SIZE];
+} __aligned(IRQ_STACK_SIZE);
+
+DECLARE_PER_CPU(struct irq_stack *, hardirq_stack_ptr);
+
#ifdef CONFIG_X86_32
DECLARE_PER_CPU(unsigned long, cpu_current_top_of_stack);
#else
@@ -375,28 +382,24 @@ DECLARE_PER_CPU(unsigned long, cpu_curre
#endif
#ifdef CONFIG_X86_64
-union irq_stack_union {
- char irq_stack[IRQ_STACK_SIZE];
+struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
- struct {
- char gs_base[40];
- unsigned long stack_canary;
- };
+ chargs_base[40];
+ unsigned long stack_canary;
};
-DECLARE_PER_CPU_FIRST(union irq_stack_union, irq_stack_union) __visible;
-DECLARE_INIT_PER_CPU(irq_stack_union);
+DECLARE_PER_CPU_FIRST(struct fixed_percpu_data, fixed_percpu_data) __visible;
+DECLARE_INIT_PER_CPU(fixed_percpu_data);
static inline unsigned long cpu_kernelmode_gs_base(int cpu)
{
- return (unsigned long)per_cpu(irq_stack_union.gs_base, cpu);
+ return (unsigned long)per_cpu(fixed_percpu_data.gs_base, cpu);
}
-DECLARE_PER_CPU(char *, hardirq_stack_ptr);
DECLARE_PER_CPU(unsigned int, irq_count);
extern asmlinkage void ignore_sysret(void);
@@ -418,14 +421,7 @@ struct stack_canary {
};
DECLARE_PER_CPU_ALIGNED(struct stack_canary, stack_canary);
#endif
-/*
- * per-CPU IRQ handling stacks
- */
-struct irq_stack {
- charstack[IRQ_STACK_SIZE];
-} __aligned(IRQ_STACK_SIZE);
-
-DECLARE_PER_CPU(struct irq_stack *, hardirq_stack_ptr);
+/* Per CPU softirq stack pointer */
DECLARE_PER_CPU(struct irq_stack *, softirq_stack_ptr);
#endif /* X86_64 */
--- a/arch/x86/include/asm/stackprotector.h
+++ b/arch/x86/include/asm/stackprotector.h
@@ -13,7 +13,7 @@
* On x86_64, %gs is shared by percpu area and stack canary. All
* percpu symbols are zero based and %gs points to the base of percpu
* area. The first occupant of the percpu area is always
- * irq_stack_union which contains stack_canary at offset 40. Userland
+ * fixed_percpu_data which contains stack_canary at offset 40. Userland
* %gs is always saved and restored on kernel entry and exit using
* swapgs, so stack protector doesn't add any complexity there.
*
@@ -64,7 +64,7 @@ static __always_inline void boot_init_st
u64 tsc;
#ifdef CONFIG_X86_64
- BUILD_BUG_ON(offsetof(union irq_stack_union, stack_canary) != 40);
+ BUILD_BUG_ON(offsetof(struct fixed_percpu_data, stack_canary) != 40);
#endif
/*
* We both use the random pool and the current TSC as a source
@@ -79,7 +79,7 @@ static __always_inline void boot_init_st
current->stack_canary = canary;
[patch V3 02/32] x86/irq/64: Limit IST stack overflow check to #DB stack
commit 37fe6a42b343 ("x86: Check stack overflow in detail") added a broad
check for the full exception stack area, i.e. it considers the full
exception stack area as valid.
That's wrong in two aspects:
1) It does not check the individual areas one by one
2) #DF, NMI and #MCE are not enabling interrupts which means that a
regular device interrupt cannot happen in their context. In fact if a
device interrupt hits one of those IST stacks that's a bug because some
code path enabled interrupts while handling the exception.
Limit the check to the #DB stack and consider all other IST stacks as
'overflow' or invalid.
Signed-off-by: Thomas Gleixner
Cc: Mitsuo Hayasaka
---
arch/x86/kernel/irq_64.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
--- a/arch/x86/kernel/irq_64.c
+++ b/arch/x86/kernel/irq_64.c
@@ -26,9 +26,18 @@ int sysctl_panic_on_stackoverflow;
/*
* Probabilistic stack overflow check:
*
- * Only check the stack in process context, because everything else
- * runs on the big interrupt stacks. Checking reliably is too expensive,
- * so we just check from interrupts.
+ * Regular device interrupts can enter on the following stacks:
+ *
+ * - User stack
+ *
+ * - Kernel task stack
+ *
+ * - Interrupt stack if a device driver reenables interrupts
+ * which should only happen in really old drivers.
+ *
+ * - Debug IST stack
+ *
+ * All other contexts are invalid.
*/
static inline void stack_overflow_check(struct pt_regs *regs)
{
@@ -53,8 +62,8 @@ static inline void stack_overflow_check(
return;
oist = this_cpu_ptr(&orig_ist);
- estack_top = (u64)oist->ist[0] - EXCEPTION_STKSZ + STACK_TOP_MARGIN;
- estack_bottom = (u64)oist->ist[N_EXCEPTION_STACKS - 1];
+ estack_bottom = (u64)oist->ist[DEBUG_STACK];
+ estack_top = estack_bottom - DEBUG_STKSZ + STACK_TOP_MARGIN;
if (regs->sp >= estack_top && regs->sp <= estack_bottom)
return;
[patch V3 16/32] x86/dumpstack/64: Use cpu_entry_area instead of orig_ist
The orig_ist[] array is a shadow copy of the IST array in the TSS. The
reason why it exists is that older kernels used two TSS variants with
different pointers into the debug stack. orig_ist[] contains the real
starting points.
There is no point anymore to do so because the same information can be
retrieved using the base address of the cpu entry area mapping and the
offsets of the various exception stacks.
No functional change. Preparation for removing orig_ist.
Signed-off-by: Thomas Gleixner
Cc: Josh Poimboeuf
---
arch/x86/kernel/dumpstack_64.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
static const char *exception_stack_names[N_EXCEPTION_STACKS] = {
@@ -25,11 +26,6 @@ static const char *exception_stack_names
[ ESTACK_MCE] = "#MC",
};
-static const unsigned long exception_stack_sizes[N_EXCEPTION_STACKS] = {
- [0 ... N_EXCEPTION_STACKS - 1] = EXCEPTION_STKSZ,
- [ESTACK_DB] = DEBUG_STKSZ
-};
-
const char *stack_type_name(enum stack_type type)
{
BUILD_BUG_ON(N_EXCEPTION_STACKS != 4);
@@ -52,25 +48,44 @@ const char *stack_type_name(enum stack_t
return NULL;
}
+struct estack_layout {
+ unsigned intbegin;
+ unsigned intend;
+};
+
+#defineESTACK_ENTRY(x) {
\
+ .begin = offsetof(struct cea_exception_stacks, x## _stack), \
+ .end= offsetof(struct cea_exception_stacks, x## _stack_guard) \
+ }
+
+static const struct estack_layout layout[N_EXCEPTION_STACKS] = {
+ [ ESTACK_DF ] = ESTACK_ENTRY(DF),
+ [ ESTACK_NMI] = ESTACK_ENTRY(NMI),
+ [ ESTACK_DB ] = ESTACK_ENTRY(DB),
+ [ ESTACK_MCE] = ESTACK_ENTRY(MCE),
+};
+
static bool in_exception_stack(unsigned long *stack, struct stack_info *info)
{
- unsigned long *begin, *end;
+ unsigned long estacks, begin, end, stk = (unsigned long)stack;
struct pt_regs *regs;
- unsigned k;
+ unsigned int k;
BUILD_BUG_ON(N_EXCEPTION_STACKS != 4);
+ estacks = (unsigned long)__this_cpu_read(cea_exception_stacks);
+
for (k = 0; k < N_EXCEPTION_STACKS; k++) {
- end = (unsigned long *)raw_cpu_ptr(&orig_ist)->ist[k];
- begin = end - (exception_stack_sizes[k] / sizeof(long));
+ begin = estacks + layout[k].begin;
+ end = estacks + layout[k].end;
regs = (struct pt_regs *)end - 1;
- if (stack < begin || stack >= end)
+ if (stk < begin || stk >= end)
continue;
info->type = STACK_TYPE_EXCEPTION + k;
- info->begin = begin;
- info->end = end;
+ info->begin = (unsigned long *)begin;
+ info->end = (unsigned long *)end;
info->next_sp = (unsigned long *)regs->sp;
return true;
[patch V3 09/32] x86/exceptions: Make IST index zero based
The defines for the exception stack (IST) array in the TSS are using the
SDM convention IST1 - IST7. That causes all sorts of code to subtract 1 for
array indices related to IST. That's confusing at best and does not provide
any value.
Make the indices zero based and fixup the usage sites. The only code which
needs to adjust the 0 based index is the interrupt descriptor setup which
needs to add 1 now.
Signed-off-by: Thomas Gleixner
Reviewed-by: Sean Christopherson
---
Documentation/x86/kernel-stacks |8
arch/x86/entry/entry_64.S|4 ++--
arch/x86/include/asm/page_64_types.h | 13 -
arch/x86/kernel/cpu/common.c |4 ++--
arch/x86/kernel/dumpstack_64.c | 14 +++---
arch/x86/kernel/idt.c| 15 +--
arch/x86/kernel/irq_64.c |2 +-
arch/x86/mm/fault.c |2 +-
8 files changed, 34 insertions(+), 28 deletions(-)
--- a/Documentation/x86/kernel-stacks
+++ b/Documentation/x86/kernel-stacks
@@ -59,7 +59,7 @@ If that assumption is ever broken then t
The currently assigned IST stacks are :-
-* DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE).
+* ESTACK_DF. EXCEPTION_STKSZ (PAGE_SIZE).
Used for interrupt 8 - Double Fault Exception (#DF).
@@ -68,7 +68,7 @@ The currently assigned IST stacks are :-
Using a separate stack allows the kernel to recover from it well enough
in many cases to still output an oops.
-* NMI_STACK. EXCEPTION_STKSZ (PAGE_SIZE).
+* ESTACK_NMI. EXCEPTION_STKSZ (PAGE_SIZE).
Used for non-maskable interrupts (NMI).
@@ -76,7 +76,7 @@ The currently assigned IST stacks are :-
middle of switching stacks. Using IST for NMI events avoids making
assumptions about the previous state of the kernel stack.
-* DEBUG_STACK. DEBUG_STKSZ
+* ESTACK_DB. DEBUG_STKSZ
Used for hardware debug interrupts (interrupt 1) and for software
debug interrupts (INT3).
@@ -86,7 +86,7 @@ The currently assigned IST stacks are :-
avoids making assumptions about the previous state of the kernel
stack.
-* MCE_STACK. EXCEPTION_STKSZ (PAGE_SIZE).
+* ESTACK_MCE. EXCEPTION_STKSZ (PAGE_SIZE).
Used for interrupt 18 - Machine Check Exception (#MC).
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -841,7 +841,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work
/*
* Exception entry points.
*/
-#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) - 1) * 8)
+#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + (x) * 8)
/**
* idtentry - Generate an IDT entry stub
@@ -1129,7 +1129,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
hv_stimer0_callback_vector hv_stimer0_vector_handler
#endif /* CONFIG_HYPERV */
-idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
+idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=ESTACK_DB
idtentry int3 do_int3 has_error_code=0
idtentry stack_segment do_stack_segmenthas_error_code=1
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -24,11 +24,14 @@
#define IRQ_STACK_ORDER (2 + KASAN_STACK_ORDER)
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#define DOUBLEFAULT_STACK 1
-#define NMI_STACK 2
-#define DEBUG_STACK 3
-#define MCE_STACK 4
-#define N_EXCEPTION_STACKS 4 /* hw limit: 7 */
+/*
+ * The index for the tss.ist[] array. The hardware limit is 7 entries.
+ */
+#defineESTACK_DF 0
+#defineESTACK_NMI 1
+#defineESTACK_DB 2
+#defineESTACK_MCE 3
+#defineN_EXCEPTION_STACKS 4
/*
* Set __PAGE_OFFSET to the most negative possible address +
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -516,7 +516,7 @@ DEFINE_PER_CPU(struct cpu_entry_area *,
*/
static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
[0 ... N_EXCEPTION_STACKS - 1]= EXCEPTION_STKSZ,
- [DEBUG_STACK - 1] = DEBUG_STKSZ
+ [ESTACK_DB] = DEBUG_STKSZ
};
#endif
@@ -1760,7 +1760,7 @@ void cpu_init(void)
estacks += exception_stack_sizes[v];
oist->ist[v] = t->x86_tss.ist[v] =
(unsigned long)estacks;
- if (v == DEBUG_STACK-1)
+ if (v == ESTACK_DB)
per_cpu(debug_stack_addr, cpu) = (unsigned
long)estacks;
}
}
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -18,16 +18,16 @@
#include
-static char *exception_stack_names[N_EXCEPTION_STACKS] = {
- [ DOUBLEFAULT_STACK-1 ] = "#DF",
- [ NMI_STACK-1 ] = "NMI",
-
