On 29.02.2020 23:31, Joerg Sonnenberger wrote:
> On Sat, Feb 29, 2020 at 10:29:02PM +0100, Kamil Rytarowski wrote:
>> On 29.02.2020 21:58, Joerg Sonnenberger wrote:
>>> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
>>>> On 29.02.2020
On 29.02.2020 22:29, Kamil Rytarowski wrote:
> On 29.02.2020 21:58, Joerg Sonnenberger wrote:
>> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
>>> On 29.02.2020 19:00, Taylor R Campbell wrote:
>>>>> Module Name:src
>>>>> Com
On 29.02.2020 21:58, Joerg Sonnenberger wrote:
> On Sat, Feb 29, 2020 at 07:36:00PM +0100, Kamil Rytarowski wrote:
>> On 29.02.2020 19:00, Taylor R Campbell wrote:
>>>> Module Name:src
>>>> Committed By: kamil
>>>> Date: Sat Feb
On 29.02.2020 19:29, Martin Husemann wrote:
> On Sat, Feb 29, 2020 at 06:00:29PM +, Taylor R Campbell wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Sat Feb 29 04:27:01 UTC 2020
>>>
>>> Modified Files:
>>> src/doc: CHANGES
>>>
>>> Log Message:
>>>
On 29.02.2020 19:00, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By: kamil
>> Date: Sat Feb 29 04:27:01 UTC 2020
>>
>> Modified Files:
>> src/doc: CHANGES
>>
>> Log Message:
>> ld.elf_so(1): Implement DT_GNU_HASH
>
> Was this discussed anywhere?
In the
On 25.02.2020 16:24, Andreas Gustafsson wrote:
> Kamil Rytarowski wrote:
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1.1.4 -r1.2 \
>> src/external/bsd/libarchive/dist/libarchive/archive_read.c
>
> What kind of sorcery is this? Why is the diff not r
On 24.02.2020 21:47, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Feb 24 20:47:47 UTC 2020
>
> Modified Files:
> src/sys/kern: init_main.c
>
> Log Message:
> move config_init_mi() call before vfsinit(), which can trigger loading
> of VFS modules
>
On 24.02.2020 20:32, Christos Zoulas wrote:
> In article <20200221222550.325a6f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Feb 21 22:25:50 UTC 2020
>&g
On 24.02.2020 20:29, Christos Zoulas wrote:
> In article <20200222191457.87687f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 22 19:14:57 UTC 2020
>&g
On 24.02.2020 17:44, Valery Ushakov wrote:
> On Mon, Feb 24, 2020 at 16:19:35 +0000, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Mon Feb 24 16:19:35 UTC 2020
>>
>> Modified Files:
>> src/exte
On 23.02.2020 08:46, Martin Husemann wrote:
> On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote:
>> Algorithm would be changed from calculating on 32bit numbers with signed
>> integer overflows to an algorithm calculating on 64bit numbers. The
>> __dorand48
On 23.02.2020 03:20, Valery Ushakov wrote:
> On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote:
>
>> On 23.02.2020 02:29, Valery Ushakov wrote:
>>> On Sat, Feb 22, 2020 at 14:07:57 +0000, Kamil Rytarowski wrote:
>>>
>>>> Module Name: s
On 23.02.2020 02:29, Valery Ushakov wrote:
> On Sat, Feb 22, 2020 at 14:07:57 +0000, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 22 14:07:57 UTC 2020
>>
>> Modified Files:
>> src/li
On 22.02.2020 15:54, Paul Goyette wrote:
> On Sat, 22 Feb 2020, Kamil Rytarowski wrote:
>
>>>>> While there, it would be good to implement modctl(MODCTL_MODSTAT,
>>>>> ) to check whether a specific module is loaded into the kernel
>>>>> and retr
On 22.02.2020 15:32, Paul Goyette wrote:
> On Sat, 22 Feb 2020, Paul Goyette wrote:
>
>>> While there, it would be good to implement modctl(MODCTL_MODSTAT,
>>> ) to check whether a specific module is loaded into the kernel
>>> and retrieve modstat_t describing it.
>>>
>>> modstat_t m;
>>>
directory should be only used for tests-that-
>> relate-to-module-functionality. It should NOT be used for modules-
>> that-support-tests-of-other-functionality.
>>
>> In the future, please do not put support modules here; put them in the
>> samae place as the tests tha
On 21.02.2020 23:53, matthew green wrote:
>> Disable ubsan instrumentation on the operation.
>
> +#if defined(__clang__)
> +__attribute__((no_sanitize("undefined")))
> +#else
> +__attribute__((no_sanitize_undefined))
> +#endif
>
> can we get a __disable_sanitizer or something i cdefs.h?
>
>
>
On 22.12.2019 20:47, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Dec 22 19:47:35 UTC 2019
>
> Modified Files:
> src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ctldir.c
> src/sys/kern: vfs_mount.c vfs_subr.c vfs_syscalls.c
>
On 20.02.2020 22:14, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Thu Feb 20 21:14:23 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> protect deferred lists' manipulation by config_misc_lock, same as
> config_pending
On 21.02.2020 07:20, Martin Husemann wrote:
> On Fri, Feb 21, 2020 at 03:01:45AM +0100, Kamil Rytarowski wrote:
>> I consider calling ncurses-dev essential as a bug.
>
> My knee jerk reaction was: if a unix compiler needs terminfo (especially
> when it only does that to create c
On 21.02.2020 09:17, Leonardo Taccari wrote:
> Kamil Rytarowski writes:
>> [...]
>> ./build.sh tools for LLVM is broken when host ships with no terminfo
>> devel libraries. I tried to disable this superfluous feature for tools
>> (for colors in a terminal), but it got r
On 21.02.2020 02:47, Christos Zoulas wrote:
> So host needs to install terminfo-dev. How is that different from the host
> environment needing to provide other pieces of the development environment?
> For example if another tool needed openssl-dev, would we disable crypto? Or
> if it needed
On 21.02.2020 01:17, Christos Zoulas wrote:
> In article <5f8df6c1-bb25-f24a-27fc-b3a752a6d...@gmx.com>,
> Kamil Rytarowski wrote:
>
>> We don't have any direct reproducer (we tried) and we must figure it out
>>from syzkaller bot. We don't have access to the mach
On 20.02.2020 01:09, Roy Marples wrote:
> On 19/02/2020 22:29, Kamil Rytarowski wrote:
>> Why do you need terminfo/termios in ./build.sh tools?
>
> We build the nbtic tool so we can build the terminfo database.
>
> Roy
I will try to have a look and switch to
On 19.02.2020 23:50, Joerg Sonnenberger wrote:
> On Wed, Feb 19, 2020 at 11:29:09PM +0100, Kamil Rytarowski wrote:
>> On 19.02.2020 23:03, Joerg Sonnenberger wrote:
>>> On Wed, Feb 19, 2020 at 04:10:17PM +0100, Kamil Rytarowski wrote:
>>>> On 19.02.2020 1
MESTAMP Wed Feb 19 19:18:01 UTC 2020
> Successful make release
> build.sh ended: Wed Feb 19 17:48:15 EST 2020
> ===> .
>
>
>
>> On Feb 19, 2020, at 11:09 AM, Kamil Rytarowski > <mailto:n...@gmx.com>> wrote:
>>
>> Signed
On 19.02.2020 23:03, Joerg Sonnenberger wrote:
> On Wed, Feb 19, 2020 at 04:10:17PM +0100, Kamil Rytarowski wrote:
>> On 19.02.2020 14:32, Joerg Sonnenberger wrote:
>>> Module Name:src
>>> Committed By: joerg
>>> Date: Wed Feb 19 13:3
On 19.02.2020 16:32, Kamil Rytarowski wrote:
> On 18.02.2020 22:14, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Feb 18 21:14:16 UTC 2020
>>
>> Modified Files:
>> src/doc: 3RDPART
On 18.02.2020 22:14, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Feb 18 21:14:16 UTC 2020
>
> Modified Files:
> src/doc: 3RDPARTY CHANGES
>
> Log Message:
> new awk
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.1690 -r1.1691
On 19.02.2020 14:32, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Wed Feb 19 13:32:40 UTC 2020
>
> Modified Files:
> src/external/apache2/llvm/config/llvm/Config: config.h.in
>
> Log Message:
> Revert last. It was objected to pre-commit, there is no
On 13.02.2020 20:03, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> On 12.02.2020 15:01, Ryo ONODERA wrote:
>>> Hi,
>>>
>>> Kamil Rytarowski writes:
>>>
>>>> Hello,
>>>>
>>>> I will have a
On 18.02.2020 16:57, Christos Zoulas wrote:
> In article <20200213152742.081a9f...@cvs.netbsd.org>,
> MichaŠGórny wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:mgorny
>> Date:Thu Feb 13 15:27:41 UTC 2020
>>
>> Modified Files:
>>
On 13.02.2020 22:20, Valery Ushakov wrote:
> I did not propose to disable the warning. I proposed to downgrade
> -Werror to -Wno-error (i.e. a warning) and only for the buggy
> sanitizer build. That file will still be compiled in normal builds
> with all the warnings=errors enabled, so real
On 13.02.2020 18:00, Valery Ushakov wrote:
> Arguably, if the tool you use is broken, you shouln't be mutilating
> the source code just to shut that tool up.
The introduced changes were good, even if GCC would be silent. It is far
from mutilating. As an alternative option we can disable warnings
On 12.02.2020 15:01, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Hello,
>>
>> I will have a look at them.
>
> Thank you.
> Real fix is welcome.
>
> And multimedia/handbrake has workaround already.
> I have workaround pa
On 13.02.2020 14:50, Valery Ushakov wrote:
> On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
>
>>
> Can you show the original problem that you are trying to fix here?
> When and how did you get warning?
>
GCC has a property (as called by Joerg bug) t
On 13.02.2020 14:13, Joerg Sonnenberger wrote:
> On Thu, Feb 13, 2020 at 02:05:12PM +0100, Kamil Rytarowski wrote:
>> On 13.02.2020 00:58, Joerg Sonnenberger wrote:
>>> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
>>>> On 09/02/2020 19:21, Joerg So
On 13.02.2020 00:58, Joerg Sonnenberger wrote:
> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
>> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
>>> On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name: src
Committed By: fox
Date:
Hello,
I will have a look at them.
On 12.02.2020 14:02, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Please apple workaround (same like in NSPR) for now if fixing is difficult.
>>
>> Such bugs can have security implications.
>
> Adding w
/mono6:
> The invalid thread pointer is not 0x.
> pthread_equal t1: 0x7b066d4d7800
> pthread_equal t2: 0x60f5f000
>
> Of course, it is desirable to fix every misuses and bugs in pkgsrc.
> However it is impossible for now (at least for me).
>
> "Kamil Rytarowski"
On 03.02.2020 17:24, Kamil Rytarowski wrote:
> On 03.02.2020 17:21, Joerg Sonnenberger wrote:
>> On Sat, Feb 01, 2020 at 03:38:46PM +0000, Kamil Rytarowski wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Sat Feb 1 15:3
On 03.02.2020 17:10, Ryo ONODERA wrote:
> Hi,
>
> Kamil Rytarowski writes:
>
>> Please check this workaround:
>>
>> http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
>>
>> It has to be applied on firefox's package.
>
> Thank you
On 03.02.2020 17:21, Joerg Sonnenberger wrote:
> On Sat, Feb 01, 2020 at 03:38:46PM +0000, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 1 15:38:46 UTC 2020
>>
>> Modified Files:
>> src/l
Please check this workaround:
http://netbsd.org/~kamil/patch-00224-firefox-pthread_equal.txt
It has to be applied on firefox's package.
The problem has to be reported upstream as a real bug.
On 03.02.2020 16:01, Ryo ONODERA wrote:
> Hi,
>
> Ryo ONODERA writes:
>
>> Hi,
>>
>> I had tested
(5) file.
On 01.02.2020 22:20, Kamil Rytarowski wrote:
> Good idea. It could be checked quicker... however I presume that
> t1->pt_magic + t1->pt_magic already crash on invalid t1/t2 pointers as
> the argument with condition is evaluated.
>
> Ryo, you might check:
> $ expo
read",
>> t1->pt_magic == PT_MAGIC);
>>
>> pthread__error(EINVAL, "Invalid thread",
>> t2->pt_magic == PT_MAGIC);
>> +#endif
>>
>> /* Nothing special here. */
>> return (t1 == t2);
>> @@ -1108,7
@@
> {
> char buf[1024];
> size_t len;
> -
> +
> if (pthread__diagassert == 0)
> return;
>
>
>
> "Kamil Rytarowski" writes:
>
>> Module Name: src
>> Committed By:kamil
>> Date:
Actually it happened that modifiying pthread_atfork() to stop
malloc()ing is enough to address the problem.
I have landed the changes and removed '#if 0' kludge.
Thanks!
On 01.02.2020 13:59, Kamil Rytarowski wrote:
> On 31.01.2020 22:10, Andrew Doran wrote:
>> On Fri, Jan 31, 2020 at 0
On 31.01.2020 22:10, Andrew Doran wrote:
> On Fri, Jan 31, 2020 at 06:55:00PM -, Christos Zoulas wrote:
>
>> In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
>> Kamil Rytarowski wrote:
>>> -=-=-=-=-=-
>>> -=-=-=-=-=-
>>
On 31.01.2020 19:55, Christos Zoulas wrote:
> In article <724af477-010b-9ddf-6ece-e23d7cf59...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 31.01.2020 03:38, Christos Zoulas wrote:
>>> And it is fixed now.
>>>
On 31.01.2020 03:38, Christos Zoulas wrote:
> And it is fixed now.
>
> christos
>
OK. I am going to submit a bug report upstream and get some feedback
what is the way forward here, delaying initialization.
signature.asc
Description: OpenPGP digital signature
On 05.03.2019 23:49, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Mar 5 22:49:38 UTC 2019
>
> Modified Files:
> src/lib/libpthread: pthread_mutex.c
>
> Log Message:
> Jemalloc initializes mutexes before we become threaded and expects to use
>
On 29.01.2020 07:40, Jason Thorpe wrote:
>
>> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote:
>>
>> The distribution build breaks for me with:
>
> Should be fixed with:
>
> /cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile
> new
On 29.01.2020 04:16, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 29 03:16:28 UTC 2020
>
> Modified Files:
> src/sys/net: Makefile files.net if.c if.h
> Added Files:
> src/sys/net: if_stats.c if_stats.h
>
> Log Message:
> Add support for
On 19.01.2020 07:57, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Jan 19 06:57:39 UTC 2020
>
> Modified Files:
> src/doc: CHANGES
>
> Log Message:
> Note removal of HIPPI support.
Thanks!
Please keep in sync src/doc/TODO.smpnet.
signature.asc
On 10.01.2020 23:21, Andrew Doran wrote:
> The second is pulling in efficient tracking of page clean/dirty status from
> the yamt-pagecache branch. This reduces the amount of work fsync() needs to
> do, which should be of benefit to the DBMS.
>
We probably should adapt DBMS to use
On 15.01.2020 11:56, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Wed Jan 15 10:56:49 UTC 2020
>
> Modified Files:
> src/common/lib/libc/arch/x86_64/string: bcmp.S memcmp.S
>
> Log Message:
> Rewrite bcmp() & memcmp() to not use REP CMPS. Seems about 5-10x
On 12.01.2020 23:03, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun Jan 12 22:03:23 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_exec.c kern_runq.c
> src/sys/sys: lwp.h sched.h
>
> Log Message:
> A final set of scheduler tweaks:
>
Great work!
On 04.01.2020 05:40, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Jan 4 04:40:17 UTC 2020
>
> Modified Files:
> src/lib/libc/sys: ptrace.2
>
> Log Message:
> /tmp/cvsbigmGa
>
Document PT_LWPSTATUS and PT_LWPNEXT
On 28.12.2019 09:00, Tomohiro Kusumi wrote:
> Module Name: src
> Committed By: tkusumi
> Date: Sat Dec 28 08:00:08 UTC 2019
>
> Modified Files:
> src/usr.sbin/fstyp: exfat.c fstyp.c fstyp.h
>
> Log Message:
> fstyp: Show exFAT volume labels with -l flag
>
> taken-from: FreeBSD
On 23.12.2019 18:14, Greg Troxel wrote:
> Warner Losh writes:
>
>> Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the
>> wumpus' for all the autoconfig scripts that suddenly thought they were
>> configuring for FreeBSD 1.0.
>>
>> If you can arrange it, it might make
On 23.12.2019 16:57, Martin Husemann wrote:
> On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote:
>> Well, we are coming up on a year since netbsd-9 was branched, or at
>> least will arrive there before this discussion resolves. So cutting
>> -10 before we hit 100 works for me :-)
>
>
On 23.12.2019 01:54, Roy Marples wrote:
> On 22/12/2019 22:24, Andrew Doran wrote:
>> NetBSD 9.99.29 - struct mount changed.
>
> Just curious - does our build software cope with 3 digit for the last
> number?
>
> Roy
At least from the __NetBSD_Version__ point of view there are 4 digits
unused,
On 22.12.2019 23:27, Andrew Doran wrote:
> On Sat, Dec 21, 2019 at 05:23:23PM +, Alexander Nasonov wrote:
>
>> Andrew Doran wrote:
>>> Log Message:
>>> NetBSD 9.99.28 - cpu_data & UVM changes.
>>
>> Wow, you bump versions faster than I compile new releases. At this
>> pace, we'll get to
On 08.12.2019 00:35, matthew green wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Dec 7 19:50:34 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: subr_kcov.c
>>
>> Log Message:
>> Revert the in_interrupt() change to use again the x86 specific code
>>
>>
On 03.12.2019 12:50, Juergen Hannken-Illjes wrote:
> Module Name: src
> Committed By: hannken
> Date: Tue Dec 3 11:50:45 UTC 2019
>
> Modified Files:
> src/sys/arch/x86/x86: x86_machdep.c
>
> Log Message:
> Make sure the assignment to "idepth" is done inside the loop to prevent
>
On 22.11.2019 06:14, Takahiro Kambe wrote:
> In message <20191121181801.11c5ff...@cvs.netbsd.org>
> on Thu, 21 Nov 2019 18:18:01 +,
> "Martin Husemann" wrote:
>> Module Name: src
>> Committed By:martin
>> Date:Thu Nov 21 18:18:00 UTC 2019
>>
>> Modified
types like void* cannot work as-is anyway.
> christos
>
>> On Nov 21, 2019, at 9:37 PM, Christos Zoulas wrote:
>>
>> That's for kernel debugging?
>>
I still have not been touching kgdb. It was for building the i386 file
on amd64 host only.
>> christos
>>
&
On 22.11.2019 02:52, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Nov 22 01:52:20 UTC 2019
>
> Modified Files:
> src/external/gpl3/gdb/lib/libgdb/arch/x86_64: config.h defs.mk init.c
>
> Log Message:
> regen x86_64 for i386 support
>
For the
On 14.11.2019 05:11, Kamil Rytarowski wrote:
> On 14.11.2019 04:55, Roy Marples wrote:
>> On 14/11/2019 02:40, Kamil Rytarowski wrote:
>>> On 14.11.2019 03:34, Roy Marples wrote:
>>>> On 13/11/2019 22:32, Joerg Sonnenberger wrote:
>>>>> Module Name:
On 14.11.2019 04:55, Roy Marples wrote:
> On 14/11/2019 02:40, Kamil Rytarowski wrote:
>> On 14.11.2019 03:34, Roy Marples wrote:
>>> On 13/11/2019 22:32, Joerg Sonnenberger wrote:
>>>> Module Name: src
>>>> Committed By: joerg
>
On 14.11.2019 03:34, Roy Marples wrote:
> On 13/11/2019 22:32, Joerg Sonnenberger wrote:
>> Module Name: src
>> Committed By: joerg
>> Date: Wed Nov 13 22:32:16 UTC 2019
>>
>> Modified Files:
>> src/share/mk: bsd.own.mk
>>
>> Log Message:
>> Restore pax-as-tar.
>>
>>
>> To
Module Name:src
Committed By: kamil
Date: Tue Nov 12 18:18:04 UTC 2019
Modified Files:
src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
Log Message:
Rework thread_concurrent_signals and trace_thread_lwpcreate_and_exit
Change the code to remove the LWP id
Module Name:src
Committed By: kamil
Date: Tue Nov 12 18:18:04 UTC 2019
Modified Files:
src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
Log Message:
Rework thread_concurrent_signals and trace_thread_lwpcreate_and_exit
Change the code to remove the LWP id
Module Name:src
Committed By: kamil
Date: Thu Nov 7 20:34:29 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Revert subr_disk_mbr.c r.1.54
Requested by as there can be a better way to fix the original
problem with alignment.
To generate a diff of
Module Name:src
Committed By: kamil
Date: Thu Nov 7 20:34:29 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Revert subr_disk_mbr.c r.1.54
Requested by as there can be a better way to fix the original
problem with alignment.
To generate a diff of
Module Name:src
Committed By: kamil
Date: Thu Nov 7 20:30:49 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Decorate check_label_magic() with __noubsan
Requested by
To generate a diff of this commit:
cvs rdiff -u -r1.54 -r1.55
Module Name:src
Committed By: kamil
Date: Thu Nov 7 20:30:49 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Decorate check_label_magic() with __noubsan
Requested by
To generate a diff of this commit:
cvs rdiff -u -r1.54 -r1.55
On 07.11.2019 19:32, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 18:08:40 +0100, Kamil Rytarowski wrote:
>
>> On 07.11.2019 16:45, Kamil Rytarowski wrote:
>>> On 07.11.2019 16:26, Martin Husemann wrote:
>>>> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Ryta
Module Name:src
Committed By: kamil
Date: Thu Nov 7 18:35:41 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Revert src/sys/kern/subr_disk_mbr.c r.1.52
Addressed in a better way in r. 1.53.
To generate a diff of this commit:
cvs rdiff -u -r1.53
Module Name:src
Committed By: kamil
Date: Thu Nov 7 18:35:41 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Revert src/sys/kern/subr_disk_mbr.c r.1.52
Addressed in a better way in r. 1.53.
To generate a diff of this commit:
cvs rdiff -u -r1.53
Module Name:src
Committed By: kamil
Date: Thu Nov 7 18:30:27 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Ensure in validate_label() that struct disklabel pointer is 8-byte aligned
The label is searched each 4 bytes and can be detected in an
Module Name:src
Committed By: kamil
Date: Thu Nov 7 18:30:27 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Ensure in validate_label() that struct disklabel pointer is 8-byte aligned
The label is searched each 4 bytes and can be detected in an
On 07.11.2019 18:20, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 06:08:40PM +0100, Kamil Rytarowski wrote:
>> Please review:
>>
>> http://netbsd.org/~kamil/patch-00194-disklabel-alignment.txt
>>
>> This patch works for me.
>
> Yes, I believe that it
On 07.11.2019 16:45, Kamil Rytarowski wrote:
> On 07.11.2019 16:26, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
>>> On 07.11.2019 14:25, Valery Ushakov wrote:
>>>> If the sanitizer does complain about other uses, there
On 07.11.2019 17:20, Kamil Rytarowski wrote:
> On 07.11.2019 17:08, Martin Husemann wrote:
>> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>>> 6.3.2.1 C11
>>>
>>> 'An lvalue is an expression (with an object type other than void) that
On 07.11.2019 17:09, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 09:58:06AM -0600, David Young wrote:
>> I think the problem is that if you have the series of statements,
>>
>> element_t *e = >element;
>>
>> if (s == NULL)
>> return;
>
> Note that this example
On 07.11.2019 17:08, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:56:16PM +0100, Kamil Rytarowski wrote:
>> 6.3.2.1 C11
>>
>> 'An lvalue is an expression (with an object type other than void) that
>> potentially designates an object'
>>
>> This me
On 07.11.2019 16:49, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 04:45:31PM +0100, Kamil Rytarowski wrote:
>> Unfortunately the C committee went into the opposite direction here and
>> specified a potential dereference.
>
> Where?
>
> Martin
>
6.3.2.1 C9
On 07.11.2019 16:26, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 02:53:08PM +0100, Kamil Rytarowski wrote:
>> On 07.11.2019 14:25, Valery Ushakov wrote:
>>> If the sanitizer does complain about other uses, there is little point
>>> in fixing one instance and not t
On 07.11.2019 14:25, Valery Ushakov wrote:
> If the sanitizer does complain about other uses, there is little point
> in fixing one instance and not the others.
We already agreed with Christos that this is appeasing of GCC. If you
want to scan the whole kernel (or whole C) file for more
On 07.11.2019 13:48, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
>
>> On 07.11.2019 13:17, Valery Ushakov wrote:
>>> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
>>> As a side note - the C99 standard c
On 07.11.2019 13:17, Valery Ushakov wrote:
> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
>
>> I have checked received the following patch and received a feedback from
>> a LLVM developer.
>>
>> On 07.11.2019 05:47, 'Dmitry Vyukov' via syzkall
On 07.11.2019 11:53, Martin Husemann wrote:
> On Thu, Nov 07, 2019 at 11:46:47AM +0100, Kamil Rytarowski wrote:
>> Please see my newer mail with rationale and another one with a
>> confirmation that this was real UB.
>
> Confirmation? The dereference in this case happens i
On 07.11.2019 07:25, Martin Husemann wrote:
> On Wed, Nov 06, 2019 at 11:17:23PM +0100, Kamil Rytarowski wrote:
>> Technically, I think that this is a real UB.
>>
>> 6.3.2.3/7
>> A pointer to an object type may be converted to a pointer to a
>> different obje
sys/kern/vfs_subr.c:793:14,
member access within null pointer of type 'struct vnode_impl'
On 07.11.2019 00:03, Kamil Rytarowski wrote:
> On 06.11.2019 23:38, Christos Zoulas wrote:
>> On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
>> -- Subject: Re: CVS commit: src/sys/kern
On 06.11.2019 23:38, Christos Zoulas wrote:
> On Nov 6, 11:17pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/sys/kern
>
> | Technically, I think that this is a real UB.
> |
> | 6.3.2.3/7
> | A pointer to an object type may be converted to a point
On 06.11.2019 22:43, Christos Zoulas wrote:
> In article <20191106130732.c6c5af...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Wed Nov 6 13:07:32 UTC 2019
Module Name:src
Committed By: kamil
Date: Wed Nov 6 13:07:32 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Avoid unaligned pointer arithmetic in check_label_magic()
Replace the logic of calculating the address with with base + offset.
Reported by
Module Name:src
Committed By: kamil
Date: Wed Nov 6 13:07:32 UTC 2019
Modified Files:
src/sys/kern: subr_disk_mbr.c
Log Message:
Avoid unaligned pointer arithmetic in check_label_magic()
Replace the logic of calculating the address with with base + offset.
Reported by
101 - 200 of 818 matches
Mail list logo
