On Thu, 12 Jun 2025 at 09:12, Vineet Gupta wrote:
>
> Back when ii had happened I did extend the date on the key and AFAIKR did
> --send-keys to pgp.mit.edu
I don't think pgp.mit.edu even works any more ...
The pgp keyserver situation seems to be better than it was a couple of
years ago, but it'
On Wed, 11 Jun 2025 at 20:29, Vineet Gupta wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
> tags/arc-6.16-rc1
So this is signed and I pulled, but your key has expired. And I don't
find a new key on kernel.org or the normal keyservers.
Please don't put expiration date
On Thu, 12 Dec 2024 at 21:47, Yafang Shao wrote:
>
> Since task->comm is guaranteed to be NUL-terminated, we can print it
> directly without the need to copy it into a separate buffer.
So i think we should do the "without copying into a separate buffer"
part of this series, but I do think we shou
On Tue, 16 Jul 2024 at 21:57, Linus Torvalds
wrote:
>
> Note, it really might be just 'allmodconfig'. We've had things that
> depend on config entries in the past, eg the whole
> CONFIG_HEADERS_INSTALL etc could affect things.
Oh, and my "find" line was
On Tue, 16 Jul 2024 at 21:44, Arnd Bergmann wrote:
>
> I don't see those either (this is an x86 defconfig example):
Note, it really might be just 'allmodconfig'. We've had things that
depend on config entries in the past, eg the whole
CONFIG_HEADERS_INSTALL etc could affect things.
And yes, I bu
On Mon, 15 Jul 2024 at 14:07, Arnd Bergmann wrote:
>
> Most of this is part of my ongoing work to clean up the system call
> tables. In this bit, all of the newer architectures are converted to
> use the machine readable syscall.tbl format instead in place of complex
> macros in include/uapi/asm-g
On Mon, Feb 21, 2022 at 5:25 AM Thomas Bogendoerfer
wrote:
>
> With this patch
[ .. snip snip ..]
> I at least get my simple test cases fixed, but I'm not sure this is
> correct.
I think you really want to do that anyway, just to get things like
wild kernel pointers right (ie think get_kernel_nof
On Mon, Feb 14, 2022 at 12:01 PM Linus Torvalds
wrote:
>
> x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the
> get_user() assembler implementation does the same.
Side note: we could just check the sign bit instead, and avoid big
constants that way.
Right now we actually
On Mon, Feb 14, 2022 at 11:46 AM Arnd Bergmann wrote:
>
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
> TASK_SIZE_MAX
On Mon, Feb 14, 2022 at 8:35 AM Arnd Bergmann wrote:
>
> I did a patch for microblaze at some point, which turned out to be fairly
> generic, and now ported it to most other architectures, using new generic
> implementations of access_ok() and __{get,put}_kernel_nocheck().
Thanks for doing this.
On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
>
> The first patch is a cleanup of numa_distance allocation in arch_numa I've
> spotted during the conversion.
> The second patch is a fix for Xen memory freeing on some of the error
> paths.
Well, at least patch 2 looks like something that s
On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
>
> The core change is in the third patch that makes memblock_free() a
> counterpart of memblock_alloc() and adds memblock_phys_alloc() to be a
^^^
> counterpart of memblock_phys_alloc().
That should be 'memblock_phys_free()'
needs a lot
more testing - I'm not comfy with this patch unless somebody takes it
upon themselves to actually test it under different loads (and
different architectures).
Linus
From 3ea219a14bd6f36dfed5e461067349ab86a02935 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Da
On Fri, Apr 30, 2021 at 3:44 PM Vineet Gupta wrote:
>
> I agree that -O2 is default, but we've had -O3 default for ARC kernel
> forever, since last decade seriously. The reason I turned it on back
> then was upside of 10% performance improvement on select LMBench numbers
> on hardware at the time
On Fri, Apr 30, 2021 at 1:46 PM Vineet Gupta wrote:
>
> I've hit a mainline gcc 10.2 (also gcc 9.3) bug which triggers at -O3
> causing wrong codegen.
I'd be more than happy to just disable CC_OPTIMIZE_FOR_PERFORMANCE_O3 entirely.
The advantages are very questionable - with a lot of the optimiza
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> +
On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
>
> While at it I might have a look at that debug request from Willy in the
> other end of this thread. Any comment on that?
>
> https://lore.kernel.org/r/87k0v7mrrd@nanos.tec.linutronix.de
I do think that it would be nice to have a debu
On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>
> But then we really should not name it kmap_local. 'local' suggests
> locality, think local_irq*, local_bh* ... kmap_task would be more
> accurate then.
So the main reason I'd like to see it is because I think on a
non-highmem machine, the
On Thu, Oct 29, 2020 at 3:32 PM Thomas Gleixner wrote:
>
>
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going forward with this, I'll have a
> deeper look into this issue.
Me likee. I think this looks like the right thing to
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.
Heh.
Right you are.
Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or maybe
On Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds
wrote:
>
> Yeah, that looks much easier to explain. Ack.
Btw, one thing that might be a good idea at least initially is to add
a check for p->kmap_ctrl.idx being zero at fork, exit and maybe
syscall return time (but that last one m
On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote:
>
> I think the more obvious solution is to split the whole exercise:
>
> schedule()
> prepare_switch()
> unmap()
>
> switch_to()
>
> finish_switch()
> map()
Yeah, that looks much easier to explain. Ack.
On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote:
>
> Actually most usage sites of kmap atomic do not need page faults to be
> disabled at all.
Right. I think the pagefault disabling has (almost) nothing at all to
do with the kmap() itself - it comes from the "atomic" part, not the
"kmap" pa
On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox wrote:
>
> My concern with that is people might use kmap() and then pass the address
> to a different task. So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.
Ahh. Yes, I guess they might do th
On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
Ack. This looks really nice, even apart from the new capability.
The only thing I really reacted to is that the name doesn't make sense
to me
On Tue, Jan 14, 2020 at 1:37 PM Vineet Gupta wrote:
>
> On 1/14/20 12:42 PM, Arnd Bergmann wrote:
> >
> > What's wrong with the generic version on little-endian? Any
> > chance you can find a way to make it work as well for you as
> > this copy?
>
> find_zero() by default doesn't use pop count ins
On Tue, Jan 14, 2020 at 12:09 PM Vineet Gupta
wrote:
>
> There are 2 generic varaints of strncpy_from_user() / strnlen_user()
> (1). inline version in asm-generic/uaccess.h
I think we should get rid of this entirely. It's just a buggy garbage
implementation that nobody should ever actually use.
On Tue, Jan 14, 2020 at 12:09 PM Vineet Gupta
wrote:
>
> This came up when switching ARC to word-at-a-time interface and using
> generic/optimized strncpy_from_user
>
> It seems the existing code checks for user buffer/string range multiple
> times and one of tem cn be avoided.
NO!
DO NOT DO THI
On Tue, Oct 15, 2019 at 12:19 PM Vineet Gupta
wrote:
>
> This is a non-functional change anyways since ARC has software page walker
> with 2 lookup levels (pgd -> pte)
Could we encourage other architectures to do the same, and get rid of
all uses of __ARCH_USE_5LEVEL_HACK?
Linus
___
On Tue, Oct 15, 2019 at 12:19 PM Vineet Gupta
wrote:
>
> This came up when removing __ARCH_HAS_5LEVEL_HACK for ARC as code bloat
> from this routine not required in a 2-level paging setup
Similarly acked,
Linus
___
linux-snps-arc mailing lis
On Tue, Oct 15, 2019 at 12:19 PM Vineet Gupta
wrote:
>
> This came up when removing __ARCH_HAS_5LEVEL_HACK for ARC as code bloat
> from this routine which is not required in a 2-level paging setup
Ack, looks good.
Linus
___
linux-snps-arc m
On Mon, Oct 14, 2019 at 12:08 PM Vineet Gupta wrote:
>
> > And yes, pmd_clear_bad() should just go away. We have
> >
> > static inline int pmd_none_or_clear_bad(pmd_t *pmd)
> > {
> > if (pmd_none(*pmd))
> > return 1;
> > if (unlikely(pmd_bad(*pmd))) {
> >
On Mon, Oct 14, 2019 at 11:02 AM Vineet Gupta wrote:
>
> I suppose we could but
>
> (a) It would be asymmetric with the __p{u,4}d_free_tlb() changes in [1] and
> [2].
Your patch is already assymmetric wrt those anyway - you had to add that
+#else
+#define pmd_free_tlb(tlb, pmdp, address)
On Fri, Oct 11, 2019 at 3:38 PM Vineet Gupta wrote:
>
> This is inine with similar patches for nopud [1] and nop4d [2] cases.
I don't think your patch is wrong, but wouldn't it be easier and
cleaner to just do this instead
--- a/include/asm-generic/pgtable-nopmd.h
+++ b/include/asm-gener
On Fri, Sep 7, 2018 at 11:21 AM Vineet Gupta wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
> tags/arc-4.19-rc3
That "tags/arc-4.19-rc3" actually a real signed tag from you, but it
doesn't point to any of your new work. In fact, it just points to my
"Linux 4.15-rc1" c
On Sun, Aug 26, 2018 at 12:32 PM H. Peter Anvin wrote:
>
> Here is a full-blown (user space) test program demonstrating the whole
> technique and how to use it.
So while I agree that some _THIS_IP_ users might be better off being
converted to __builtin_return_address(0) at the caller, I also thin
On Tue, Aug 21, 2018 at 1:31 PM Nick Desaulniers
wrote:
>
> I suspect that current_text_addr predated GNU C extensions for statement
> expressions and/or taking the address of a label, then the macro was
> reimplemented for every new archs include/asm/processor.h, even though
> there were very few
On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote:
>
> Please merge these directly if you are happy with the result.
I will take this.
I do see two warnings, but they both seem to be valid and recent,
though, so I have no issues with the spurious cases.
Warning #1:
sound/soc/qcom/lpass-pl
On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta
wrote:
>
> The highlight is support for EZChip (now Mellanox) NPS-400 network processor
> [..]
Oh, and that brought in the
drivers/irqchip/irq-eznps.c
driver that is compile-test enabled.
And that driver is not 64-bit clean:
In file includ
On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta
wrote:
> Hi Linus,
>
> We have a relatively big changeset for ARC for 4.7.
.. this pull request is missing the diffstat, though, so it's hard to
see that your "big changeset" matches what I actually get.
To make matters worse, the shortlog doesn't m
40 matches
Mail list logo
