On 12/18/18 3:52 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>
>> At any rate, the generated code will likely be different for -Os and
>> otherwise,
>> does that mean entries get added conditionally to localplt.data etc ?
>
> Entries *can* have a "?" to indicate they are o
Hi,
On Thu, Dec 13, 2018 at 08:21:46PM +0300, Dmitry V. Levin wrote:
> syscall_get_arch() is required to be implemented on all architectures
> in addition to already implemented syscall_get_nr(),
> syscall_get_arguments(), syscall_get_error(), and
> syscall_get_return_value() functions in order to
On Thu, 20 Dec 2018, Vineet Gupta wrote:
> I'm still ramping up on hard-float, so pardon some of my naivety. It seems the
> function calling convention is no different for soft-float vs. hard-float. We
> have
> a single register file (hard FP instructions inherently use an additional
> accumulato
Hi,
On Thu, Dec 13, 2018 at 08:21:42PM +0300, Dmitry V. Levin wrote:
> These should never have been defined in the arch tree to begin with, and
> now uapi/linux/audit.h header is going to use EM_ARCOMPACT and EM_ARCV2
> in order to define AUDIT_ARCH_ARCOMPACT and AUDIT_ARCH_ARCV2 which are
> neede
On 12/18/18 3:23 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>
>> +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)
>
> Missing spaces before '(' (should have such spaces in most cases between
> an identifier or keyword and '(' - calls to "defined", calls to function
On Thu, 20 Dec 2018, Vineet Gupta wrote:
> On 12/19/18 2:17 PM, Joseph Myers wrote:
> > I should note a separate issue to consider: that of *static* PIE support.
> > That doesn't need to be working, but if it's not working,
>
> Aren't there directed test cases for that already ?
>
> PASS: elf/
On 12/19/18 2:17 PM, Joseph Myers wrote:
> I should note a separate issue to consider: that of *static* PIE support.
> That doesn't need to be working, but if it's not working,
Aren't there directed test cases for that already ?
PASS: elf/tst-tls1-static
PASS: elf/tst-tls1-static-non-pie
FAIL:
On Thu, 20 Dec 2018, Vineet Gupta wrote:
> On 12/18/18 1:04 PM, Vineet Gupta wrote:
> > (a) build-many-glibcs.py check results are clean
> >
> > | Summary of test results:
> > | 1173 PASS
> > | 15 XFAIL
> > |
> > | PASS: glibcs-arc-linux-gnu check
>
> One of the issues in running build-ma
On 12/18/18 4:01 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Joseph Myers wrote:
>
>> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>>
>>> +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)
>> Missing spaces before '(' (should have such spaces in most cases between
>> an identifier or keyword
On 12/18/18 1:04 PM, Vineet Gupta wrote:
> (a) build-many-glibcs.py check results are clean
>
> | Summary of test results:
> | 1173 PASS
> | 15 XFAIL
> |
> | PASS: glibcs-arc-linux-gnu check
One of the issues in running build-many incrementally, i.e. "host-libraries",
"compilers" only once
On 12/20/18 12:06 PM, Adhemerval Zanella wrote:
>
>
> On 20/12/2018 17:23, Vineet Gupta wrote:
>> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
> #define SET_SA_RESTORER(kact, act) \
> (kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
> (kact)->sa_resto
On 20/12/2018 17:23, Vineet Gupta wrote:
> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
#define SET_SA_RESTORER(kact, act) \
(kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
(kact)->sa_restorer = &__default_rt_sa_restorer
>>> +#define SET_SA_RESTO
On 12/20/18 4:07 AM, Arnd Bergmann wrote:
> All users of sigset_t that I could find in the kernel just check
> the size argument to ensure it matches _NSIG, and return
> EINVAL otherwise.
Indeed that was one of the very first problem ARC glibc port ran into with stock
sizeof(sigset_t) passed in si
On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
>>> #define SET_SA_RESTORER(kact, act) \
>>> (kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
>>> (kact)->sa_restorer = &__default_rt_sa_restorer
>> +#define SET_SA_RESTORER(kact, act) \
>> + ({
On 12/20/18 4:40 AM, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> The only advantage of using a larger sigset_t from glibc standpoint is if
>> kernel ever change it maximum number of supported signals it would not be
>> a ABI change (it would be if glibc provided sigset_t need to be extended)
On 12/20/18 5:04 AM, Michal Hocko wrote:
> On Tue 18-12-18 10:53:59, Vineet Gupta wrote:
>> signal handling core calls ARCH show_regs() with preemption disabled
>> which causes __might_sleep functions such as mmput leading to lockdep
>> splat. Workaround by re-enabling preemption temporarily.
>>
>
On 12/20/18 5:30 AM, Tetsuo Handa wrote:
>> | Stack Trace:
>> | arc_unwind_core+0xcc/0x100
>> | ___might_sleep+0x17a/0x190
>> | mmput+0x16/0xb8
> Then, does mmput_async() help?
>
It helps, but then we get the next one (w/o my patch 2/2)
BUG: sleeping function called from invalid context at ker
On 12/20/18 4:57 AM, Michal Hocko wrote:
>> Despite this, lockdep still barfs (see next change), but this patch
>> still has merit as in we use smaller/localized buffers now and there's
>> less instructoh trace to sift thru when debugging pesky issues.
> But show_regs is called from contexts which
On 12/20/18 5:30 AM, Tetsuo Handa wrote:
>> | mmput+0x16/0xb8
> Then, does mmput_async() help?
Probably, I can try.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Btw, can you try wit the very latests dma-mapping-for-next tree
which has a new fix from Thierry Reding that might be related.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote:
> > I would be really surprised if that is caused by the patch to add
> > the zeroing.
> Me too :)
>
> > Can you check which commit caused the issue by bisecting
> > from a known good baseline?
>
> Yep. At least kernel build from
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote:
> On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> > Hi Christoph,
> >
> > I test kernel from your 'dma-alloc-always-zero' branch, and as
> > I can see we have DMA peripherals (like USB) broken.
>
> I would be really surprise
On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> I test kernel from your 'dma-alloc-always-zero' branch, and as
> I can see we have DMA peripherals (like USB) broken.
I would be really surprised if that is caused by the patch to add
the zeroing. Can you check
Hi Christoph,
I test kernel from your 'dma-alloc-always-zero' branch, and as
I can see we have DMA peripherals (like USB) broken.
There are the errors example I got during USB initializing:
-->8
usb 1-1: device descriptor read/64, error
On 2018/12/20 10:16, Vineet Gupta wrote:
> On 12/19/18 9:04 AM, Eugeniy Paltsev wrote:
>> As I can see x86 use print_vma_addr() in their show_signal_msg()
>> function which allocate page with __get_free_page(GFP_NOWAIT);
>
> Indeed with that the __get_free_page() lockdep splat is gone.
>
> There'
On Tue 18-12-18 10:53:59, Vineet Gupta wrote:
> signal handling core calls ARCH show_regs() with preemption disabled
> which causes __might_sleep functions such as mmput leading to lockdep
> splat. Workaround by re-enabling preemption temporarily.
>
> This may not be as bad as it sounds since the
On Tue 18-12-18 10:53:58, Vineet Gupta wrote:
> Use on-stack smaller buffers instead of dynamic pages.
>
> The motivation for this change was to address lockdep splat when
> signal handling code calls show_regs (with preemption disabled) and
> ARC show_regs calls into sleepable page allocator.
>
* Adhemerval Zanella:
> The only advantage of using a larger sigset_t from glibc standpoint is if
> kernel ever change it maximum number of supported signals it would not be
> a ABI change (it would be if glibc provided sigset_t need to be extended).
It's not just the kernel. We might want to re
On Thu, Dec 20, 2018 at 12:19 PM Adhemerval Zanella
wrote:
> On 19/12/2018 20:23, Vineet Gupta wrote:
> > On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
> >> One possibility is to define an arch-specific __sigset_t.h with a custom
> >> _SIGSET_NWORDS value and add an optimization on Linux sigactio
On 19/12/2018 20:23, Vineet Gupta wrote:
> On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
>>
>>
>> One possibility is to define an arch-specific __sigset_t.h with a custom
>> _SIGSET_NWORDS value and add an optimization on Linux sigaction.c to check
>> if both kernel_sigaction and glibc sigacti
30 matches
Mail list logo
