HomeSort by: relevance | last modified time | path
    Searched hist:1.155 (Results 1 - 25 of 653) sorted by relevancy

1 2 3 4 5 6 7 8 91011>>

  /src/usr.bin/make/unit-tests/
opt-debug-for.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug-for.mk 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug-loud.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug-loud.mk 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-export-literal.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-ifnmake.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-ifnmake.mk 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

make-exported.exp 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug-jobs.mk 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-export-literal.mk 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-ifndef.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

directive-ifndef.mk 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

make-exported.mk 1.5 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug.exp 1.3 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

opt-debug.mk 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

var-op-append.mk 1.4 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

varname-dot-curdir.mk 1.5 Mon Oct 05 19:24:29 UTC 2020 rillig make(1): fix double-free bug in -DCLEANUP mode (since 2020-10-02)

The bug had been introduced with dir.c 1.155 on 2020-10-02 22:20:25. In
that commit, openDirectories was replaced with a combination of a list
with a hash table, for more efficient lookup by name.

Upon cleanup, OpenDirs_Done is called, which in turn called
Dir_ClearPath. Dir_ClearPath takes full ownership of the given list and
empties it. This was no problem before since afterwards the list was
empty and calling Lst_Free just frees the remaining list pointer.

With OpenDirs, this list was combined with a hash table, and the hash
table contains the list nodes, assuming that the OpenDirs functions have
full ownership of both the list and the hash table. This assumption was
generally correct, except for the one moment during cleanup where full
ownership of the list was passed to Dir_ClearPath, while the hash table
still contained pointers to the (now freed) list nodes. This by itself
was not a problem since the hash table would be freed afterwards. But
as part of Dir_ClearPath, OpenDirs_Remove was called, which looked up
the freed directory by name and now found the freed list node, trying to
free it again. Boom.

Fixed by replacing the call to Dir_ClearPath with code that only frees
the directories, without giving up control over the list.

  /src/sbin/iscsid/
iscsid.h 1.2.4.1 Wed May 30 08:06:26 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #291):
etc/MAKEDEV.tmpl: revision 1.155
sbin/iscsictl/iscsictl.8: revision 1.2-1.4
sbin/iscsid/iscsid_driverif.c: revision 1.4-1.5
sbin/iscsid/iscsid_lists.c: revision 1.4-1.7
sbin/iscsid/iscsid_targets.c: revision 1.4
sbin/iscsid/iscsid_globals.h: revision 1.5-1.7
sbin/iscsid/iscsid_main.c: revision 1.4-1.7
sbin/iscsid/Makefile: revision 1.2-1.4
sbin/iscsid/iscsid.8: revision 1.3-1.8
sbin/iscsid/iscsid.h: revision 1.3
sys/dev/iscsi/iscsi_main.c: revision 1.2-1.3

Fix bugs in iscsid target list handling, and improve documentation
somewhat for the in-kernel iSCSI initiator.

Makefile 1.1.4.1 Wed May 30 08:06:26 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #291):
etc/MAKEDEV.tmpl: revision 1.155
sbin/iscsictl/iscsictl.8: revision 1.2-1.4
sbin/iscsid/iscsid_driverif.c: revision 1.4-1.5
sbin/iscsid/iscsid_lists.c: revision 1.4-1.7
sbin/iscsid/iscsid_targets.c: revision 1.4
sbin/iscsid/iscsid_globals.h: revision 1.5-1.7
sbin/iscsid/iscsid_main.c: revision 1.4-1.7
sbin/iscsid/Makefile: revision 1.2-1.4
sbin/iscsid/iscsid.8: revision 1.3-1.8
sbin/iscsid/iscsid.h: revision 1.3
sys/dev/iscsi/iscsi_main.c: revision 1.2-1.3

Fix bugs in iscsid target list handling, and improve documentation
somewhat for the in-kernel iSCSI initiator.

iscsid_globals.h 1.4.2.1 Wed May 30 08:06:26 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #291):
etc/MAKEDEV.tmpl: revision 1.155
sbin/iscsictl/iscsictl.8: revision 1.2-1.4
sbin/iscsid/iscsid_driverif.c: revision 1.4-1.5
sbin/iscsid/iscsid_lists.c: revision 1.4-1.7
sbin/iscsid/iscsid_targets.c: revision 1.4
sbin/iscsid/iscsid_globals.h: revision 1.5-1.7
sbin/iscsid/iscsid_main.c: revision 1.4-1.7
sbin/iscsid/Makefile: revision 1.2-1.4
sbin/iscsid/iscsid.8: revision 1.3-1.8
sbin/iscsid/iscsid.h: revision 1.3
sys/dev/iscsi/iscsi_main.c: revision 1.2-1.3

Fix bugs in iscsid target list handling, and improve documentation
somewhat for the in-kernel iSCSI initiator.

iscsid_targets.c 1.3.2.1 Wed May 30 08:06:26 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #291):
etc/MAKEDEV.tmpl: revision 1.155
sbin/iscsictl/iscsictl.8: revision 1.2-1.4
sbin/iscsid/iscsid_driverif.c: revision 1.4-1.5
sbin/iscsid/iscsid_lists.c: revision 1.4-1.7
sbin/iscsid/iscsid_targets.c: revision 1.4
sbin/iscsid/iscsid_globals.h: revision 1.5-1.7
sbin/iscsid/iscsid_main.c: revision 1.4-1.7
sbin/iscsid/Makefile: revision 1.2-1.4
sbin/iscsid/iscsid.8: revision 1.3-1.8
sbin/iscsid/iscsid.h: revision 1.3
sys/dev/iscsi/iscsi_main.c: revision 1.2-1.3

Fix bugs in iscsid target list handling, and improve documentation
somewhat for the in-kernel iSCSI initiator.

  /src/sys/arch/sparc64/dev/
fdc.c 1.42 Tue Aug 19 18:20:51 UTC 2014 jnemeth branches: 1.42.2;
Sync with sparc/dev/fd.c:1.155.

Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().

I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).

Should be pulled up to netbsd-7.
1.36.22.1 Mon Nov 03 16:47:07 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
1.36.14.1 Mon Nov 03 16:47:29 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
1.36.8.1 Mon Nov 03 15:54:50 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
  /src/sbin/iscsictl/
iscsictl.8 1.1.4.1 Wed May 30 08:06:26 UTC 2012 sborrill Pull up the following revisions(s) (requested by riz in ticket #291):
etc/MAKEDEV.tmpl: revision 1.155
sbin/iscsictl/iscsictl.8: revision 1.2-1.4
sbin/iscsid/iscsid_driverif.c: revision 1.4-1.5
sbin/iscsid/iscsid_lists.c: revision 1.4-1.7
sbin/iscsid/iscsid_targets.c: revision 1.4
sbin/iscsid/iscsid_globals.h: revision 1.5-1.7
sbin/iscsid/iscsid_main.c: revision 1.4-1.7
sbin/iscsid/Makefile: revision 1.2-1.4
sbin/iscsid/iscsid.8: revision 1.3-1.8
sbin/iscsid/iscsid.h: revision 1.3
sys/dev/iscsi/iscsi_main.c: revision 1.2-1.3

Fix bugs in iscsid target list handling, and improve documentation
somewhat for the in-kernel iSCSI initiator.

  /src/share/man/man9/
vnfileops.9 1.13 Thu Apr 10 04:43:02 UTC 2008 riz branches: 1.13.2;
Catch the documentation up with the changes in vfs_vnops.c revision
1.155 - s/struct file/file_t/, and dropping a struct lwp * arg from
some functions.

  /src/sys/arch/sun3/dev/
fd.c 1.78 Wed Aug 20 17:48:57 UTC 2014 tsutsui branches: 1.78.2;
Sync with sparc/dev/fd.c rev 1.155.

> Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().

Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)

Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

1.72.16.1 Mon Nov 03 16:47:07 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)


sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

1.72.14.1 Mon Nov 03 16:47:29 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)


sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

1.72.8.1 Mon Nov 03 15:54:50 UTC 2014 msaitoh Pull up following revision(s) (requested by tsutsui in ticket #1139):
sys/arch/sun3/dev/fd.c: revision 1.78
sys/arch/sparc/dev/fd.c: revision 1.155
sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)


sys/arch/sparc64/dev/fdc.c: revision 1.42
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c:1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)

.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
Sync with sparc/dev/fd.c rev 1.155.
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)


Completed in 195 milliseconds

1 2 3 4 5 6 7 8 91011>>