Re: svn commit: r334971 - head/sbin/dump

[Rodney W. Grimes]

> On Mon, 11 Jun 2018 19:32:45 + (UTC)
> Warner Losh  wrote:
> 
> > Author: imp
> > Date: Mon Jun 11 19:32:45 2018
> > New Revision: 334971
> > URL: https://svnweb.freebsd.org/changeset/base/334971
> > 
> > Log:
> >   Document the newly enforced 524288 inode restriction.
> > 
> > Modified:
> >   head/sbin/dump/dump.8
> > 
> > Modified: head/sbin/dump/dump.8
> > ==
> > --- head/sbin/dump/dump.8   Mon Jun 11 19:32:40 2018(r334970)
> > +++ head/sbin/dump/dump.8   Mon Jun 11 19:32:45 2018(r334971)
> > @@ -29,7 +29,7 @@
> >  .\" @(#)dump.8 8.3 (Berkeley) 5/1/95
> >  .\" $FreeBSD$
> >  .\"
> > -.Dd October 3, 2016
> > +.Dd June 11, 2018
> >  .Dt DUMP 8
> >  .Os
> >  .Sh NAME
> > @@ -566,3 +566,8 @@ This will be fixed in a later version of
> >  .Fx .
> >  Presently, it works if you set it setuid (like it used to be), but this
> >  might constitute a security risk.
> > +.Pp
> > +It is not possible to safely dump filesystems that use more than
> > +524288 inodes.
> > +.Nm
> > +refuses to dump any filesystem that has more than 524288 inodes.
> > ___
> > svn-src-h...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/svn-src-head
> > To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
> 
> Hello.
> 
> Is this limitation going to be eternal or are efforts being made to make it
> possible to go beyond this limitations? Just for curiosity ...
> 
> Thanks in advance,

This 512k limitiation was a short lived miss understanding of the code and
a correct fix that should resolve the issue has been commited, I am doing futher
testing at this time on a large file system to confirm imp@'s fix.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334971 - head/sbin/dump

[O. Hartmann]

On Mon, 11 Jun 2018 19:32:45 + (UTC)
Warner Losh  wrote:

> Author: imp
> Date: Mon Jun 11 19:32:45 2018
> New Revision: 334971
> URL: https://svnweb.freebsd.org/changeset/base/334971
> 
> Log:
>   Document the newly enforced 524288 inode restriction.
> 
> Modified:
>   head/sbin/dump/dump.8
> 
> Modified: head/sbin/dump/dump.8
> ==
> --- head/sbin/dump/dump.8 Mon Jun 11 19:32:40 2018(r334970)
> +++ head/sbin/dump/dump.8 Mon Jun 11 19:32:45 2018(r334971)
> @@ -29,7 +29,7 @@
>  .\" @(#)dump.8   8.3 (Berkeley) 5/1/95
>  .\" $FreeBSD$
>  .\"
> -.Dd October 3, 2016
> +.Dd June 11, 2018
>  .Dt DUMP 8
>  .Os
>  .Sh NAME
> @@ -566,3 +566,8 @@ This will be fixed in a later version of
>  .Fx .
>  Presently, it works if you set it setuid (like it used to be), but this
>  might constitute a security risk.
> +.Pp
> +It is not possible to safely dump filesystems that use more than
> +524288 inodes.
> +.Nm
> +refuses to dump any filesystem that has more than 524288 inodes.
> ___
> svn-src-h...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Hello.

Is this limitation going to be eternal or are efforts being made to make it
possible to go beyond this limitations? Just for curiosity ...

Thanks in advance,

oh
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334986 - head/stand/lua

[Kyle Evans]

Author: kevans
Date: Tue Jun 12 03:44:34 2018
New Revision: 334986
URL: https://svnweb.freebsd.org/changeset/base/334986

Log:
  lualoader: More black-on-white fixes
  
  To recap the problem: with a black-on-white xterm, the menu draws terribly.
  Ideally, we would try our best for a white-on-black context for the menu
  since graphics and whatnot might not be tested for other setups and there's
  no reasonable way to sample the terminal at this point for the used color
  scheme.
  
  This commit attempts to address that further in two ways:
  - Instead of issuing CSI bg/fg resets (CSI 39m and CSI 49m respectively for
"default"), issue CSI bg/fg escape sequences for our expected color scheme
  - Reset to *our* default color scheme before we even attempt to load the
local module, so that we personally don't have any earlier text with the
console default color scheme.
  
  Reported by:  emaste (again)

Modified:
  head/stand/lua/color.lua
  head/stand/lua/loader.lua

Modified: head/stand/lua/color.lua
==
--- head/stand/lua/color.luaTue Jun 12 01:50:58 2018(r334985)
+++ head/stand/lua/color.luaTue Jun 12 03:44:34 2018(r334986)
@@ -69,7 +69,7 @@ function color.resetfg()
if color.disabled then
return ''
end
-   return core.KEYSTR_CSI .. "39m"
+   return color.escapefg(color.WHITE)
 end
 
 function color.escapebg(color_value)
@@ -83,7 +83,7 @@ function color.resetbg()
if color.disabled then
return ''
end
-   return core.KEYSTR_CSI .. "49m"
+   return color.escapebg(color.BLACK)
 end
 
 function color.escape(fg_color, bg_color, attribute)

Modified: head/stand/lua/loader.lua
==
--- head/stand/lua/loader.lua   Tue Jun 12 01:50:58 2018(r334985)
+++ head/stand/lua/loader.lua   Tue Jun 12 03:44:34 2018(r334986)
@@ -42,6 +42,12 @@ local password = require("password")
 -- need it.
 local menu
 
+-- Our console may have been setup for a different color scheme before we get
+-- here, so make sure we set the default.
+if color.isEnabled() then
+   printc(color.default())
+end
+
 try_include("local")
 
 config.load()
@@ -50,11 +56,6 @@ if not core.isMenuSkipped() then
 end
 if core.isUEFIBoot() then
loader.perform("efi-autoresizecons")
-end
--- Our console may have been setup for a different color scheme before we get
--- here, so make sure we set the default.
-if color.isEnabled() then
-   printc(color.default())
 end
 password.check()
 -- menu might be disabled
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Warner Losh]

On Mon, Jun 11, 2018 at 6:23 PM, Devin Teske  wrote:

>
> On Jun 11, 2018, at 11:20 AM, Warner Losh  wrote:
>
>
>
> On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  wrote:
>
>>
>> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
>>
>>
>>
>> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:
>>
>>>
>>>
>>> > On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
>>> >
>>> > Author: kevans
>>> > Date: Mon Jun 11 01:32:18 2018
>>> > New Revision: 334939
>>> > URL: https://svnweb.freebsd.org/changeset/base/334939
>>> >
>>> > Log:
>>> >  lualoader: Allow brand-*.lua for adding new brands
>>> >
>>> >  dteske@, I believe, had originally pointed out that lualoader failed
>>> to
>>> >  allow logo-*.lua for new logos to be added. When correcting this
>>> mistake, I
>>> >  failed to do the same for brands.
>>> >
>>>
>>> You’re doing an amazing job, Kyle.
>>>
>>> I continually see nothing but genuine effort toward feature parity which
>>> makes me think one day I can pass the reigns.
>>>
>>> Yeah, I will always love Forth. It will always hold a special place in
>>> my heart as that whacky language that simultaneously exudes great power
>>> while also having the image ability to induce vomiting 冷 by the
>>> uninitiated.
>>>
>>> However, all that being said, I’d actually like to keep the Ficl boot
>>> stuff as an option through to 14.0 and here is why ...
>>>
>>> Last year we were looking to update from ficl3 to ficl4. That may not
>>> sound too exciting to most folks, but most folks don’t know the power that
>>> ficl4 brings — like the capability to use full networking in the loader!
>>> Can lua do that? How cool would it be to be able to communicate with the
>>> network from the loader before the kernel is even loaded into memory? I had
>>> a few hair-brained schemes left for Forth which might be exciting, lol
>>>
>>
>> The current boot loader can already communicate via NFS or TFTP today.
>> Adding http would be easy, https would be harder due to crypto being huge
>> and space being small (though bear ssl might be small enough).
>>
>> The last articulated plan in arch@ was that LUA will be default in 12,
>> and we plan to remove FORTH in 13. Last time I said it there in February,
>> there was only email agreeing that I could find. This matches the in-person
>> consensus poll I took at BSDcan as well. I think it would take a very
>> extraordinary set circumstance and severe problems with LUA to change those
>> plans.
>>
>>
>> At BSD Can there was the boot working group where we discussed that an
>> FCP would be required to decide this.
>>
>
> In the working group you weren't listening and being rather combative and
> demanding that I do stuff,
>
>
> I think that's an unfair characterization of the situation, but it doesn't
> matter -- that's your opinion and you are entitled to it.
>
>
>
> so I stopped talking.
>
>
> Hopefully we can _start_ talking. As the principled author of this work, I
> want to have a say in its deprecation since I still maintain that body of
> work.
>
>
> It should not be taken as a sign of my consent, but more a sign of not
> wanting to get into a yelling match in public on a topic I thought had been
> settled months ago.
>
>
> Nobody asked *me* about how I would like to see *my* work removed from the
> tree. I think I should have a say.
>
> I think I've been pretty darn helpful in the process by providing
> substantive and helpful feedback to not only Kyle but also on the GSoC
> project etc. I've not stood in any ones way. For being so helpful, I would
> expect a level respect in this matter.
>
>
>
> I raised my desires that I would like to be able to flip a knob in 13 and
>> reboot between Ficl and Lua, back and forth.
>>
>> Give people a choice until we have done a "shake-out" through an entire
>> major version.
>>
>> An honest-to-goodness procession would be, in my mind:
>>
>> 13: Has both; both are installed. End-user can boot back and forth
>> between the two
>>
>> Problems that arise in one or the other are non-critical because there is
>> always an "out" by running the other.
>>
>> 14: Has both but both are not installed. The installer media doesn't even
>> have it. You can't install the Forth booth stuff unless you twist a knob in
>> buildworld, optionally going down the path of generating release media
>> which has the Forth boot stuff.
>>
>> 15. It's removed from tree. You can't build Forth boot. Lua only. No
>> looking back, no way to build it with Forth, to get Ficl you need to go to
>> ports. A Ficl with FreeBSD boot words no longer exists and is no longer
>> maintained. All of bhyve userboot also therefore uses Lua.
>>
>
> That's way too long. 12 will have Lua by default, but you can build FORTH
> if you want has been the plan since February when I socialized this on arch@.
> I originally pitched coexistence, but there was little appetite for that.
>
> So I think a FCP discussed in arch@ is the right path forward.
>
>
> We sat on the GSoC for years. Why all of a sudden do we need to 

Re: svn commit: r334939 - head/stand/lua

[Warner Losh]

On Mon, Jun 11, 2018 at 6:43 PM, Kyle Evans  wrote:

> On Mon, Jun 11, 2018 at 7:34 PM, Devin Teske  wrote:
>
> Are you at feature parity yet?
>
> Basically, yeah. There's a couple of environment variables not
> respected that I could easily implement given, say, an hour or two.
> OTOH, 'feature parity' is slightly rough to define as one has to weed
> out what still makes sense in the Lua-based world vs. what gets a more
> Lua-ish way of accomplishing the same task (e.g. with menu stuff).
>

When the FCP thread starts in arch@, we should include these items in the
list of pros/cons for Lua. Maybe they are important, or maybe not, but to
decide we need to know what they are.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334985 - head/sbin/geom/class/part

[Li-Wen Hsu]

Author: lwhsu (ports committer)
Date: Tue Jun 12 01:50:58 2018
New Revision: 334985
URL: https://svnweb.freebsd.org/changeset/base/334985

Log:
  Follow r333233, add fat32lba description to gpart(8)
  
  Reviewed by:  emaste
  MFC after:3 days
  X-MFC with:   r333233
  Sponsored by: The FreeBSD Foundation
  Differential Revision:https://reviews.freebsd.org/D15767

Modified:
  head/sbin/geom/class/part/gpart.8

Modified: head/sbin/geom/class/part/gpart.8
==
--- head/sbin/geom/class/part/gpart.8   Tue Jun 12 01:24:48 2018
(r334984)
+++ head/sbin/geom/class/part/gpart.8   Tue Jun 12 01:50:58 2018
(r334985)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd May 11, 2018
+.Dd June 11, 2018
 .Dt GPART 8
 .Os
 .Sh NAME
@@ -806,6 +806,11 @@ for MBR.
 A partition that contains a FAT32 filesystem.
 The scheme-specific type is
 .Qq Li "!11"
+for MBR.
+.It Cm fat32lba
+A partition that contains a FAT32 (LBA) filesystem.
+The scheme-specific type is
+.Qq Li "!12"
 for MBR.
 .It Cm linux-data
 A Linux partition that contains some filesystem with data.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Kyle Evans]

On Mon, Jun 11, 2018 at 7:34 PM, Devin Teske  wrote:
>
> On Jun 11, 2018, at 5:32 PM, Kyle Evans  wrote:
>
> On Mon, Jun 11, 2018 at 7:23 PM, Devin Teske  wrote:
>
>
> On Jun 11, 2018, at 11:20 AM, Warner Losh  wrote:
>
>
>
> On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  wrote:
>
>
>
> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
>
>
>
> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:
>
>
>
>
> On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
>
> Author: kevans
> Date: Mon Jun 11 01:32:18 2018
> New Revision: 334939
> URL: https://svnweb.freebsd.org/changeset/base/334939
>
> Log:
> lualoader: Allow brand-*.lua for adding new brands
>
> dteske@, I believe, had originally pointed out that lualoader failed
> to
> allow logo-*.lua for new logos to be added. When correcting this
> mistake, I
> failed to do the same for brands.
>
>
> You’re doing an amazing job, Kyle.
>
> I continually see nothing but genuine effort toward feature parity which
> makes me think one day I can pass the reigns.
>
> Yeah, I will always love Forth. It will always hold a special place in my
> heart as that whacky language that simultaneously exudes great power while
> also having the image ability to induce vomiting 冷 by the uninitiated.
>
> However, all that being said, I’d actually like to keep the Ficl boot
> stuff as an option through to 14.0 and here is why ...
>
> Last year we were looking to update from ficl3 to ficl4. That may not
> sound too exciting to most folks, but most folks don’t know the power that
> ficl4 brings — like the capability to use full networking in the loader! Can
> lua do that? How cool would it be to be able to communicate with the network
> from the loader before the kernel is even loaded into memory? I had a few
> hair-brained schemes left for Forth which might be exciting, lol
>
>
>
> The current boot loader can already communicate via NFS or TFTP today.
> Adding http would be easy, https would be harder due to crypto being huge
> and space being small (though bear ssl might be small enough).
>
> The last articulated plan in arch@ was that LUA will be default in 12, and
> we plan to remove FORTH in 13. Last time I said it there in February, there
> was only email agreeing that I could find. This matches the in-person
> consensus poll I took at BSDcan as well. I think it would take a very
> extraordinary set circumstance and severe problems with LUA to change those
> plans.
>
>
> At BSD Can there was the boot working group where we discussed that an FCP
> would be required to decide this.
>
>
>
> In the working group you weren't listening and being rather combative and
> demanding that I do stuff,
>
>
> I think that's an unfair characterization of the situation, but it doesn't
> matter -- that's your opinion and you are entitled to it.
>
>
>
> so I stopped talking.
>
>
> Hopefully we can _start_ talking. As the principled author of this work, I
> want to have a say in its deprecation since I still maintain that body of
> work.
>
>
> It should not be taken as a sign of my consent, but more a sign of not
> wanting to get into a yelling match in public on a topic I thought had been
> settled months ago.
>
>
> Nobody asked *me* about how I would like to see *my* work removed from the
> tree. I think I should have a say.
>
> I think I've been pretty darn helpful in the process by providing
> substantive and helpful feedback to not only Kyle but also on the GSoC
> project etc. I've not stood in any ones way. For being so helpful, I would
> expect a level respect in this matter.
>
>
>
> I raised my desires that I would like to be able to flip a knob in 13 and
> reboot between Ficl and Lua, back and forth.
>
> Give people a choice until we have done a "shake-out" through an entire
> major version.
>
> An honest-to-goodness procession would be, in my mind:
>
> 13: Has both; both are installed. End-user can boot back and forth between
> the two
>
> Problems that arise in one or the other are non-critical because there is
> always an "out" by running the other.
>
> 14: Has both but both are not installed. The installer media doesn't even
> have it. You can't install the Forth booth stuff unless you twist a knob in
> buildworld, optionally going down the path of generating release media which
> has the Forth boot stuff.
>
> 15. It's removed from tree. You can't build Forth boot. Lua only. No
> looking back, no way to build it with Forth, to get Ficl you need to go to
> ports. A Ficl with FreeBSD boot words no longer exists and is no longer
> maintained. All of bhyve userboot also therefore uses Lua.
>
>
>
> That's way too long. 12 will have Lua by default, but you can build FORTH if
> you want has been the plan since February when I socialized this on arch@. I
> originally pitched coexistence, but there was little appetite for that.
>
> So I think a FCP discussed in arch@ is the right path forward.
>
>
> We sat on the GSoC for years. Why all of a sudden do we need to ship this in
> less than 6 months?
>
> 

Re: svn commit: r334939 - head/stand/lua

[Devin Teske]

> On Jun 11, 2018, at 5:32 PM, Kyle Evans  wrote:
> 
> On Mon, Jun 11, 2018 at 7:23 PM, Devin Teske  > wrote:
>> 
>> On Jun 11, 2018, at 11:20 AM, Warner Losh  wrote:
>> 
>> 
>> 
>> On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  wrote:
>>> 
>>> 
>>> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:
 
 
 
> On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
> 
> Author: kevans
> Date: Mon Jun 11 01:32:18 2018
> New Revision: 334939
> URL: https://svnweb.freebsd.org/changeset/base/334939
> 
> Log:
> lualoader: Allow brand-*.lua for adding new brands
> 
> dteske@, I believe, had originally pointed out that lualoader failed
> to
> allow logo-*.lua for new logos to be added. When correcting this
> mistake, I
> failed to do the same for brands.
> 
 
 You’re doing an amazing job, Kyle.
 
 I continually see nothing but genuine effort toward feature parity which
 makes me think one day I can pass the reigns.
 
 Yeah, I will always love Forth. It will always hold a special place in my
 heart as that whacky language that simultaneously exudes great power while
 also having the image ability to induce vomiting 冷 by the uninitiated.
 
 However, all that being said, I’d actually like to keep the Ficl boot
 stuff as an option through to 14.0 and here is why ...
 
 Last year we were looking to update from ficl3 to ficl4. That may not
 sound too exciting to most folks, but most folks don’t know the power that
 ficl4 brings — like the capability to use full networking in the loader! 
 Can
 lua do that? How cool would it be to be able to communicate with the 
 network
 from the loader before the kernel is even loaded into memory? I had a few
 hair-brained schemes left for Forth which might be exciting, lol
>>> 
>>> 
>>> The current boot loader can already communicate via NFS or TFTP today.
>>> Adding http would be easy, https would be harder due to crypto being huge
>>> and space being small (though bear ssl might be small enough).
>>> 
>>> The last articulated plan in arch@ was that LUA will be default in 12, and
>>> we plan to remove FORTH in 13. Last time I said it there in February, there
>>> was only email agreeing that I could find. This matches the in-person
>>> consensus poll I took at BSDcan as well. I think it would take a very
>>> extraordinary set circumstance and severe problems with LUA to change those
>>> plans.
>>> 
>>> 
>>> At BSD Can there was the boot working group where we discussed that an FCP
>>> would be required to decide this.
>> 
>> 
>> In the working group you weren't listening and being rather combative and
>> demanding that I do stuff,
>> 
>> 
>> I think that's an unfair characterization of the situation, but it doesn't
>> matter -- that's your opinion and you are entitled to it.
>> 
>> 
>> 
>> so I stopped talking.
>> 
>> 
>> Hopefully we can _start_ talking. As the principled author of this work, I
>> want to have a say in its deprecation since I still maintain that body of
>> work.
>> 
>> 
>> It should not be taken as a sign of my consent, but more a sign of not
>> wanting to get into a yelling match in public on a topic I thought had been
>> settled months ago.
>> 
>> 
>> Nobody asked *me* about how I would like to see *my* work removed from the
>> tree. I think I should have a say.
>> 
>> I think I've been pretty darn helpful in the process by providing
>> substantive and helpful feedback to not only Kyle but also on the GSoC
>> project etc. I've not stood in any ones way. For being so helpful, I would
>> expect a level respect in this matter.
>> 
>> 
>> 
>>> I raised my desires that I would like to be able to flip a knob in 13 and
>>> reboot between Ficl and Lua, back and forth.
>>> 
>>> Give people a choice until we have done a "shake-out" through an entire
>>> major version.
>>> 
>>> An honest-to-goodness procession would be, in my mind:
>>> 
>>> 13: Has both; both are installed. End-user can boot back and forth between
>>> the two
>>> 
>>> Problems that arise in one or the other are non-critical because there is
>>> always an "out" by running the other.
>>> 
>>> 14: Has both but both are not installed. The installer media doesn't even
>>> have it. You can't install the Forth booth stuff unless you twist a knob in
>>> buildworld, optionally going down the path of generating release media which
>>> has the Forth boot stuff.
>>> 
>>> 15. It's removed from tree. You can't build Forth boot. Lua only. No
>>> looking back, no way to build it with Forth, to get Ficl you need to go to
>>> ports. A Ficl with FreeBSD boot words no longer exists and is no longer
>>> maintained. All of bhyve userboot also therefore uses Lua.
>> 
>> 
>> That's way too long. 12 will have Lua by default, but you can build FORTH if
>> you want has been the plan since 

Re: svn commit: r334939 - head/stand/lua

[Kyle Evans]

On Mon, Jun 11, 2018 at 7:23 PM, Devin Teske  wrote:
>
> On Jun 11, 2018, at 11:20 AM, Warner Losh  wrote:
>
>
>
> On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  wrote:
>>
>>
>> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
>>
>>
>>
>> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:
>>>
>>>
>>>
>>> > On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
>>> >
>>> > Author: kevans
>>> > Date: Mon Jun 11 01:32:18 2018
>>> > New Revision: 334939
>>> > URL: https://svnweb.freebsd.org/changeset/base/334939
>>> >
>>> > Log:
>>> >  lualoader: Allow brand-*.lua for adding new brands
>>> >
>>> >  dteske@, I believe, had originally pointed out that lualoader failed
>>> > to
>>> >  allow logo-*.lua for new logos to be added. When correcting this
>>> > mistake, I
>>> >  failed to do the same for brands.
>>> >
>>>
>>> You’re doing an amazing job, Kyle.
>>>
>>> I continually see nothing but genuine effort toward feature parity which
>>> makes me think one day I can pass the reigns.
>>>
>>> Yeah, I will always love Forth. It will always hold a special place in my
>>> heart as that whacky language that simultaneously exudes great power while
>>> also having the image ability to induce vomiting 冷 by the uninitiated.
>>>
>>> However, all that being said, I’d actually like to keep the Ficl boot
>>> stuff as an option through to 14.0 and here is why ...
>>>
>>> Last year we were looking to update from ficl3 to ficl4. That may not
>>> sound too exciting to most folks, but most folks don’t know the power that
>>> ficl4 brings — like the capability to use full networking in the loader! Can
>>> lua do that? How cool would it be to be able to communicate with the network
>>> from the loader before the kernel is even loaded into memory? I had a few
>>> hair-brained schemes left for Forth which might be exciting, lol
>>
>>
>> The current boot loader can already communicate via NFS or TFTP today.
>> Adding http would be easy, https would be harder due to crypto being huge
>> and space being small (though bear ssl might be small enough).
>>
>> The last articulated plan in arch@ was that LUA will be default in 12, and
>> we plan to remove FORTH in 13. Last time I said it there in February, there
>> was only email agreeing that I could find. This matches the in-person
>> consensus poll I took at BSDcan as well. I think it would take a very
>> extraordinary set circumstance and severe problems with LUA to change those
>> plans.
>>
>>
>> At BSD Can there was the boot working group where we discussed that an FCP
>> would be required to decide this.
>
>
> In the working group you weren't listening and being rather combative and
> demanding that I do stuff,
>
>
> I think that's an unfair characterization of the situation, but it doesn't
> matter -- that's your opinion and you are entitled to it.
>
>
>
> so I stopped talking.
>
>
> Hopefully we can _start_ talking. As the principled author of this work, I
> want to have a say in its deprecation since I still maintain that body of
> work.
>
>
> It should not be taken as a sign of my consent, but more a sign of not
> wanting to get into a yelling match in public on a topic I thought had been
> settled months ago.
>
>
> Nobody asked *me* about how I would like to see *my* work removed from the
> tree. I think I should have a say.
>
> I think I've been pretty darn helpful in the process by providing
> substantive and helpful feedback to not only Kyle but also on the GSoC
> project etc. I've not stood in any ones way. For being so helpful, I would
> expect a level respect in this matter.
>
>
>
>> I raised my desires that I would like to be able to flip a knob in 13 and
>> reboot between Ficl and Lua, back and forth.
>>
>> Give people a choice until we have done a "shake-out" through an entire
>> major version.
>>
>> An honest-to-goodness procession would be, in my mind:
>>
>> 13: Has both; both are installed. End-user can boot back and forth between
>> the two
>>
>> Problems that arise in one or the other are non-critical because there is
>> always an "out" by running the other.
>>
>> 14: Has both but both are not installed. The installer media doesn't even
>> have it. You can't install the Forth booth stuff unless you twist a knob in
>> buildworld, optionally going down the path of generating release media which
>> has the Forth boot stuff.
>>
>> 15. It's removed from tree. You can't build Forth boot. Lua only. No
>> looking back, no way to build it with Forth, to get Ficl you need to go to
>> ports. A Ficl with FreeBSD boot words no longer exists and is no longer
>> maintained. All of bhyve userboot also therefore uses Lua.
>
>
> That's way too long. 12 will have Lua by default, but you can build FORTH if
> you want has been the plan since February when I socialized this on arch@. I
> originally pitched coexistence, but there was little appetite for that.
>
> So I think a FCP discussed in arch@ is the right path forward.
>
>
> We sat on the GSoC for years. Why all of a sudden do we need to 

Re: svn commit: r334939 - head/stand/lua

[Devin Teske]

> On Jun 11, 2018, at 11:20 AM, Warner Losh  wrote:
> 
> 
> 
> On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  > wrote:
> 
>> On Jun 11, 2018, at 7:07 AM, Warner Losh > > wrote:
>> 
>> 
>> 
>> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske > > wrote:
>> 
>> 
>> > On Jun 10, 2018, at 6:32 PM, Kyle Evans > > > wrote:
>> > 
>> > Author: kevans
>> > Date: Mon Jun 11 01:32:18 2018
>> > New Revision: 334939
>> > URL: https://svnweb.freebsd.org/changeset/base/334939 
>> > 
>> > 
>> > Log:
>> >  lualoader: Allow brand-*.lua for adding new brands
>> > 
>> >  dteske@, I believe, had originally pointed out that lualoader failed to
>> >  allow logo-*.lua for new logos to be added. When correcting this mistake, 
>> > I
>> >  failed to do the same for brands.
>> > 
>> 
>> You’re doing an amazing job, Kyle.
>> 
>> I continually see nothing but genuine effort toward feature parity which 
>> makes me think one day I can pass the reigns.
>> 
>> Yeah, I will always love Forth. It will always hold a special place in my 
>> heart as that whacky language that simultaneously exudes great power while 
>> also having the image ability to induce vomiting 冷 by the uninitiated.
>> 
>> However, all that being said, I’d actually like to keep the Ficl boot stuff 
>> as an option through to 14.0 and here is why ...
>> 
>> Last year we were looking to update from ficl3 to ficl4. That may not sound 
>> too exciting to most folks, but most folks don’t know the power that ficl4 
>> brings — like the capability to use full networking in the loader! Can lua 
>> do that? How cool would it be to be able to communicate with the network 
>> from the loader before the kernel is even loaded into memory? I had a few 
>> hair-brained schemes left for Forth which might be exciting, lol
>> 
>> The current boot loader can already communicate via NFS or TFTP today. 
>> Adding http would be easy, https would be harder due to crypto being huge 
>> and space being small (though bear ssl might be small enough).
>> 
>> The last articulated plan in arch@ was that LUA will be default in 12, and 
>> we plan to remove FORTH in 13. Last time I said it there in February, there 
>> was only email agreeing that I could find. This matches the in-person 
>> consensus poll I took at BSDcan as well. I think it would take a very 
>> extraordinary set circumstance and severe problems with LUA to change those 
>> plans.
>> 
> 
> At BSD Can there was the boot working group where we discussed that an FCP 
> would be required to decide this.
> 
> In the working group you weren't listening and being rather combative and 
> demanding that I do stuff,

I think that's an unfair characterization of the situation, but it doesn't 
matter -- that's your opinion and you are entitled to it.



> so I stopped talking.

Hopefully we can _start_ talking. As the principled author of this work, I want 
to have a say in its deprecation since I still maintain that body of work.


> It should not be taken as a sign of my consent, but more a sign of not 
> wanting to get into a yelling match in public on a topic I thought had been 
> settled months ago.
> 

Nobody asked *me* about how I would like to see *my* work removed from the 
tree. I think I should have a say.

I think I've been pretty darn helpful in the process by providing substantive 
and helpful feedback to not only Kyle but also on the GSoC project etc. I've 
not stood in any ones way. For being so helpful, I would expect a level respect 
in this matter.



> I raised my desires that I would like to be able to flip a knob in 13 and 
> reboot between Ficl and Lua, back and forth.
> 
> Give people a choice until we have done a "shake-out" through an entire major 
> version.
> 
> An honest-to-goodness procession would be, in my mind:
> 
> 13: Has both; both are installed. End-user can boot back and forth between 
> the two
> 
> Problems that arise in one or the other are non-critical because there is 
> always an "out" by running the other.
> 
> 14: Has both but both are not installed. The installer media doesn't even 
> have it. You can't install the Forth booth stuff unless you twist a knob in 
> buildworld, optionally going down the path of generating release media which 
> has the Forth boot stuff.
> 
> 15. It's removed from tree. You can't build Forth boot. Lua only. No looking 
> back, no way to build it with Forth, to get Ficl you need to go to ports. A 
> Ficl with FreeBSD boot words no longer exists and is no longer maintained. 
> All of bhyve userboot also therefore uses Lua.
> 
> That's way too long. 12 will have Lua by default, but you can build FORTH if 
> you want has been the plan since February when I socialized this on arch@. I 
> originally pitched coexistence, but there was little appetite for that.
> 
> So I think a FCP discussed in arch@ is the right path forward.
> 

svn commit: r334983 - head/sys/net

[Jonathan T. Looney]

Author: jtl
Date: Mon Jun 11 23:32:06 2018
New Revision: 334983
URL: https://svnweb.freebsd.org/changeset/base/334983

Log:
  Fix a memory leak for the BIOCSETWF ioctl on kernels with the BPF_JITTER
  option.
  
  The BPF code was creating a compiled filter in the common filter-creation
  path.  However, BPF only uses compiled filters in the read direction.
  When creating a write filter, the common filter-creation code was
  creating an unneeded write filter and leaking the memory used for that.
  
  MFC after:2 weeks
  Sponsored by: Netflix

Modified:
  head/sys/net/bpf.c

Modified: head/sys/net/bpf.c
==
--- head/sys/net/bpf.c  Mon Jun 11 22:48:34 2018(r334982)
+++ head/sys/net/bpf.c  Mon Jun 11 23:32:06 2018(r334983)
@@ -1895,8 +1895,13 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_lo
return (EINVAL);
}
 #ifdef BPF_JITTER
-   /* Filter is copied inside fcode and is perfectly valid. */
-   jfunc = bpf_jitter(fcode, flen);
+   if (cmd != BIOCSETWF) {
+   /*
+* Filter is copied inside fcode and is
+* perfectly valid.
+*/
+   jfunc = bpf_jitter(fcode, flen);
+   }
 #endif
}
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334982 - in head/etc: . devd

[Warner Losh]

Author: imp
Date: Mon Jun 11 22:48:34 2018
New Revision: 334982
URL: https://svnweb.freebsd.org/changeset/base/334982

Log:
  User service foo rather than /etc/rc.d/foo.
  
  devd predates service in the system. Modernize usage to use service to
  start/stop things in reaction to events rather than calling the rc
  file directly.
  
  This was pointed out in my talk at BSDcan as well as indirectly
  referrred to as a barrier to entry for OpenRC in that working group.

Modified:
  head/etc/devd.conf
  head/etc/devd/apple.conf
  head/etc/devd/devmatch.conf

Modified: head/etc/devd.conf
==
--- head/etc/devd.conf  Mon Jun 11 20:46:20 2018(r334981)
+++ head/etc/devd.conf  Mon Jun 11 22:48:34 2018(r334982)
@@ -57,7 +57,7 @@ notify 0 {
match "system"  "IFNET";
match "type""LINK_UP";
media-type  "ethernet";
-   action "/etc/rc.d/dhclient quietstart $subsystem";
+   action "service dhclient quietstart $subsystem";
 };
 
 #
@@ -76,7 +76,7 @@ notify 0 {
match "system"  "IFNET";
match "type""LINK_UP";
media-type  "802.11";
-   action "/etc/rc.d/dhclient quietstart $subsystem";
+   action "service dhclient quietstart $subsystem";
 };
 
 # An entry like this might be in a different file, but is included here
@@ -94,11 +94,11 @@ detach 100 {
 # When a USB Bluetooth dongle appears, activate it
 attach 100 {
device-name "ubt[0-9]+";
-   action "/etc/rc.d/bluetooth quietstart $device-name";
+   action "service bluetooth quietstart $device-name";
 };
 detach 100 {
device-name "ubt[0-9]+";
-   action "/etc/rc.d/bluetooth quietstop $device-name";
+   action "service bluetooth quietstop $device-name";
 };
 
 # Firmware downloader for Atheros AR3011 based USB Bluetooth devices
@@ -111,11 +111,11 @@ detach 100 {
 # When a USB keyboard arrives, attach it as the console keyboard.
 attach 100 {
device-name "ukbd0";
-   action "/etc/rc.d/syscons setkeyboard /dev/ukbd0";
+   action "service syscons setkeyboard /dev/ukbd0";
 };
 detach 100 {
device-name "ukbd0";
-   action "/etc/rc.d/syscons setkeyboard /dev/kbd0";
+   action "service syscons setkeyboard /dev/kbd0";
 };
 
 notify 100 {
@@ -124,7 +124,7 @@ notify 100 {
match "type" "CREATE";
match "cdev" "atp[0-9]+";
 
-   action "/etc/rc.d/moused quietstart $cdev";
+   action "service moused quietstart $cdev";
 };
 
 notify 100 {
@@ -133,7 +133,7 @@ notify 100 {
match "type" "CREATE";
match "cdev" "ums[0-9]+";
 
-   action "/etc/rc.d/moused quietstart $cdev";
+   action "service moused quietstart $cdev";
 };
 
 notify 100 {
@@ -142,7 +142,7 @@ notify 100 {
match "type" "CREATE";
match "cdev" "wsp[0-9]+";
 
-   action "/etc/rc.d/moused quietstart $cdev";
+   action "service moused quietstart $cdev";
 };
 
 notify 100 {
@@ -151,7 +151,7 @@ notify 100 {
match "type" "DESTROY";
match "cdev" "ums[0-9]+";
 
-   action "/etc/rc.d/moused stop $cdev";
+   action "service moused stop $cdev";
 };
 
 # Firmware download into the ActiveWire board. After the firmware download is
@@ -236,7 +236,7 @@ nomatch 10 {
 notify 10 {
match "system"  "ACPI";
match "subsystem"   "ACAD";
-   action "/etc/rc.d/power_profile $notify";
+   action "service power_profile $notify";
 };
 
 # Notify all users before beginning emergency shutdown when we get
@@ -317,7 +317,7 @@ notify 10 {
 notify 0 {
match "system"  "RCTL";
match "rule""user:770:swap:.*";
-   action  "/usr/local/etc/rc.d/postgresql restart";
+   action  "service postgresql restart";
 };
 
 # Discard autofs caches, useful for the -media special map.

Modified: head/etc/devd/apple.conf
==
--- head/etc/devd/apple.confMon Jun 11 20:46:20 2018(r334981)
+++ head/etc/devd/apple.confMon Jun 11 22:48:34 2018(r334982)
@@ -76,5 +76,5 @@ notify 10 {
match "system"  "PMU";
match "subsystem"   "POWER";
match "type""ACLINE";
-   action "/etc/rc.d/power_profile $notify";
+   action "service power_profile $notify";
 };

Modified: head/etc/devd/devmatch.conf
==
--- head/etc/devd/devmatch.conf Mon Jun 11 20:46:20 2018(r334981)
+++ head/etc/devd/devmatch.conf Mon Jun 11 22:48:34 2018(r334982)
@@ -9,7 +9,7 @@
 #
 # Generic NOMATCH event
 nomatch 100 {
-   action "/etc/rc.d/devmatch start '?$_'";
+   action "service devmatch start '?$_'";
 };
 
 # Add the following to devd.conf to prevent this from running:

Re: svn commit: r334221 - head/etc

[Ian Lepore]

On Mon, 2018-06-11 at 17:29 -0500, Mark Felder wrote:
> 
> On Sun, May 27, 2018, at 01:09, Alexey Dokuchaev wrote:
> > 
> > On Fri, May 25, 2018 at 07:36:26PM +, Mark Felder wrote:
> > > 
> > > New Revision: 334221
> > > URL: https://svnweb.freebsd.org/changeset/base/334221
> > > 
> > > Log:
> > >   rc.subr: Support loading environmental variables from a file
> > >   
> > > + if [ -n "$_env_file" ] && [ -r "${_env_file}" ]; then
> > Style bug: "$_env_file" vs. "${_env_file}".  Also, isn't the -n
> > check
> > redundant?
> The entire rc.subr file seems to be full of style inconsistencies.
> I'd take the time to fix it if there would be no objections. As per
> redundancy, it's copy+paste of what mat suggested. I suppose the -r
> will fail if the variable is not set, so it would indeed be
> redundant. I didn't think of it that way.
> 

That will work as long as there are quotes around the arg to -r:

$ foo=""
$ [ -r ${foo} ] && echo good
good
$ [ -r "${foo}" ] && echo good
$ 

Same results if $foo is unset.

-- Ian
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334221 - head/etc

[Mark Felder]

On Sun, May 27, 2018, at 01:09, Alexey Dokuchaev wrote:
> On Fri, May 25, 2018 at 07:36:26PM +, Mark Felder wrote:
> > New Revision: 334221
> > URL: https://svnweb.freebsd.org/changeset/base/334221
> > 
> > Log:
> >   rc.subr: Support loading environmental variables from a file
> >   
> > +   if [ -n "$_env_file" ] && [ -r "${_env_file}" ]; then
> 
> Style bug: "$_env_file" vs. "${_env_file}".  Also, isn't the -n check
> redundant?

The entire rc.subr file seems to be full of style inconsistencies. I'd take the 
time to fix it if there would be no objections. As per redundancy, it's 
copy+paste of what mat suggested. I suppose the -r will fail if the variable is 
not set, so it would indeed be redundant. I didn't think of it that way.

> 
> > +   set -a
> > +   . $_env_file
> 
> Shouldn't it be quoted here as well (. "$_env_file")?
> 

It wouldn't hurt


Sorry about the late reply. I had a mistake in my sieve filters sending my mail 
to a wrong folder.


-- 
  Mark Felder
  ports-secteam & portmgr member
  f...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334970 - head

[Rodney W. Grimes]

> On Mon, Jun 11, 2018 at 2:01 PM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
> > > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > >
> > > > [ Charset UTF-8 unsupported, converting... ]
> > > > > Author: imp
> > > > > Date: Mon Jun 11 19:32:40 2018
> > > > > New Revision: 334970
> > > > > URL: https://svnweb.freebsd.org/changeset/base/334970
> > > > >
> > > > > Log:
> > > > >   Document the dump issue in UPDATING so people understand when they
> > > > >   get a new diagnostic.
> > > > >
> > > > > Modified:
> > > > >   head/UPDATING
> > > > >
> > > > > Modified: head/UPDATING
> > > > > 
> > > > ==
> > > > > --- head/UPDATING     Mon Jun 11 19:32:36 2018(r334969)
> > > > > +++ head/UPDATING Mon Jun 11 19:32:40 2018(r334970)
> > > > > @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS
> > SLOW:
> > > > >   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> > > > >
> > > > >
> > > > > +20180611:
> > > > > + A bug in dump has been found where it can incorrectly dump
> > > > filesystems
> > > > > + with more than 512k inodes and produce corrupted dump images.
> > > > r334968
> > > > > + closes the door by not dumping filesystems with more than 512k
> > > > inodes.
> > > > > + While older dumps may 'work' the image they produce may or may
> > not
> > > > be
> > > > > + readable depending on many factors.
> > > > > +
> > > >
> > > > Does it make since to put a temporary warning in newfs to warn users
> > > > of the "may bot be able to dump this fs" issue?
> > > >
> > >
> > > It does.
> > >
> > > However, there may have been an error in assessment, which I'm working
> > > through now. If so, there will be a revert.
> >
> > Ok, I am wondering some about this as I have:
> > Filesystem   1024-blocks  Used Avail Capacity iused
> >  ifree %iused  Mounted on
> > /dev/ada0s2h   473659989 417657089  1811010196%  918794
> > 479499082%   /mnt
> >
> > And have had that file system for at least a decade,
> > and it gets dump | restore on a fairly regular basis.
> 
> 
> Yea. Are you in a good position to test a fix for the core dump db@ was
> seeing? A dump /restore (though the restore should be to a second fs to
> test)

Yes, I have 4 spare drives that can be used as restore targets of
the above mentioned file system.  And actually have at least 2
copies of it already for sources, so it is just a mater of minutes
for me to set up a test bed.

> There's two things my fix does: (1) backs out the mistaken limit check and
> (2) doesn't walk through a list that's guaranteed to be bogus and fall off
> the end.
> 
> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334981 - head/share/man/man4

[Ed Maste]

Author: emaste
Date: Mon Jun 11 20:46:20 2018
New Revision: 334981
URL: https://svnweb.freebsd.org/changeset/base/334981

Log:
  muge.4: remove BUGS section (about link/act LEDs)
  
  Lack of functioning link and activity LEDs on devices without an EEPROM
  is expected (not a bug).  Quoting the EVB-LAN7850 User's Guide:
  
  When configured with the default internal register settings, the
  Ethernet Link status LEDs are not enabled.  To enable Ethernet Link
  status LEDs, enable the EEPROM.
  
  This is an artifact of the different ways in which the evaluation board
  can be used.  End-user USB-Ethernet adapters using the Microchip LAN78XX
  or LAN7515 controllers should use an EEPROM or have OTP configuration,
  if their product configuration does not match the boot default register
  configuration.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/share/man/man4/muge.4

Modified: head/share/man/man4/muge.4
==
--- head/share/man/man4/muge.4  Mon Jun 11 20:38:30 2018(r334980)
+++ head/share/man/man4/muge.4  Mon Jun 11 20:46:20 2018(r334981)
@@ -70,6 +70,3 @@ The
 .Nm
 device driver first appeared in
 .Fx 12.0 .
-.Sh BUGS
-USB-Ethernet adapters that use the LAN7850 without a configuration EEPROM
-may not activate link or activity LEDs.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334979 - head/sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 20:38:26 2018
New Revision: 334979
URL: https://svnweb.freebsd.org/changeset/base/334979

Log:
  Fix a bug in the counting of blks.
  
  We shouldn't count the bytes set in c_addr for TS_CLRI and TS_BITS
  nodes. Those block overload c_count to communicate how many blocks
  follow, not now many c_addr spaces are used. Dump would dump core
  (now) because memory layout moved around and we'd access elements past
  the end to make a count.
  
  Reviewed by: kib@

Modified:
  head/sbin/dump/tape.c

Modified: head/sbin/dump/tape.c
==
--- head/sbin/dump/tape.c   Mon Jun 11 20:26:10 2018(r334978)
+++ head/sbin/dump/tape.c   Mon Jun 11 20:38:26 2018(r334979)
@@ -279,7 +279,8 @@ flushtape(void)
}
 
blks = 0;
-   if (spcl.c_type != TS_END) {
+   if (spcl.c_type != TS_END && spcl.c_type != TS_CLRI &&
+   spcl.c_type != TS_BITS) {
assert(spcl.c_count <= TP_NINDIR);
for (i = 0; i < spcl.c_count; i++)
if (spcl.c_addr[i] != 0)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334980 - in head: . sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 20:38:30 2018
New Revision: 334980
URL: https://svnweb.freebsd.org/changeset/base/334980

Log:
  Revert size limits.
  
  The size limits came from a flawed understanding of dump records.
  The real issue was that dump was bogusly interpreting c_count
  sometimes. r334978 fixes that.

Modified:
  head/UPDATING
  head/sbin/dump/dump.8
  head/sbin/dump/main.c

Modified: head/UPDATING
==
--- head/UPDATING   Mon Jun 11 20:38:26 2018(r334979)
+++ head/UPDATING   Mon Jun 11 20:38:30 2018(r334980)
@@ -32,13 +32,6 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
 
-20180611:
-   A bug in dump has been found where it can incorrectly dump filesystems
-   with more than 512k inodes and produce corrupted dump images. r334968
-   closes the door by not dumping filesystems with more than 512k inodes.
-   While older dumps may 'work' the image they produce may or may not be
-   readable depending on many factors.
-
 20180530:
The kernel / userland interface for devinfo changed, so you'll
need a new kernel and userland as a pair for it to work (rebuilding

Modified: head/sbin/dump/dump.8
==
--- head/sbin/dump/dump.8   Mon Jun 11 20:38:26 2018(r334979)
+++ head/sbin/dump/dump.8   Mon Jun 11 20:38:30 2018(r334980)
@@ -566,8 +566,3 @@ This will be fixed in a later version of
 .Fx .
 Presently, it works if you set it setuid (like it used to be), but this
 might constitute a security risk.
-.Pp
-It is not possible to safely dump filesystems that use more than
-524288 inodes.
-.Nm
-refuses to dump any filesystem that has more than 524288 inodes.

Modified: head/sbin/dump/main.c
==
--- head/sbin/dump/main.c   Mon Jun 11 20:38:26 2018(r334979)
+++ head/sbin/dump/main.c   Mon Jun 11 20:38:30 2018(r334980)
@@ -100,7 +100,7 @@ main(int argc, char *argv[])
struct fstab *dt;
char *map, *mntpt;
int ch, mode, mntflags;
-   int i, ret, anydirskipped, c_count, bflag = 0, Tflag = 0, honorlevel = 
1;
+   int i, ret, anydirskipped, bflag = 0, Tflag = 0, honorlevel = 1;
int just_estimate = 0;
ino_t maxino;
char *tmsg;
@@ -452,9 +452,6 @@ main(int argc, char *argv[])
quit("TP_BSIZE (%d) is not a power of 2", TP_BSIZE);
maxino = sblock->fs_ipg * sblock->fs_ncg;
mapsize = roundup(howmany(maxino, CHAR_BIT), TP_BSIZE);
-   c_count = howmany(mapsize * sizeof(char), TP_BSIZE);
-   if (c_count > TP_NINDIR)
-   quit("fs is too large for dump!");
usedinomap = (char *)calloc((unsigned) mapsize, sizeof(char));
dumpdirmap = (char *)calloc((unsigned) mapsize, sizeof(char));
dumpinomap = (char *)calloc((unsigned) mapsize, sizeof(char));
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334977 - head/share/man/man4

[Ed Maste]

Author: emaste
Date: Mon Jun 11 20:19:20 2018
New Revision: 334977
URL: https://svnweb.freebsd.org/changeset/base/334977

Log:
  Connect muge.4 man page
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/share/man/man4/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileMon Jun 11 19:51:48 2018
(r334976)
+++ head/share/man/man4/MakefileMon Jun 11 20:19:20 2018
(r334977)
@@ -309,6 +309,7 @@ MAN=aac.4 \
msk.4 \
mtio.4 \
multicast.4 \
+   muge.4 \
mvs.4 \
mwl.4 \
mwlfw.4 \
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334970 - head

[Warner Losh]

On Mon, Jun 11, 2018 at 2:01 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
> > free...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > Author: imp
> > > > Date: Mon Jun 11 19:32:40 2018
> > > > New Revision: 334970
> > > > URL: https://svnweb.freebsd.org/changeset/base/334970
> > > >
> > > > Log:
> > > >   Document the dump issue in UPDATING so people understand when they
> > > >   get a new diagnostic.
> > > >
> > > > Modified:
> > > >   head/UPDATING
> > > >
> > > > Modified: head/UPDATING
> > > > 
> > > ==
> > > > --- head/UPDATING Mon Jun 11 19:32:36 2018(r334969)
> > > > +++ head/UPDATING Mon Jun 11 19:32:40 2018(r334970)
> > > > @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS
> SLOW:
> > > >   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> > > >
> > > >
> > > > +20180611:
> > > > + A bug in dump has been found where it can incorrectly dump
> > > filesystems
> > > > + with more than 512k inodes and produce corrupted dump images.
> > > r334968
> > > > + closes the door by not dumping filesystems with more than 512k
> > > inodes.
> > > > + While older dumps may 'work' the image they produce may or may
> not
> > > be
> > > > + readable depending on many factors.
> > > > +
> > >
> > > Does it make since to put a temporary warning in newfs to warn users
> > > of the "may bot be able to dump this fs" issue?
> > >
> >
> > It does.
> >
> > However, there may have been an error in assessment, which I'm working
> > through now. If so, there will be a revert.
>
> Ok, I am wondering some about this as I have:
> Filesystem   1024-blocks  Used Avail Capacity iused
>  ifree %iused  Mounted on
> /dev/ada0s2h   473659989 417657089  1811010196%  918794
> 479499082%   /mnt
>
> And have had that file system for at least a decade,
> and it gets dump | restore on a fairly regular basis.


Yea. Are you in a good position to test a fix for the core dump db@ was
seeing? A dump /restore (though the restore should be to a second fs to
test)

There's two things my fix does: (1) backs out the mistaken limit check and
(2) doesn't walk through a list that's guaranteed to be bogus and fall off
the end.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334970 - head

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > Author: imp
> > > Date: Mon Jun 11 19:32:40 2018
> > > New Revision: 334970
> > > URL: https://svnweb.freebsd.org/changeset/base/334970
> > >
> > > Log:
> > >   Document the dump issue in UPDATING so people understand when they
> > >   get a new diagnostic.
> > >
> > > Modified:
> > >   head/UPDATING
> > >
> > > Modified: head/UPDATING
> > > 
> > ==
> > > --- head/UPDATING Mon Jun 11 19:32:36 2018(r334969)
> > > +++ head/UPDATING Mon Jun 11 19:32:40 2018    (r334970)
> > > @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
> > >   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> > >
> > >
> > > +20180611:
> > > + A bug in dump has been found where it can incorrectly dump
> > filesystems
> > > + with more than 512k inodes and produce corrupted dump images.
> > r334968
> > > + closes the door by not dumping filesystems with more than 512k
> > inodes.
> > > + While older dumps may 'work' the image they produce may or may not
> > be
> > > + readable depending on many factors.
> > > +
> >
> > Does it make since to put a temporary warning in newfs to warn users
> > of the "may bot be able to dump this fs" issue?
> >
> 
> It does.
> 
> However, there may have been an error in assessment, which I'm working
> through now. If so, there will be a revert.

Ok, I am wondering some about this as I have:
Filesystem   1024-blocks  Used Avail Capacity iused 
ifree %iused  Mounted on
/dev/ada0s2h   473659989 417657089  1811010196%  918794  
479499082%   /mnt

And have had that file system for at least a decade,
and it gets dump | restore on a fairly regular basis.

> Warner

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334970 - head

[Warner Losh]

On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > Author: imp
> > Date: Mon Jun 11 19:32:40 2018
> > New Revision: 334970
> > URL: https://svnweb.freebsd.org/changeset/base/334970
> >
> > Log:
> >   Document the dump issue in UPDATING so people understand when they
> >   get a new diagnostic.
> >
> > Modified:
> >   head/UPDATING
> >
> > Modified: head/UPDATING
> > 
> ==
> > --- head/UPDATING Mon Jun 11 19:32:36 2018(r334969)
> > +++ head/UPDATING Mon Jun 11 19:32:40 2018(r334970)
> > @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
> >   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> >
> >
> > +20180611:
> > + A bug in dump has been found where it can incorrectly dump
> filesystems
> > + with more than 512k inodes and produce corrupted dump images.
> r334968
> > + closes the door by not dumping filesystems with more than 512k
> inodes.
> > + While older dumps may 'work' the image they produce may or may not
> be
> > + readable depending on many factors.
> > +
>
> Does it make since to put a temporary warning in newfs to warn users
> of the "may bot be able to dump this fs" issue?
>

It does.

However, there may have been an error in assessment, which I'm working
through now. If so, there will be a revert.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334970 - head

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: imp
> Date: Mon Jun 11 19:32:40 2018
> New Revision: 334970
> URL: https://svnweb.freebsd.org/changeset/base/334970
> 
> Log:
>   Document the dump issue in UPDATING so people understand when they
>   get a new diagnostic.
> 
> Modified:
>   head/UPDATING
> 
> Modified: head/UPDATING
> ==
> --- head/UPDATING Mon Jun 11 19:32:36 2018(r334969)
> +++ head/UPDATING Mon Jun 11 19:32:40 2018(r334970)
> @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
>   "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
>  
>  
> +20180611:
> + A bug in dump has been found where it can incorrectly dump filesystems
> + with more than 512k inodes and produce corrupted dump images. r334968
> + closes the door by not dumping filesystems with more than 512k inodes.
> + While older dumps may 'work' the image they produce may or may not be
> + readable depending on many factors.
> +

Does it make since to put a temporary warning in newfs to warn users
of the "may bot be able to dump this fs" issue?

Regards,
-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334975 - head/share/man/man4

[Ed Maste]

Author: emaste
Date: Mon Jun 11 19:48:15 2018
New Revision: 334975
URL: https://svnweb.freebsd.org/changeset/base/334975

Log:
  muge.4: correct BUGS statement
  
  The EVB-LAN7850 I have does function with the EEPROM disabled - the
  link / activity LEDs just do not function.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/share/man/man4/muge.4

Modified: head/share/man/man4/muge.4
==
--- head/share/man/man4/muge.4  Mon Jun 11 19:35:41 2018(r334974)
+++ head/share/man/man4/muge.4  Mon Jun 11 19:48:15 2018(r334975)
@@ -72,4 +72,4 @@ device driver first appeared in
 .Fx 12.0 .
 .Sh BUGS
 USB-Ethernet adapters that use the LAN7850 without a configuration EEPROM
-will not work.
+may not activate link or activity LEDs.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334974 - head/sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 19:35:41 2018
New Revision: 334974
URL: https://svnweb.freebsd.org/changeset/base/334974

Log:
  Don't initialize c_count. We don't need to.

Modified:
  head/sbin/dump/main.c

Modified: head/sbin/dump/main.c
==
--- head/sbin/dump/main.c   Mon Jun 11 19:34:47 2018(r334973)
+++ head/sbin/dump/main.c   Mon Jun 11 19:35:41 2018(r334974)
@@ -100,8 +100,8 @@ main(int argc, char *argv[])
struct fstab *dt;
char *map, *mntpt;
int ch, mode, mntflags;
-   int i, ret, anydirskipped, bflag = 0, Tflag = 0, honorlevel = 1;
-   int just_estimate = 0, c_count = 0;
+   int i, ret, anydirskipped, c_count, bflag = 0, Tflag = 0, honorlevel = 
1;
+   int just_estimate = 0;
ino_t maxino;
char *tmsg;
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334971 - head/sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 19:32:45 2018
New Revision: 334971
URL: https://svnweb.freebsd.org/changeset/base/334971

Log:
  Document the newly enforced 524288 inode restriction.

Modified:
  head/sbin/dump/dump.8

Modified: head/sbin/dump/dump.8
==
--- head/sbin/dump/dump.8   Mon Jun 11 19:32:40 2018(r334970)
+++ head/sbin/dump/dump.8   Mon Jun 11 19:32:45 2018(r334971)
@@ -29,7 +29,7 @@
 .\" @(#)dump.8 8.3 (Berkeley) 5/1/95
 .\" $FreeBSD$
 .\"
-.Dd October 3, 2016
+.Dd June 11, 2018
 .Dt DUMP 8
 .Os
 .Sh NAME
@@ -566,3 +566,8 @@ This will be fixed in a later version of
 .Fx .
 Presently, it works if you set it setuid (like it used to be), but this
 might constitute a security risk.
+.Pp
+It is not possible to safely dump filesystems that use more than
+524288 inodes.
+.Nm
+refuses to dump any filesystem that has more than 524288 inodes.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334973 - head/sys/dev/usb/net

[Ed Maste]

Author: emaste
Date: Mon Jun 11 19:34:47 2018
New Revision: 334973
URL: https://svnweb.freebsd.org/changeset/base/334973

Log:
  if_muge: retire lan78xx_eeprom_read
  
  lan78xx_eeprom_read just checked for EEPROM presence then called
  lan78xx_eeprom_read_raw if present, and had only one caller.  Introduce
  lan78xx_eeprom_present to check for EEPROM presence, and use it in the
  one place it is needed.
  
  This is used by r334964, which was accidentally committed out-of-order
  from my work tree.
  
  Reported by:  markj
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/dev/usb/net/if_muge.c

Modified: head/sys/dev/usb/net/if_muge.c
==
--- head/sys/dev/usb/net/if_muge.c  Mon Jun 11 19:32:49 2018
(r334972)
+++ head/sys/dev/usb/net/if_muge.c  Mon Jun 11 19:34:47 2018
(r334973)
@@ -445,32 +445,14 @@ done:
return (err);
 }
 
-/**
- * lan78xx_eeprom_read - Read EEPROM and confirm it is programmed
- * @sc: soft context
- * @off: the eeprom address offset
- * @buf: stores the bytes
- * @buflen: the number of bytes to read
- *
- * RETURNS:
- * 0 on success, or a USB_ERR_?? error code on failure.
- */
-static int
-lan78xx_eeprom_read(struct muge_softc *sc, uint16_t off, uint8_t *buf,
-uint16_t buflen)
+static bool
+lan78xx_eeprom_present(struct muge_softc *sc)
 {
-   uint8_t sig;
int ret;
+   uint8_t sig;
 
ret = lan78xx_eeprom_read_raw(sc, ETH_E2P_INDICATOR_OFFSET, , 1);
-   if ((ret == 0) && (sig == ETH_E2P_INDICATOR)) {
-   ret = lan78xx_eeprom_read_raw(sc, off, buf, buflen);
-   muge_dbg_printf(sc, "EEPROM present\n");
-   } else {
-   ret = -EINVAL;
-   muge_dbg_printf(sc, "EEPROM not present\n");
-   }
-   return (ret);
+   return (ret == 0 && sig == ETH_E2P_INDICATOR);
 }
 
 /**
@@ -1487,7 +1469,8 @@ muge_attach_post(struct usb_ether *ue)
 
/* If RX_ADDRx did not provide a valid MAC address, try EEPROM. */
if (!ETHER_IS_VALID(sc->sc_ue.ue_eaddr)) {
-   if ((lan78xx_eeprom_read(sc, ETH_E2P_MAC_OFFSET,
+   if ((lan78xx_eeprom_present(sc) &&
+   lan78xx_eeprom_read_raw(sc, ETH_E2P_MAC_OFFSET,
sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN) == 0) ||
(lan78xx_otp_read(sc, OTP_MAC_OFFSET,
sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN) == 0)) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334970 - head

[Warner Losh]

Author: imp
Date: Mon Jun 11 19:32:40 2018
New Revision: 334970
URL: https://svnweb.freebsd.org/changeset/base/334970

Log:
  Document the dump issue in UPDATING so people understand when they
  get a new diagnostic.

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Mon Jun 11 19:32:36 2018(r334969)
+++ head/UPDATING   Mon Jun 11 19:32:40 2018(r334970)
@@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW:
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
 
+20180611:
+   A bug in dump has been found where it can incorrectly dump filesystems
+   with more than 512k inodes and produce corrupted dump images. r334968
+   closes the door by not dumping filesystems with more than 512k inodes.
+   While older dumps may 'work' the image they produce may or may not be
+   readable depending on many factors.
+
 20180530:
The kernel / userland interface for devinfo changed, so you'll
need a new kernel and userland as a pair for it to work (rebuilding
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334972 - head/sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 19:32:49 2018
New Revision: 334972
URL: https://svnweb.freebsd.org/changeset/base/334972

Log:
  Minor style polishing.
  
  Declare c_count and initialize it with other ints.
  
  Reported by: mjg@

Modified:
  head/sbin/dump/main.c

Modified: head/sbin/dump/main.c
==
--- head/sbin/dump/main.c   Mon Jun 11 19:32:45 2018(r334971)
+++ head/sbin/dump/main.c   Mon Jun 11 19:32:49 2018(r334972)
@@ -101,9 +101,8 @@ main(int argc, char *argv[])
char *map, *mntpt;
int ch, mode, mntflags;
int i, ret, anydirskipped, bflag = 0, Tflag = 0, honorlevel = 1;
-   int just_estimate = 0;
+   int just_estimate = 0, c_count = 0;
ino_t maxino;
-   int c_count=0;
char *tmsg;
 
spcl.c_date = _time_to_time64(time(NULL));
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334969 - head/sbin/dump

[Warner Losh]

Author: imp
Date: Mon Jun 11 19:32:36 2018
New Revision: 334969
URL: https://svnweb.freebsd.org/changeset/base/334969

Log:
  Add asserts to prevent overflows of c_addr.
  
  Add some asserts that prevents the overflows of c_addr. This can't
  happen, absent bugs. However, certain large filesystems can cause
  problems. These have been prevented by r334968, but a solution
  is needed. These asserts will help assure that solution is correct.
  
  PR: 228807
  Reviewed by: db

Modified:
  head/sbin/dump/tape.c
  head/sbin/dump/traverse.c

Modified: head/sbin/dump/tape.c
==
--- head/sbin/dump/tape.c   Mon Jun 11 19:12:50 2018(r334968)
+++ head/sbin/dump/tape.c   Mon Jun 11 19:32:36 2018(r334969)
@@ -47,6 +47,7 @@ static const char rcsid[] =
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -279,6 +280,7 @@ flushtape(void)
 
blks = 0;
if (spcl.c_type != TS_END) {
+   assert(spcl.c_count <= TP_NINDIR);
for (i = 0; i < spcl.c_count; i++)
if (spcl.c_addr[i] != 0)
blks++;

Modified: head/sbin/dump/traverse.c
==
--- head/sbin/dump/traverse.c   Mon Jun 11 19:12:50 2018(r334968)
+++ head/sbin/dump/traverse.c   Mon Jun 11 19:32:36 2018(r334969)
@@ -46,6 +46,7 @@ static const char rcsid[] =
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -637,6 +638,7 @@ ufs1_blksout(ufs1_daddr_t *blkp, int frags, ino_t ino)
count = blks;
else
count = i + TP_NINDIR;
+   assert(count <= TP_NINDIR + i);
for (j = i; j < count; j++)
if (blkp[j / tbperdb] != 0)
spcl.c_addr[j - i] = 1;
@@ -689,6 +691,7 @@ ufs2_blksout(union dinode *dp, ufs2_daddr_t *blkp, int
count = blks;
else
count = i + TP_NINDIR;
+   assert(count <= TP_NINDIR + i);
for (j = i; j < count; j++)
if (blkp[j / tbperdb] != 0)
spcl.c_addr[j - i] = 1;
@@ -753,6 +756,7 @@ appendextdata(union dinode *dp)
 * data by the writeextdata() routine.
 */
tbperdb = sblock->fs_bsize >> tp_bshift;
+   assert(spcl.c_count + blks < TP_NINDIR);
for (i = 0; i < blks; i++)
if (>dp2.di_extb[i / tbperdb] != 0)
spcl.c_addr[spcl.c_count + i] = 1;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334968 - head/sbin/dump

[Diane Bruce]

Author: db (ports committer)
Date: Mon Jun 11 19:12:50 2018
New Revision: 334968
URL: https://svnweb.freebsd.org/changeset/base/334968

Log:
  Large file systems with inodes > 512K have been silently overflowing
  c_addr in spcl. So check before we start dumping otherwise we can
  end up with a corrupted dump.
  
  PR:   228807
  Submitted by: db
  Reviewed by:  imp
  Approved by:  imp

Modified:
  head/sbin/dump/main.c   (contents, props changed)

Modified: head/sbin/dump/main.c
==
--- head/sbin/dump/main.c   Mon Jun 11 19:03:49 2018(r334967)
+++ head/sbin/dump/main.c   Mon Jun 11 19:12:50 2018(r334968)
@@ -103,6 +103,7 @@ main(int argc, char *argv[])
int i, ret, anydirskipped, bflag = 0, Tflag = 0, honorlevel = 1;
int just_estimate = 0;
ino_t maxino;
+   int c_count=0;
char *tmsg;
 
spcl.c_date = _time_to_time64(time(NULL));
@@ -433,7 +434,6 @@ main(int argc, char *argv[])
msgtail("to %s\n", tape);
 
sync();
-   sblock = NULL;
if ((ret = sbget(diskfd, , -1)) != 0) {
switch (ret) {
case ENOENT:
@@ -453,6 +453,9 @@ main(int argc, char *argv[])
quit("TP_BSIZE (%d) is not a power of 2", TP_BSIZE);
maxino = sblock->fs_ipg * sblock->fs_ncg;
mapsize = roundup(howmany(maxino, CHAR_BIT), TP_BSIZE);
+   c_count = howmany(mapsize * sizeof(char), TP_BSIZE);
+   if (c_count > TP_NINDIR)
+   quit("fs is too large for dump!");
usedinomap = (char *)calloc((unsigned) mapsize, sizeof(char));
dumpdirmap = (char *)calloc((unsigned) mapsize, sizeof(char));
dumpinomap = (char *)calloc((unsigned) mapsize, sizeof(char));
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334966 - in head/sys/fs: nfs nfsclient

[Rick Macklem]

Author: rmacklem
Date: Mon Jun 11 19:00:07 2018
New Revision: 334966
URL: https://svnweb.freebsd.org/changeset/base/334966

Log:
  Add a couple of safety belt checks to the NFSv4.1 client related to sessions.
  
  There were a couple of cases in newnfs_request() that it assumed that it
  was an NFSv4.1 mount with a session. This should always be the case when
  a Sequence operation is in the reply or the server replies NFSERR_BADSESSION.
  However, if a server was broken and sent an erroneous reply, these safety
  belt checks should avoid trouble.
  The one check required a small tweak to nfsmnt_mdssession() so that it
  returns NULL when there is no session instead of the offset of the field
  in the structure (0x8 for i386).
  This patch should have no effect on normal operation of the client.
  Found by inspection during pNFS server development.
  
  MFC after:2 weeks

Modified:
  head/sys/fs/nfs/nfs_commonkrpc.c
  head/sys/fs/nfsclient/nfsmount.h

Modified: head/sys/fs/nfs/nfs_commonkrpc.c
==
--- head/sys/fs/nfs/nfs_commonkrpc.cMon Jun 11 18:57:40 2018
(r334965)
+++ head/sys/fs/nfs/nfs_commonkrpc.cMon Jun 11 19:00:07 2018
(r334966)
@@ -852,9 +852,9 @@ tryagain:
if ((nmp != NULL && i == NFSV4OP_SEQUENCE && j != 0) ||
(clp != NULL && i == NFSV4OP_CBSEQUENCE && j != 0))
NFSCL_DEBUG(1, "failed seq=%d\n", j);
-   if ((nmp != NULL && i == NFSV4OP_SEQUENCE && j == 0) ||
-   (clp != NULL && i == NFSV4OP_CBSEQUENCE && j == 0)
-   ) {
+   if (((nmp != NULL && i == NFSV4OP_SEQUENCE && j == 0) ||
+   (clp != NULL && i == NFSV4OP_CBSEQUENCE &&
+   j == 0)) && sep != NULL) {
if (i == NFSV4OP_SEQUENCE)
NFSM_DISSECT(tl, uint32_t *,
NFSX_V4SESSIONID +
@@ -896,7 +896,8 @@ tryagain:
}
if (nd->nd_repstat != 0) {
if (nd->nd_repstat == NFSERR_BADSESSION &&
-   nmp != NULL && dssep == NULL) {
+   nmp != NULL && dssep == NULL &&
+   (nd->nd_flag & ND_NFSV41) != 0) {
/*
 * If this is a client side MDS RPC, mark
 * the MDS session defunct and initiate

Modified: head/sys/fs/nfsclient/nfsmount.h
==
--- head/sys/fs/nfsclient/nfsmount.hMon Jun 11 18:57:40 2018
(r334965)
+++ head/sys/fs/nfsclient/nfsmount.hMon Jun 11 19:00:07 2018
(r334966)
@@ -129,8 +129,10 @@ nfsmnt_mdssession(struct nfsmount *nmp)
 {
struct nfsclsession *tsep;
 
+   tsep = NULL;
mtx_lock(>nm_mtx);
-   tsep = NFSMNT_MDSSESSION(nmp);
+   if (TAILQ_FIRST(>nm_sess) != NULL)
+   tsep = NFSMNT_MDSSESSION(nmp);
mtx_unlock(>nm_mtx);
return (tsep);
 }
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334965 - head/sys/kern

[Ed Maste]

Author: emaste
Date: Mon Jun 11 18:57:40 2018
New Revision: 334965
URL: https://svnweb.freebsd.org/changeset/base/334965

Log:
  makesyscalls: simplify capenabled pipeline
  
  Replace cat + 2x grep with one grep.
  
  Sponsored by: Turing Robotic Industries

Modified:
  head/sys/kern/makesyscalls.sh

Modified: head/sys/kern/makesyscalls.sh
==
--- head/sys/kern/makesyscalls.sh   Mon Jun 11 18:44:56 2018
(r334964)
+++ head/sys/kern/makesyscalls.sh   Mon Jun 11 18:57:40 2018
(r334965)
@@ -47,7 +47,7 @@ systracetmp="systrace.$$"
 systraceret="systraceret.$$"
 
 if [ -r capabilities.conf ]; then
-   capenabled=`cat capabilities.conf | grep -v "^#" | grep -v "^$"`
+   capenabled=`egrep -v '^#|^$' capabilities.conf`
capenabled=`echo $capenabled | sed 's/ /,/g'`
 else
capenabled=""
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334964 - in head: share/man/man4 sys/dev/usb/net

[Ed Maste]

Author: emaste
Date: Mon Jun 11 18:44:56 2018
New Revision: 334964
URL: https://svnweb.freebsd.org/changeset/base/334964

Log:
  if_muge: add LAN7850 support
  
  Differences between LAN7800 and LAN7850 from the driver's perspective:
  
  * The LAN7800 muxes EEPROM signals with LEDs, so LED mode needs to be
disabled when reading/writing EEPROM.  The EEPROM is not muxed on the
LAN7850.
  
  * The Linux driver enables automatic duplex and speed detection when
there is no EEPROM, for the LAN7800 only.  With this FreeBSD driver
LAN7850-based adapters without a configuration EEPROM fail to link
(with or without the automatic duplex and speed detection code), so
I have just followed the example of the Linux driver for now.
  
  Sponsored by: The FreeBSD Foundation
  Sponsored by: Microchip (hardware)

Modified:
  head/share/man/man4/muge.4
  head/sys/dev/usb/net/if_muge.c

Modified: head/share/man/man4/muge.4
==
--- head/share/man/man4/muge.4  Mon Jun 11 17:22:27 2018(r334963)
+++ head/share/man/man4/muge.4  Mon Jun 11 18:44:56 2018(r334964)
@@ -23,7 +23,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd May 17, 2018
+.Dd June 11, 2018
 .Dt MUGE 4
 .Os
 .Sh NAME
@@ -56,6 +56,8 @@ driver supports:
 .It
 Microchip LAN7800 USB 3.1 Gigabit Ethernet controller with PHY
 .It
+Microchip LAN7850 USB 2.0 Gigabit Ethernet controller with PHY
+.It
 Microchip LAN7515 USB 2 hub and Gigabit Ethernet controller with PHY
 .El
 .Sh SEE ALSO
@@ -68,3 +70,6 @@ The
 .Nm
 device driver first appeared in
 .Fx 12.0 .
+.Sh BUGS
+USB-Ethernet adapters that use the LAN7850 without a configuration EEPROM
+will not work.

Modified: head/sys/dev/usb/net/if_muge.c
==
--- head/sys/dev/usb/net/if_muge.c  Mon Jun 11 17:22:27 2018
(r334963)
+++ head/sys/dev/usb/net/if_muge.c  Mon Jun 11 18:44:56 2018
(r334964)
@@ -40,6 +40,9 @@ __FBSDID("$FreeBSD$");
  * USB 3.1 to 10/100/1000 Mbps Ethernet
  * LAN7800 http://www.microchip.com/wwwproducts/en/LAN7800
  *
+ * USB 2.0 to 10/100/1000 Mbps Ethernet
+ * LAN7850 http://www.microchip.com/wwwproducts/en/LAN7850
+ *
  * USB 2 to 10/100/1000 Mbps Ethernet with built-in USB hub
  * LAN7515 (no datasheet available, but probes and functions as LAN7800)
  *
@@ -386,11 +389,14 @@ lan78xx_eeprom_read_raw(struct muge_softc *sc, uint16_
if (!locked)
MUGE_LOCK(sc);
 
-   err = lan78xx_read_reg(sc, ETH_HW_CFG, );
-   saved = val;
+   if (sc->chipid == ETH_ID_REV_CHIP_ID_7800_) {
+   /* EEDO/EECLK muxed with LED0/LED1 on LAN7800. */
+   err = lan78xx_read_reg(sc, ETH_HW_CFG, );
+   saved = val;
 
-   val &= ~(ETH_HW_CFG_LEDO_EN_ | ETH_HW_CFG_LED1_EN_);
-   err = lan78xx_write_reg(sc, ETH_HW_CFG, val);
+   val &= ~(ETH_HW_CFG_LEDO_EN_ | ETH_HW_CFG_LED1_EN_);
+   err = lan78xx_write_reg(sc, ETH_HW_CFG, val);
+   }
 
err = lan78xx_wait_for_bits(sc, ETH_E2P_CMD, ETH_E2P_CMD_BUSY_);
if (err != 0) {
@@ -432,7 +438,10 @@ lan78xx_eeprom_read_raw(struct muge_softc *sc, uint16_
 done:
if (!locked)
MUGE_UNLOCK(sc);
-   lan78xx_write_reg(sc, ETH_HW_CFG, saved);
+   if (sc->chipid == ETH_ID_REV_CHIP_ID_7800_) {
+   /* Restore saved LED configuration. */
+   lan78xx_write_reg(sc, ETH_HW_CFG, saved);
+   }
return (err);
 }
 
@@ -982,7 +991,11 @@ lan78xx_chip_init(struct muge_softc *sc)
}
sc->chipid = (buf & ETH_ID_REV_CHIP_ID_MASK_) >> 16;
sc->chiprev = buf & ETH_ID_REV_CHIP_REV_MASK_;
-   if (sc->chipid != ETH_ID_REV_CHIP_ID_7800_) {
+   switch (sc->chipid) {
+   case ETH_ID_REV_CHIP_ID_7800_:
+   case ETH_ID_REV_CHIP_ID_7850_:
+   break;
+   default:
muge_warn_printf(sc, "Chip ID 0x%04x not yet supported\n",
sc->chipid);
goto init_failed;
@@ -1078,9 +1091,12 @@ lan78xx_chip_init(struct muge_softc *sc)
goto init_failed;
}
 
-   /* Enable automatic duplex detection and automatic speed detection. */
err = lan78xx_read_reg(sc, ETH_MAC_CR, );
-   buf |= ETH_MAC_CR_AUTO_DUPLEX_ | ETH_MAC_CR_AUTO_SPEED_;
+   if (sc->chipid == ETH_ID_REV_CHIP_ID_7800_ &&
+   !lan78xx_eeprom_present(sc)) {
+   /* Set automatic duplex and speed on LAN7800 without EEPROM. */
+   buf |= ETH_MAC_CR_AUTO_DUPLEX_ | ETH_MAC_CR_AUTO_SPEED_;
+   }
err = lan78xx_write_reg(sc, ETH_MAC_CR, buf);
 
/*
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334962 - head/sys/kern

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: mmacy
> Date: Mon Jun 11 17:10:19 2018
> New Revision: 334962
> URL: https://svnweb.freebsd.org/changeset/base/334962
> 
> Log:
>   limit change to fixing controlp handling pending review

It is best to write commit messages that stand alone,
as at a later time when reading the log for this file
the null relative reference here may take some one
a time to figure out.

limit change of rXX to fixing controlp handling...
or something more direct would be better in the future
as one does not usually have the mail thread handy
at the time of log reading.

Thanks,
Rod

> Modified:
>   head/sys/kern/uipc_socket.c
> 
> Modified: head/sys/kern/uipc_socket.c
> ==
> --- head/sys/kern/uipc_socket.c   Mon Jun 11 16:33:36 2018
> (r334961)
> +++ head/sys/kern/uipc_socket.c   Mon Jun 11 17:10:19 2018
> (r334962)
> @@ -2180,8 +2180,6 @@ soreceive_stream(struct socket *so, struct sockaddr **
>   flags = *flagsp &~ MSG_EOR;
>   else
>   flags = 0;
> - if (flags & (MSG_PEEK|MSG_WAITALL))
> - return (soreceive_generic(so, psa, uio, mp0, controlp, flagsp));
>   if (controlp != NULL)
>   *controlp = NULL;
>   if (flags & MSG_OOB)
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Warner Losh]

On Mon, Jun 11, 2018 at 11:54 AM, Devin Teske  wrote:

>
> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
>
>
>
> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:
>
>>
>>
>> > On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
>> >
>> > Author: kevans
>> > Date: Mon Jun 11 01:32:18 2018
>> > New Revision: 334939
>> > URL: https://svnweb.freebsd.org/changeset/base/334939
>> >
>> > Log:
>> >  lualoader: Allow brand-*.lua for adding new brands
>> >
>> >  dteske@, I believe, had originally pointed out that lualoader failed
>> to
>> >  allow logo-*.lua for new logos to be added. When correcting this
>> mistake, I
>> >  failed to do the same for brands.
>> >
>>
>> You’re doing an amazing job, Kyle.
>>
>> I continually see nothing but genuine effort toward feature parity which
>> makes me think one day I can pass the reigns.
>>
>> Yeah, I will always love Forth. It will always hold a special place in my
>> heart as that whacky language that simultaneously exudes great power while
>> also having the image ability to induce vomiting 冷 by the uninitiated.
>>
>> However, all that being said, I’d actually like to keep the Ficl boot
>> stuff as an option through to 14.0 and here is why ...
>>
>> Last year we were looking to update from ficl3 to ficl4. That may not
>> sound too exciting to most folks, but most folks don’t know the power that
>> ficl4 brings — like the capability to use full networking in the loader!
>> Can lua do that? How cool would it be to be able to communicate with the
>> network from the loader before the kernel is even loaded into memory? I had
>> a few hair-brained schemes left for Forth which might be exciting, lol
>>
>
> The current boot loader can already communicate via NFS or TFTP today.
> Adding http would be easy, https would be harder due to crypto being huge
> and space being small (though bear ssl might be small enough).
>
> The last articulated plan in arch@ was that LUA will be default in 12,
> and we plan to remove FORTH in 13. Last time I said it there in February,
> there was only email agreeing that I could find. This matches the in-person
> consensus poll I took at BSDcan as well. I think it would take a very
> extraordinary set circumstance and severe problems with LUA to change those
> plans.
>
>
> At BSD Can there was the boot working group where we discussed that an FCP
> would be required to decide this.
>

In the working group you weren't listening and being rather combative and
demanding that I do stuff, so I stopped talking. It should not be taken as
a sign of my consent, but more a sign of not wanting to get into a yelling
match in public on a topic I thought had been settled months ago.

I raised my desires that I would like to be able to flip a knob in 13 and
> reboot between Ficl and Lua, back and forth.
>
> Give people a choice until we have done a "shake-out" through an entire
> major version.
>
> An honest-to-goodness procession would be, in my mind:
>
> 13: Has both; both are installed. End-user can boot back and forth between
> the two
>
> Problems that arise in one or the other are non-critical because there is
> always an "out" by running the other.
>
> 14: Has both but both are not installed. The installer media doesn't even
> have it. You can't install the Forth booth stuff unless you twist a knob in
> buildworld, optionally going down the path of generating release media
> which has the Forth boot stuff.
>
> 15. It's removed from tree. You can't build Forth boot. Lua only. No
> looking back, no way to build it with Forth, to get Ficl you need to go to
> ports. A Ficl with FreeBSD boot words no longer exists and is no longer
> maintained. All of bhyve userboot also therefore uses Lua.
>

That's way too long. 12 will have Lua by default, but you can build FORTH
if you want has been the plan since February when I socialized this on arch@.
I originally pitched coexistence, but there was little appetite for that.

So I think a FCP discussed in arch@ is the right path forward.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Devin Teske]

> On Jun 11, 2018, at 7:07 AM, Warner Losh  wrote:
> 
> 
> 
> On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  > wrote:
> 
> 
> > On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
> > 
> > Author: kevans
> > Date: Mon Jun 11 01:32:18 2018
> > New Revision: 334939
> > URL: https://svnweb.freebsd.org/changeset/base/334939 
> > 
> > 
> > Log:
> >  lualoader: Allow brand-*.lua for adding new brands
> > 
> >  dteske@, I believe, had originally pointed out that lualoader failed to
> >  allow logo-*.lua for new logos to be added. When correcting this mistake, I
> >  failed to do the same for brands.
> > 
> 
> You’re doing an amazing job, Kyle.
> 
> I continually see nothing but genuine effort toward feature parity which 
> makes me think one day I can pass the reigns.
> 
> Yeah, I will always love Forth. It will always hold a special place in my 
> heart as that whacky language that simultaneously exudes great power while 
> also having the image ability to induce vomiting 冷 by the uninitiated.
> 
> However, all that being said, I’d actually like to keep the Ficl boot stuff 
> as an option through to 14.0 and here is why ...
> 
> Last year we were looking to update from ficl3 to ficl4. That may not sound 
> too exciting to most folks, but most folks don’t know the power that ficl4 
> brings — like the capability to use full networking in the loader! Can lua do 
> that? How cool would it be to be able to communicate with the network from 
> the loader before the kernel is even loaded into memory? I had a few 
> hair-brained schemes left for Forth which might be exciting, lol
> 
> The current boot loader can already communicate via NFS or TFTP today. Adding 
> http would be easy, https would be harder due to crypto being huge and space 
> being small (though bear ssl might be small enough).
> 
> The last articulated plan in arch@ was that LUA will be default in 12, and we 
> plan to remove FORTH in 13. Last time I said it there in February, there was 
> only email agreeing that I could find. This matches the in-person consensus 
> poll I took at BSDcan as well. I think it would take a very extraordinary set 
> circumstance and severe problems with LUA to change those plans.
> 

At BSD Can there was the boot working group where we discussed that an FCP 
would be required to decide this.

I raised my desires that I would like to be able to flip a knob in 13 and 
reboot between Ficl and Lua, back and forth.

Give people a choice until we have done a "shake-out" through an entire major 
version.

An honest-to-goodness procession would be, in my mind:

13: Has both; both are installed. End-user can boot back and forth between the 
two

Problems that arise in one or the other are non-critical because there is 
always an "out" by running the other.

14: Has both but both are not installed. The installer media doesn't even have 
it. You can't install the Forth booth stuff unless you twist a knob in 
buildworld, optionally going down the path of generating release media which 
has the Forth boot stuff.

15. It's removed from tree. You can't build Forth boot. Lua only. No looking 
back, no way to build it with Forth, to get Ficl you need to go to ports. A 
Ficl with FreeBSD boot words no longer exists and is no longer maintained. All 
of bhyve userboot also therefore uses Lua.
-- 
Devin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334963 - in stable: 10/release 11/release

[Glen Barber]

Author: gjb
Date: Mon Jun 11 17:22:27 2018
New Revision: 334963
URL: https://svnweb.freebsd.org/changeset/base/334963

Log:
  MFC r74:
   Use vMMDD in the timestamp suffix for Google Compute Engine
   snapshot images for consistency with other OSes.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  stable/10/release/Makefile.gce
Directory Properties:
  stable/10/   (props changed)

Changes in other areas also in this revision:
Modified:
  stable/11/release/Makefile.gce
Directory Properties:
  stable/11/   (props changed)

Modified: stable/10/release/Makefile.gce
==
--- stable/10/release/Makefile.gce  Mon Jun 11 17:10:19 2018
(r334962)
+++ stable/10/release/Makefile.gce  Mon Jun 11 17:22:27 2018
(r334963)
@@ -24,7 +24,8 @@ GCE_FAMILY=   ${TYPE:tl}-${REVISION:S,.,-,}
 .endif
 
 .if ${BRANCH} == "STABLE" || ${BRANCH} == "CURRENT" || ${BRANCH} == 
"PRERELEASE"
-SNAPSHOT_DATE!=date +-%Y-%m-%d
+_SNAPSHOT_DATE!=   date +%Y%m%d
+SNAPSHOT_DATE= -v${_SNAPSHOT_DATE}
 GCE_FAMILY_SUFX=   -snap
 .endif
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334963 - in stable: 10/release 11/release

[Glen Barber]

Author: gjb
Date: Mon Jun 11 17:22:27 2018
New Revision: 334963
URL: https://svnweb.freebsd.org/changeset/base/334963

Log:
  MFC r74:
   Use vMMDD in the timestamp suffix for Google Compute Engine
   snapshot images for consistency with other OSes.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  stable/11/release/Makefile.gce
Directory Properties:
  stable/11/   (props changed)

Changes in other areas also in this revision:
Modified:
  stable/10/release/Makefile.gce
Directory Properties:
  stable/10/   (props changed)

Modified: stable/11/release/Makefile.gce
==
--- stable/11/release/Makefile.gce  Mon Jun 11 17:10:19 2018
(r334962)
+++ stable/11/release/Makefile.gce  Mon Jun 11 17:22:27 2018
(r334963)
@@ -24,7 +24,8 @@ GCE_FAMILY=   ${TYPE:tl}-${REVISION:S,.,-,}
 .endif
 
 .if ${BRANCH} == "STABLE" || ${BRANCH} == "CURRENT" || ${BRANCH} == 
"PRERELEASE"
-SNAPSHOT_DATE!=date +-%Y-%m-%d
+_SNAPSHOT_DATE!=   date +%Y%m%d
+SNAPSHOT_DATE= -v${_SNAPSHOT_DATE}
 GCE_FAMILY_SUFX=   -snap
 .endif
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334962 - head/sys/kern

[Matt Macy]

Author: mmacy
Date: Mon Jun 11 17:10:19 2018
New Revision: 334962
URL: https://svnweb.freebsd.org/changeset/base/334962

Log:
  limit change to fixing controlp handling pending review

Modified:
  head/sys/kern/uipc_socket.c

Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Mon Jun 11 16:33:36 2018(r334961)
+++ head/sys/kern/uipc_socket.c Mon Jun 11 17:10:19 2018(r334962)
@@ -2180,8 +2180,6 @@ soreceive_stream(struct socket *so, struct sockaddr **
flags = *flagsp &~ MSG_EOR;
else
flags = 0;
-   if (flags & (MSG_PEEK|MSG_WAITALL))
-   return (soreceive_generic(so, psa, uio, mp0, controlp, flagsp));
if (controlp != NULL)
*controlp = NULL;
if (flags & MSG_OOB)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334960 - head/sys/kern

[Matthew Macy]

Fair. But it didn't actually work before. It's not clear anyone has
ever used it.

On Mon, Jun 11, 2018 at 9:54 AM, Mark Johnston  wrote:
> On Mon, Jun 11, 2018 at 04:31:43PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Mon Jun 11 16:31:42 2018
>> New Revision: 334960
>> URL: https://svnweb.freebsd.org/changeset/base/334960
>>
>> Log:
>>   soreceive_stream: correctly handle edge cases
>>
>>   - non NULL controlp is not an error, returning EINVAL
>> would cause X forwarding to fail
>>
>>   - MSG_PEEK and MSG_WAITALL are fairly exceptional, but we still
>> want to handle them - punt to soreceive_generic
>>
>> Modified:
>>   head/sys/kern/uipc_socket.c
>>
>> Modified: head/sys/kern/uipc_socket.c
>> ==
>> --- head/sys/kern/uipc_socket.c   Mon Jun 11 16:27:09 2018
>> (r334959)
>> +++ head/sys/kern/uipc_socket.c   Mon Jun 11 16:31:42 2018
>> (r334960)
>> @@ -2162,7 +2162,6 @@ release:
>>
>>  /*
>>   * Optimized version of soreceive() for stream (TCP) sockets.
>> - * XXXAO: (MSG_WAITALL | MSG_PEEK) isn't properly handled.
>>   */
>>  int
>>  soreceive_stream(struct socket *so, struct sockaddr **psa, struct uio *uio,
>> @@ -2177,12 +2176,14 @@ soreceive_stream(struct socket *so, struct sockaddr 
>> **
>>   return (EINVAL);
>>   if (psa != NULL)
>>   *psa = NULL;
>> - if (controlp != NULL)
>> - return (EINVAL);
>>   if (flagsp != NULL)
>>   flags = *flagsp &~ MSG_EOR;
>>   else
>>   flags = 0;
>> + if (flags & (MSG_PEEK|MSG_WAITALL))
>> + return (soreceive_generic(so, psa, uio, mp0, controlp, 
>> flagsp));
>> + if (controlp != NULL)
>> + *controlp = NULL;
>
> Now soreceive_stream() contains dead code to handle MSG_WAITALL, and a
> bunch of always-true checks for both flags.
>
> Changes to this code should be reviewed.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334960 - head/sys/kern

[Mark Johnston]

On Mon, Jun 11, 2018 at 04:31:43PM +, Matt Macy wrote:
> Author: mmacy
> Date: Mon Jun 11 16:31:42 2018
> New Revision: 334960
> URL: https://svnweb.freebsd.org/changeset/base/334960
> 
> Log:
>   soreceive_stream: correctly handle edge cases
>   
>   - non NULL controlp is not an error, returning EINVAL
> would cause X forwarding to fail
>   
>   - MSG_PEEK and MSG_WAITALL are fairly exceptional, but we still
> want to handle them - punt to soreceive_generic
> 
> Modified:
>   head/sys/kern/uipc_socket.c
> 
> Modified: head/sys/kern/uipc_socket.c
> ==
> --- head/sys/kern/uipc_socket.c   Mon Jun 11 16:27:09 2018
> (r334959)
> +++ head/sys/kern/uipc_socket.c   Mon Jun 11 16:31:42 2018
> (r334960)
> @@ -2162,7 +2162,6 @@ release:
>  
>  /*
>   * Optimized version of soreceive() for stream (TCP) sockets.
> - * XXXAO: (MSG_WAITALL | MSG_PEEK) isn't properly handled.
>   */
>  int
>  soreceive_stream(struct socket *so, struct sockaddr **psa, struct uio *uio,
> @@ -2177,12 +2176,14 @@ soreceive_stream(struct socket *so, struct sockaddr **
>   return (EINVAL);
>   if (psa != NULL)
>   *psa = NULL;
> - if (controlp != NULL)
> - return (EINVAL);
>   if (flagsp != NULL)
>   flags = *flagsp &~ MSG_EOR;
>   else
>   flags = 0;
> + if (flags & (MSG_PEEK|MSG_WAITALL))
> + return (soreceive_generic(so, psa, uio, mp0, controlp, flagsp));
> + if (controlp != NULL)
> + *controlp = NULL;

Now soreceive_stream() contains dead code to handle MSG_WAITALL, and a
bunch of always-true checks for both flags.

Changes to this code should be reviewed.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334961 - head/cddl/contrib/opensolaris/tools/ctf/cvt

[Mark Johnston]

Author: markj
Date: Mon Jun 11 16:33:36 2018
New Revision: 334961
URL: https://svnweb.freebsd.org/changeset/base/334961

Log:
  Process CUs with a language attribute of DW_LANG_Mips_Assembler.
  
  At the moment ctfconvert(1) does not do much with such CUs, but
  that may not be true in the future, and we run ctfconvert on several
  assembly files during the build.
  
  X-MFC with:   r334883

Modified:
  head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c

Modified: head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
==
--- head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c Mon Jun 11 16:31:42 
2018(r334960)
+++ head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c Mon Jun 11 16:33:36 
2018(r334961)
@@ -1982,10 +1982,11 @@ dw_read(tdata_t *td, Elf *elf, char *filename __unused
case DW_LANG_C_plus_plus_03:
case DW_LANG_C_plus_plus_11:
case DW_LANG_C_plus_plus_14:
+   case DW_LANG_Mips_Assembler:
break;
default:
terminate("file contains DWARF for unsupported "
-   "language %d", lang);
+   "language %#x", lang);
}
else
warning("die %llu: failed to get language attribute: %s\n",
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334960 - head/sys/kern

[Matt Macy]

Author: mmacy
Date: Mon Jun 11 16:31:42 2018
New Revision: 334960
URL: https://svnweb.freebsd.org/changeset/base/334960

Log:
  soreceive_stream: correctly handle edge cases
  
  - non NULL controlp is not an error, returning EINVAL
would cause X forwarding to fail
  
  - MSG_PEEK and MSG_WAITALL are fairly exceptional, but we still
want to handle them - punt to soreceive_generic

Modified:
  head/sys/kern/uipc_socket.c

Modified: head/sys/kern/uipc_socket.c
==
--- head/sys/kern/uipc_socket.c Mon Jun 11 16:27:09 2018(r334959)
+++ head/sys/kern/uipc_socket.c Mon Jun 11 16:31:42 2018(r334960)
@@ -2162,7 +2162,6 @@ release:
 
 /*
  * Optimized version of soreceive() for stream (TCP) sockets.
- * XXXAO: (MSG_WAITALL | MSG_PEEK) isn't properly handled.
  */
 int
 soreceive_stream(struct socket *so, struct sockaddr **psa, struct uio *uio,
@@ -2177,12 +2176,14 @@ soreceive_stream(struct socket *so, struct sockaddr **
return (EINVAL);
if (psa != NULL)
*psa = NULL;
-   if (controlp != NULL)
-   return (EINVAL);
if (flagsp != NULL)
flags = *flagsp &~ MSG_EOR;
else
flags = 0;
+   if (flags & (MSG_PEEK|MSG_WAITALL))
+   return (soreceive_generic(so, psa, uio, mp0, controlp, flagsp));
+   if (controlp != NULL)
+   *controlp = NULL;
if (flags & MSG_OOB)
return (soreceive_rcvoob(so, uio, flags));
if (mp0 != NULL)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Important Notification

[Information Update]

Dear Recipent ,

This email address has won Three Million Pounds on the o2 mobile 
sweepstakes.Please Contact Payment Cordinator Mat on email :  
mrw...@o2loto.co.uk for explanation and payment processing .

Yours Faithfully 

Debbie Spence 

Cordinator O2 Mobile Promotional Sweepstakes.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334959 - head/sys/dev/hwpmc

[Mark Johnston]

Author: markj
Date: Mon Jun 11 16:27:09 2018
New Revision: 334959
URL: https://svnweb.freebsd.org/changeset/base/334959

Log:
  Use the cached curthread reference in pmc_process_interrupt().
  
  Fix indentation while here.

Modified:
  head/sys/dev/hwpmc/hwpmc_mod.c

Modified: head/sys/dev/hwpmc/hwpmc_mod.c
==
--- head/sys/dev/hwpmc/hwpmc_mod.c  Mon Jun 11 16:26:33 2018
(r334958)
+++ head/sys/dev/hwpmc/hwpmc_mod.c  Mon Jun 11 16:27:09 2018
(r334959)
@@ -4748,9 +4748,9 @@ pmc_process_interrupt(int ring, struct pmc *pm, struct
 
td = curthread;
if ((pm->pm_flags & PMC_F_USERCALLCHAIN) &&
-(td->td_proc->p_flag & P_KPROC) == 0 &&
-   !TRAPF_USERMODE(tf)) {
-   atomic_add_int(>td_pmcpend, 1);
+   (td->td_proc->p_flag & P_KPROC) == 0 &&
+   !TRAPF_USERMODE(tf)) {
+   atomic_add_int(>td_pmcpend, 1);
return (pmc_add_sample(PMC_UR, pm, tf));
}
return (pmc_add_sample(ring, pm, tf));
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334958 - head/sys/compat/linuxkpi/common/include/linux

[Hans Petter Selasky]

Author: hselasky
Date: Mon Jun 11 16:26:33 2018
New Revision: 334958
URL: https://svnweb.freebsd.org/changeset/base/334958

Log:
  Implement the kstrtobool() and kstrtobool_from_user() functions
  in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  MFC after:1 week
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  head/sys/compat/linuxkpi/common/include/linux/kernel.h

Modified: head/sys/compat/linuxkpi/common/include/linux/kernel.h
==
--- head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 11 
16:09:54 2018(r334957)
+++ head/sys/compat/linuxkpi/common/include/linux/kernel.h  Mon Jun 11 
16:26:33 2018(r334958)
@@ -50,7 +50,9 @@
 #include 
 #include 
 #include 
+
 #include 
+#include 
 
 #include 
 
@@ -370,6 +372,46 @@ kstrtou32(const char *cp, unsigned int base, u32 *res)
if (temp != (u32)temp)
return (-ERANGE);
return (0);
+}
+
+static inline int
+kstrtobool(const char *s, bool *res)
+{
+   int len;
+
+   if (s == NULL || (len = strlen(s)) == 0 || res == NULL)
+   return (-EINVAL);
+
+   /* skip newline character, if any */
+   if (s[len - 1] == '\n')
+   len--;
+
+   if (len == 1 && strchr("yY1", s[0]) != NULL)
+   *res = true;
+   else if (len == 1 && strchr("nN0", s[0]) != NULL)
+   *res = false;
+   else if (strncasecmp("on", s, len) == 0)
+   *res = true;
+   else if (strncasecmp("off", s, len) == 0)
+   *res = false;
+   else
+   return (-EINVAL);
+
+   return (0);
+}
+
+static inline int
+kstrtobool_from_user(const char __user *s, size_t count, bool *res)
+{
+   char buf[8] = {};
+
+   if (count > (sizeof(buf) - 1))
+   count = (sizeof(buf) - 1);
+
+   if (copy_from_user(buf, s, count))
+   return (-EFAULT);
+
+   return (kstrtobool(buf, res));
 }
 
 #define min(x, y)  ((x) < (y) ? (x) : (y))
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334957 - in head: lib/libpmc usr.sbin/pmc

[Ryan Libby]

Author: rlibby
Date: Mon Jun 11 16:09:54 2018
New Revision: 334957
URL: https://svnweb.freebsd.org/changeset/base/334957

Log:
  pmc gcc fixups
  
  Fix the build of lib/libpmc and usr.sbin/pmc for gcc on amd64.
  
  Reviewed by:mmacy
  Sponsored by:   Dell EMC Isilon
  Differential Revision:  https://reviews.freebsd.org/D15723

Modified:
  head/lib/libpmc/Makefile
  head/usr.sbin/pmc/Makefile
  head/usr.sbin/pmc/cmd_pmc_filter.cc

Modified: head/lib/libpmc/Makefile
==
--- head/lib/libpmc/MakefileMon Jun 11 15:44:53 2018(r334956)
+++ head/lib/libpmc/MakefileMon Jun 11 16:09:54 2018(r334957)
@@ -7,6 +7,7 @@ SRCS=   libpmc.c pmclog.c libpmc_pmu_util.c libpmc_json.
 INCS=  pmc.h pmclog.h pmcformat.h
 
 CFLAGS+= -I${.CURDIR}
+CWARNFLAGS.gcc+= -Wno-shadow
 
 .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
 

Modified: head/usr.sbin/pmc/Makefile
==
--- head/usr.sbin/pmc/Makefile  Mon Jun 11 15:44:53 2018(r334956)
+++ head/usr.sbin/pmc/Makefile  Mon Jun 11 16:09:54 2018(r334957)
@@ -5,7 +5,8 @@
 .include 
 PROG_CXX=  pmc
 MAN=   
-CXXFLAGS+= -O0
+CXXFLAGS+= -O0 -std=c++14
+CWARNFLAGS.gcc+= -Wno-redundant-decls
 
 LIBADD=kvm pmc m ncursesw pmcstat elf
 

Modified: head/usr.sbin/pmc/cmd_pmc_filter.cc
==
--- head/usr.sbin/pmc/cmd_pmc_filter.cc Mon Jun 11 15:44:53 2018
(r334956)
+++ head/usr.sbin/pmc/cmd_pmc_filter.cc Mon Jun 11 16:09:54 2018
(r334957)
@@ -68,7 +68,6 @@ __FBSDID("$FreeBSD$");
 #include 
 #include "cmd_pmc.h"
 
-#include 
 #include 
 #include 
 
@@ -182,11 +181,11 @@ static void
 pmc_log_event(int fd, struct pmclog_ev *ev, bool json)
 {
int len;
-   void *buf;
+   const void *buf;
 
if (json) {
string ret = event_to_json(ev);
-   buf = (void*)ret.c_str();
+   buf = ret.c_str();
len = ret.size();
} else {
len = ev->pl_len;
@@ -233,7 +232,7 @@ pmc_filter_handler(uint32_t *lwplist, int lwpcount, ui
pmclog_close(ps);
if ((ps = static_cast < struct pmclog_parse_state 
*>(pmclog_open(infd)))== NULL)
errx(EX_OSERR, "ERROR: Cannot allocate pmclog parse state: 
%s\n", strerror(errno));
-   if ((pe = (typeof(pe)) malloc(sizeof(*pe) * pmccount)) == NULL)
+   if ((pe = (struct pmcid_ent *) malloc(sizeof(*pe) * pmccount)) == NULL)
errx(EX_OSERR, "ERROR: failed to allocate pmcid map");
i = 0;
while (pmclog_read(ps, ) == 0 && i < pmccount) {
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334955 - stable/11/lib/libc/sys

[Mark Johnston]

Author: markj
Date: Mon Jun 11 15:44:02 2018
New Revision: 334955
URL: https://svnweb.freebsd.org/changeset/base/334955

Log:
  MFC r334504:
  Remove an inaccuracy from mincore.2.

Modified:
  stable/11/lib/libc/sys/mincore.2
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/lib/libc/sys/mincore.2
==
--- stable/11/lib/libc/sys/mincore.2Mon Jun 11 15:43:28 2018
(r334954)
+++ stable/11/lib/libc/sys/mincore.2Mon Jun 11 15:44:02 2018
(r334955)
@@ -28,7 +28,7 @@
 .\"@(#)mincore.2   8.1 (Berkeley) 6/9/93
 .\" $FreeBSD$
 .\"
-.Dd January 17, 2003
+.Dd June 1, 2018
 .Dt MINCORE 2
 .Os
 .Sh NAME
@@ -73,7 +73,9 @@ Page has been referenced.
 .It Dv MINCORE_MODIFIED_OTHER
 Page has been modified.
 .It Dv MINCORE_SUPER
-Page is part of a "super" page. (only i386 & amd64)
+Page is part of a large
+.Pq Dq super
+page.
 .El
 .Pp
 The information returned by
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334956 - in stable/11/lib/libc: aarch64 riscv

[Mark Johnston]

Author: markj
Date: Mon Jun 11 15:44:53 2018
New Revision: 334956
URL: https://svnweb.freebsd.org/changeset/base/334956

Log:
  MFC r334505:
  Don't export _end on arm64 and riscv.

Modified:
  stable/11/lib/libc/aarch64/Symbol.map
  stable/11/lib/libc/riscv/Symbol.map
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/lib/libc/aarch64/Symbol.map
==
--- stable/11/lib/libc/aarch64/Symbol.map   Mon Jun 11 15:44:02 2018
(r334955)
+++ stable/11/lib/libc/aarch64/Symbol.map   Mon Jun 11 15:44:53 2018
(r334956)
@@ -33,6 +33,5 @@ FBSD_1.0 {
 
 FBSDprivate_1.0 {
_set_tp;
-   _end;
__makecontext;
 };

Modified: stable/11/lib/libc/riscv/Symbol.map
==
--- stable/11/lib/libc/riscv/Symbol.map Mon Jun 11 15:44:02 2018
(r334955)
+++ stable/11/lib/libc/riscv/Symbol.map Mon Jun 11 15:44:53 2018
(r334956)
@@ -33,6 +33,5 @@ FBSD_1.0 {
 
 FBSDprivate_1.0 {
_set_tp;
-   _end;
__makecontext;
 };
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334954 - stable/11/sys/arm64/include

[Mark Johnston]

Author: markj
Date: Mon Jun 11 15:43:28 2018
New Revision: 334954
URL: https://svnweb.freebsd.org/changeset/base/334954

Log:
  MFC r334101:
  Add GET_STACK_USAGE() for arm64.

Modified:
  stable/11/sys/arm64/include/proc.h
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/arm64/include/proc.h
==
--- stable/11/sys/arm64/include/proc.h  Mon Jun 11 15:42:29 2018
(r334953)
+++ stable/11/sys/arm64/include/proc.h  Mon Jun 11 15:43:28 2018
(r334954)
@@ -53,4 +53,18 @@ struct syscall_args {
int narg;
 };
 
+#ifdef _KERNEL
+
+#include 
+
+#defineGET_STACK_USAGE(total, used) do {   
\
+   struct thread *td = curthread;  \
+   (total) = td->td_kstack_pages * PAGE_SIZE - sizeof(struct pcb); \
+   (used) = (char *)td->td_kstack +\
+   td->td_kstack_pages * PAGE_SIZE -   \
+   (char *)\
+} while (0)
+
+#endif
+
 #endif /* !_MACHINE_PROC_H_ */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334953 - head/sys/compat/linuxkpi/common/include/asm

[Hans Petter Selasky]

Author: hselasky
Date: Mon Jun 11 15:42:29 2018
New Revision: 334953
URL: https://svnweb.freebsd.org/changeset/base/334953

Log:
  Implement the user_access_begin(), user_access_end(), usafe_get_user() and
  unsafe_put_user() function macros in the LinuxKPI.
  
  Submitted by: Johannes Lundberg 
  MFC after:1 week
  Sponsored by: Mellanox Technologies
  Sponsored by: Limelight Networks

Modified:
  head/sys/compat/linuxkpi/common/include/asm/uaccess.h

Modified: head/sys/compat/linuxkpi/common/include/asm/uaccess.h
==
--- head/sys/compat/linuxkpi/common/include/asm/uaccess.h   Mon Jun 11 
15:28:20 2018(r334952)
+++ head/sys/compat/linuxkpi/common/include/asm/uaccess.h   Mon Jun 11 
15:42:29 2018(r334953)
@@ -52,4 +52,17 @@ copy_from_user(void *to, const void *from, unsigned lo
 #define__copy_from_user(...)   copy_from_user(__VA_ARGS__)
 #define__copy_in_user(...) copy_from_user(__VA_ARGS__)
 
+#defineuser_access_begin() do { } while (0)
+#defineuser_access_end() do { } while (0)
+
+#defineunsafe_get_user(x, ptr, err) do { \
+   if (unlikely(__get_user(x, ptr))) \
+   goto err; \
+} while (0)
+
+#defineunsafe_put_user(x, ptr, err) do { \
+   if (unlikely(__put_user(x, ptr))) \
+   goto err; \
+} while (0)
+
 #endif /* _ASM_UACCESS_H_ */
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334952 - head/sys/amd64/amd64

[Konstantin Belousov]

Author: kib
Date: Mon Jun 11 15:28:20 2018
New Revision: 334952
URL: https://svnweb.freebsd.org/changeset/base/334952

Log:
  Fix braino in r334799.  Maxmem is in pages.
  
  Reported by:  ae, pho
  Tested by:pho
  Sponsored by: The FreeBSD Foundation
  MFC after:1 week

Modified:
  head/sys/amd64/amd64/mp_machdep.c

Modified: head/sys/amd64/amd64/mp_machdep.c
==
--- head/sys/amd64/amd64/mp_machdep.c   Mon Jun 11 15:18:31 2018
(r334951)
+++ head/sys/amd64/amd64/mp_machdep.c   Mon Jun 11 15:28:20 2018
(r334952)
@@ -122,7 +122,7 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *phys
 */
if (physmap[i] >= GiB(4) || physmap[i + 1] -
round_page(physmap[i]) < PAGE_SIZE * 3 ||
-   physmap[i + 1] > Maxmem)
+   atop(physmap[i + 1]) > Maxmem)
continue;
 
allocated = true;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334940 - head/usr.sbin/bhyve

[Marcelo Araujo]

2018-06-11 22:46 GMT+08:00 Pedro Giffuni :

>
>
> On 06/10/18 21:41, Marcelo Araujo wrote:
>
>
>
> 2018-06-11 10:25 GMT+08:00 Pedro Giffuni :
>
>>
>>
>> On 10/06/2018 21:09, Marcelo Araujo wrote:
>>
>>> Author: araujo
>>> Date: Mon Jun 11 02:09:20 2018
>>> New Revision: 334940
>>> URL: https://svnweb.freebsd.org/changeset/base/334940
>>>
>>> Log:
>>>- Add bhyve virtio-scsi storage backend support.
>>>   Example of configuration:
>>>ctl.conf:
>>>portal-group pg0 {
>>>discovery-auth-group no-authentication
>>>listen 0.0.0.0
>>>listen [::]
>>>}
>>>   target iqn.2012-06.com.example:target0 {
>>>auth-group no-authentication
>>>portal-group pg0
>>>port ioctl/5/3
>>>   lun 0 {
>>>path /z/test.img
>>>size 8G
>>>}
>>>lun 1 {
>>>path /z/test1.img
>>>size 8G
>>>}
>>>}
>>>   bhyve <...> -s 4,virtio-scsi,/dev/cam/ctl5.3,iid=3 
>>>   From inside guest:
>>>root@:~ # zpool status test
>>>  pool: test
>>> state: ONLINE
>>>  scan: none requested
>>>config:
>>>   NAMESTATE READ WRITE CKSUM
>>>testONLINE   0 0 0
>>>  da0   ONLINE   0 0 0
>>>  da1   ONLINE   0 0 0
>>>   dmesg:
>>>da0 at vtscsi0 bus 0 scbus0 target 0 lun 0
>>>da0:  Fixed Direct Access SPC-5 SCSI device
>>>da0: Serial Number MYSERIAL
>>>da0: 300.000MB/s transfers
>>>da0: Command Queueing enabled
>>>da0: 8192MB (16777216 512 byte sectors)
>>>da1 at vtscsi0 bus 0 scbus0 target 0 lun 1
>>>da1:  Fixed Direct Access SPC-5 SCSI device
>>>da1: Serial Number MYSERIAL0001
>>>da1: 300.000MB/s transfers
>>>da1: Command Queueing enabled
>>>da1: 8192MB (16777216 512 byte sectors)
>>>   Discussed with:   grehan
>>>Reviewed by: mav
>>>Obtained from:   TrueOS
>>>Relnotes:Yes
>>>Sponsored by:iXsystems Inc.
>>>Tested with: FreeBSD HEAD, Fedora 28 (Workstation) and
>>> Ubuntu 18.04.
>>>Differential Revision:  https://reviews.freebsd.org/D15276
>>>
>>> Added:
>>>head/usr.sbin/bhyve/iov.c   (contents, props changed)
>>>head/usr.sbin/bhyve/iov.h   (contents, props changed)
>>>head/usr.sbin/bhyve/pci_virtio_scsi.c   (contents, props changed)
>>> Modified:
>>>head/usr.sbin/bhyve/Makefile
>>>head/usr.sbin/bhyve/bhyve.8
>>>head/usr.sbin/bhyve/virtio.h
>>>
>>> ...
>>>
>>
>> Added: head/usr.sbin/bhyve/pci_virtio_scsi.c
>>> 
>>> ==
>>> --- /dev/null   00:00:00 1970   (empty, because file is newly added)
>>> +++ head/usr.sbin/bhyve/pci_virtio_scsi.c   Mon Jun 11 02:09:20
>>> 2018(r334940)
>>> @@ -0,0 +1,718 @@
>>> +/*-
>>> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
>>> + *
>>> + * Copyright (c) 2016 Jakub Klama 
>>> .
>>> + * Copyright (c) 2018 Marcelo Araujo 
>>> .
>>> + * All rights reserved.
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * modification, are permitted provided that the following conditions
>>> + * are met:
>>> + * 1. Redistributions of source code must retain the above copyright
>>> + *notice, this list of conditions and the following disclaimer
>>> + *in this position and unchanged.
>>> + * 2. Redistributions in binary form must reproduce the above copyright
>>> + *notice, this list of conditions and the following disclaimer in
>>> the
>>> + *documentation and/or other materials provided with the
>>> distribution.
>>> + *
>>> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS''
>>> AND
>>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>> PURPOSE
>>> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE
>>> LIABLE
>>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>> CONSEQUENTIAL
>>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
>>> GOODS
>>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
>>> STRICT
>>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
>>> ANY WAY
>>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
>>> OF
>>> + * SUCH DAMAGE.
>>> + */
>>> +
>>> +#include 
>>> +__FBSDID("$FreeBSD$");
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 

svn commit: r334951 - head/usr.sbin/bhyve

[Marcelo Araujo]

Author: araujo
Date: Mon Jun 11 15:18:31 2018
New Revision: 334951
URL: https://svnweb.freebsd.org/changeset/base/334951

Log:
  More style(9) fixes, space vs tab.

Modified:
  head/usr.sbin/bhyve/pci_virtio_block.c

Modified: head/usr.sbin/bhyve/pci_virtio_block.c
==
--- head/usr.sbin/bhyve/pci_virtio_block.c  Mon Jun 11 14:45:34 2018
(r334950)
+++ head/usr.sbin/bhyve/pci_virtio_block.c  Mon Jun 11 15:18:31 2018
(r334951)
@@ -111,7 +111,7 @@ struct virtio_blk_hdr {
 #defineVBH_OP_FLUSH_OUT5
 #defineVBH_OP_IDENT8   
 #defineVBH_FLAG_BARRIER0x8000  /* OR'ed into vbh_type 
*/
-   uint32_tvbh_type;
+   uint32_tvbh_type;
uint32_tvbh_ioprio;
uint64_tvbh_sector;
 } __packed;
@@ -125,8 +125,8 @@ static int pci_vtblk_debug;
 
 struct pci_vtblk_ioreq {
struct blockif_req  io_req;
-   struct pci_vtblk_softc *io_sc;
-   uint8_t*io_status;
+   struct pci_vtblk_softc  *io_sc;
+   uint8_t *io_status;
uint16_tio_idx;
 };
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334950 - head/usr.sbin/bhyve

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> Author: pfg
> Date: Mon Jun 11 14:45:34 2018
> New Revision: 334950
> URL: https://svnweb.freebsd.org/changeset/base/334950
> 
> Log:
>   style(9): Fix tabs after #define.
>   
>   No functional change intended.

Thank you.


> Modified:
>   head/usr.sbin/bhyve/pci_virtio_scsi.c
> 
> Modified: head/usr.sbin/bhyve/pci_virtio_scsi.c
> ==
> --- head/usr.sbin/bhyve/pci_virtio_scsi.c Mon Jun 11 14:27:19 2018
> (r334949)
> +++ head/usr.sbin/bhyve/pci_virtio_scsi.c Mon Jun 11 14:45:34 2018
> (r334950)
> @@ -77,17 +77,17 @@ __FBSDID("$FreeBSD$");
>  #define  VTSCSI_OUT_HEADER_LEN(_sc)  \
>   (sizeof(struct pci_vtscsi_req_cmd_wr) + _sc->vss_config.sense_size)
>  
> -#define VIRTIO_SCSI_MAX_CHANNEL 0
> -#define VIRTIO_SCSI_MAX_TARGET  0
> -#define VIRTIO_SCSI_MAX_LUN 16383
> +#define  VIRTIO_SCSI_MAX_CHANNEL 0
> +#define  VIRTIO_SCSI_MAX_TARGET  0
> +#define  VIRTIO_SCSI_MAX_LUN 16383
>  
>  #define  VIRTIO_SCSI_F_INOUT (1 << 0)
>  #define  VIRTIO_SCSI_F_HOTPLUG   (1 << 1)
>  #define  VIRTIO_SCSI_F_CHANGE(1 << 2)
>  
>  static int pci_vtscsi_debug = 0;
> -#define DPRINTF(params) if (pci_vtscsi_debug) printf params
> -#define WPRINTF(params) printf params
> +#define  DPRINTF(params) if (pci_vtscsi_debug) printf params
> +#define  WPRINTF(params) printf params
>  
>  struct pci_vtscsi_config {
>   uint32_t num_queues;
> @@ -108,7 +108,7 @@ struct pci_vtscsi_queue {
>   int   vsq_ctl_fd;
>   pthread_mutex_t   vsq_mtx;
>   pthread_mutex_t   vsq_qmtx;
> -pthread_cond_tvsq_cv;
> + pthread_cond_tvsq_cv;
>   STAILQ_HEAD(, pci_vtscsi_request) vsq_requests;
>   LIST_HEAD(, pci_vtscsi_worker)vsq_workers;
>  };
> @@ -117,7 +117,7 @@ struct pci_vtscsi_worker {
>   struct pci_vtscsi_queue * vsw_queue;
>   pthread_t vsw_thread;
>   bool  vsw_exiting;
> -LIST_ENTRY(pci_vtscsi_worker) vsw_link;
> + LIST_ENTRY(pci_vtscsi_worker) vsw_link;
>  };
>  
>  struct pci_vtscsi_request {
> @@ -144,20 +144,20 @@ struct pci_vtscsi_softc {
>   struct pci_vtscsi_config vss_config;
>  };
>  
> -#define VIRTIO_SCSI_T_TMF0
> -#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0
> -#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1
> -#define VIRTIO_SCSI_T_TMF_CLEAR_ACA  2
> -#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3
> -#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET4
> -#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5
> -#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6
> -#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7
> +#define  VIRTIO_SCSI_T_TMF   0
> +#define  VIRTIO_SCSI_T_TMF_ABORT_TASK0
> +#define  VIRTIO_SCSI_T_TMF_ABORT_TASK_SET1
> +#define  VIRTIO_SCSI_T_TMF_CLEAR_ACA 2
> +#define  VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET3
> +#define  VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET   4
> +#define  VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET5
> +#define  VIRTIO_SCSI_T_TMF_QUERY_TASK6
> +#define  VIRTIO_SCSI_T_TMF_QUERY_TASK_SET7
>  
>  /* command-specific response values */
> -#define VIRTIO_SCSI_S_FUNCTION_COMPLETE  0
> -#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10
> -#define VIRTIO_SCSI_S_FUNCTION_REJECTED  11
> +#define  VIRTIO_SCSI_S_FUNCTION_COMPLETE 0
> +#define  VIRTIO_SCSI_S_FUNCTION_SUCCEEDED10
> +#define  VIRTIO_SCSI_S_FUNCTION_REJECTED 11
>  
>  struct pci_vtscsi_ctrl_tmf {
>   uint32_t type;
> @@ -167,13 +167,13 @@ struct pci_vtscsi_ctrl_tmf {
>   uint8_t response;
>  } __attribute__((packed));
>  
> -#define VIRTIO_SCSI_T_AN_QUERY   1
> -#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
> -#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT 4
> -#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST   8
> -#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE   16
> -#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST 32
> -#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY64
> +#define  VIRTIO_SCSI_T_AN_QUERY  1
> +#define  VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
> +#define  VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT4
> +#define  VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST  8
> +#define  VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE  16
> +#define  VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST32
> +#define  VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY   64
>  
>  struct pci_vtscsi_ctrl_an {
>   uint32_t type;
> @@ -184,23 +184,23 @@ struct pci_vtscsi_ctrl_an {
>  } __attribute__((packed));
>  
>  /* command-specific response values */
> -#define VIRTIO_SCSI_S_OK 0
> -#define VIRTIO_SCSI_S_OVERRUN  

Re: svn commit: r334940 - head/usr.sbin/bhyve

[Pedro Giffuni]

On 06/10/18 21:41, Marcelo Araujo wrote:



2018-06-11 10:25 GMT+08:00 Pedro Giffuni >:




On 10/06/2018 21:09, Marcelo Araujo wrote:

Author: araujo
Date: Mon Jun 11 02:09:20 2018
New Revision: 334940
URL: https://svnweb.freebsd.org/changeset/base/334940


Log:
   - Add bhyve virtio-scsi storage backend support.
      Example of configuration:
   ctl.conf:
   portal-group pg0 {
           discovery-auth-group no-authentication
           listen 0.0.0.0
           listen [::]
   }
      target iqn.2012-06.com.example:target0 {
           auth-group no-authentication
           portal-group pg0
           port ioctl/5/3
              lun 0 {
                   path /z/test.img
                   size 8G
           }
           lun 1 {
                   path /z/test1.img
                   size 8G
           }
   }
      bhyve <...> -s 4,virtio-scsi,/dev/cam/ctl5.3,iid=3 
      From inside guest:
   root@:~ # zpool status test
     pool: test
    state: ONLINE
     scan: none requested
   config:
              NAME        STATE     READ WRITE CKSUM
           test        ONLINE       0     0     0
             da0       ONLINE       0     0     0
             da1       ONLINE       0     0     0
      dmesg:
   da0 at vtscsi0 bus 0 scbus0 target 0 lun 0
   da0:  Fixed Direct Access SPC-5 SCSI
device
   da0: Serial Number MYSERIAL
   da0: 300.000MB/s transfers
   da0: Command Queueing enabled
   da0: 8192MB (16777216 512 byte sectors)
   da1 at vtscsi0 bus 0 scbus0 target 0 lun 1
   da1:  Fixed Direct Access SPC-5 SCSI
device
   da1: Serial Number MYSERIAL0001
   da1: 300.000MB/s transfers
   da1: Command Queueing enabled
   da1: 8192MB (16777216 512 byte sectors)
      Discussed with:           grehan
   Reviewed by:         mav
   Obtained from:               TrueOS
   Relnotes:            Yes
   Sponsored by:                iXsystems Inc.
   Tested with:         FreeBSD HEAD, Fedora 28 (Workstation) and
                        Ubuntu 18.04.
   Differential Revision: https://reviews.freebsd.org/D15276


Added:
   head/usr.sbin/bhyve/iov.c   (contents, props changed)
   head/usr.sbin/bhyve/iov.h   (contents, props changed)
   head/usr.sbin/bhyve/pci_virtio_scsi.c  (contents, props
changed)
Modified:
   head/usr.sbin/bhyve/Makefile
   head/usr.sbin/bhyve/bhyve.8
   head/usr.sbin/bhyve/virtio.h

...


Added: head/usr.sbin/bhyve/pci_virtio_scsi.c

==
--- /dev/null   00:00:00 1970   (empty, because file is newly
added)
+++ head/usr.sbin/bhyve/pci_virtio_scsi.c  Mon Jun 11 02:09:20
2018        (r334940)
@@ -0,0 +1,718 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2016 Jakub Klama .
+ * Copyright (c) 2018 Marcelo Araujo .
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
without
+ * modification, are permitted provided that the following
conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above
copyright
+ *    notice, this list of conditions and the following
disclaimer
+ *    in this position and unchanged.
+ * 2. Redistributions in binary form must reproduce the above
copyright
+ *    notice, this list of conditions and the following
disclaimer in the
+ *    documentation and/or other materials provided with the
distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR
CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY 

svn commit: r334950 - head/usr.sbin/bhyve

[Pedro F. Giffuni]

Author: pfg
Date: Mon Jun 11 14:45:34 2018
New Revision: 334950
URL: https://svnweb.freebsd.org/changeset/base/334950

Log:
  style(9): Fix tabs after #define.
  
  No functional change intended.

Modified:
  head/usr.sbin/bhyve/pci_virtio_scsi.c

Modified: head/usr.sbin/bhyve/pci_virtio_scsi.c
==
--- head/usr.sbin/bhyve/pci_virtio_scsi.c   Mon Jun 11 14:27:19 2018
(r334949)
+++ head/usr.sbin/bhyve/pci_virtio_scsi.c   Mon Jun 11 14:45:34 2018
(r334950)
@@ -77,17 +77,17 @@ __FBSDID("$FreeBSD$");
 #defineVTSCSI_OUT_HEADER_LEN(_sc)  \
(sizeof(struct pci_vtscsi_req_cmd_wr) + _sc->vss_config.sense_size)
 
-#define VIRTIO_SCSI_MAX_CHANNEL 0
-#define VIRTIO_SCSI_MAX_TARGET  0
-#define VIRTIO_SCSI_MAX_LUN 16383
+#defineVIRTIO_SCSI_MAX_CHANNEL 0
+#defineVIRTIO_SCSI_MAX_TARGET  0
+#defineVIRTIO_SCSI_MAX_LUN 16383
 
 #defineVIRTIO_SCSI_F_INOUT (1 << 0)
 #defineVIRTIO_SCSI_F_HOTPLUG   (1 << 1)
 #defineVIRTIO_SCSI_F_CHANGE(1 << 2)
 
 static int pci_vtscsi_debug = 0;
-#define DPRINTF(params) if (pci_vtscsi_debug) printf params
-#define WPRINTF(params) printf params
+#defineDPRINTF(params) if (pci_vtscsi_debug) printf params
+#defineWPRINTF(params) printf params
 
 struct pci_vtscsi_config {
uint32_t num_queues;
@@ -108,7 +108,7 @@ struct pci_vtscsi_queue {
int   vsq_ctl_fd;
pthread_mutex_t   vsq_mtx;
pthread_mutex_t   vsq_qmtx;
-pthread_cond_tvsq_cv;
+   pthread_cond_tvsq_cv;
STAILQ_HEAD(, pci_vtscsi_request) vsq_requests;
LIST_HEAD(, pci_vtscsi_worker)vsq_workers;
 };
@@ -117,7 +117,7 @@ struct pci_vtscsi_worker {
struct pci_vtscsi_queue * vsw_queue;
pthread_t vsw_thread;
bool  vsw_exiting;
-LIST_ENTRY(pci_vtscsi_worker) vsw_link;
+   LIST_ENTRY(pci_vtscsi_worker) vsw_link;
 };
 
 struct pci_vtscsi_request {
@@ -144,20 +144,20 @@ struct pci_vtscsi_softc {
struct pci_vtscsi_config vss_config;
 };
 
-#define VIRTIO_SCSI_T_TMF  0
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK   0
-#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET   1
-#define VIRTIO_SCSI_T_TMF_CLEAR_ACA2
-#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET   3
-#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET  4
-#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET   5
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK   6
-#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET   7
+#defineVIRTIO_SCSI_T_TMF   0
+#defineVIRTIO_SCSI_T_TMF_ABORT_TASK0
+#defineVIRTIO_SCSI_T_TMF_ABORT_TASK_SET1
+#defineVIRTIO_SCSI_T_TMF_CLEAR_ACA 2
+#defineVIRTIO_SCSI_T_TMF_CLEAR_TASK_SET3
+#defineVIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET   4
+#defineVIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET5
+#defineVIRTIO_SCSI_T_TMF_QUERY_TASK6
+#defineVIRTIO_SCSI_T_TMF_QUERY_TASK_SET7
 
 /* command-specific response values */
-#define VIRTIO_SCSI_S_FUNCTION_COMPLETE0
-#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED   10
-#define VIRTIO_SCSI_S_FUNCTION_REJECTED11
+#defineVIRTIO_SCSI_S_FUNCTION_COMPLETE 0
+#defineVIRTIO_SCSI_S_FUNCTION_SUCCEEDED10
+#defineVIRTIO_SCSI_S_FUNCTION_REJECTED 11
 
 struct pci_vtscsi_ctrl_tmf {
uint32_t type;
@@ -167,13 +167,13 @@ struct pci_vtscsi_ctrl_tmf {
uint8_t response;
 } __attribute__((packed));
 
-#define VIRTIO_SCSI_T_AN_QUERY 1
-#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
-#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT   4
-#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST 8
-#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE 16
-#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST   32
-#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY  64
+#defineVIRTIO_SCSI_T_AN_QUERY  1
+#defineVIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2
+#defineVIRTIO_SCSI_EVT_ASYNC_POWER_MGMT4
+#defineVIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST  8
+#defineVIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE  16
+#defineVIRTIO_SCSI_EVT_ASYNC_MULTI_HOST32
+#defineVIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY   64
 
 struct pci_vtscsi_ctrl_an {
uint32_t type;
@@ -184,23 +184,23 @@ struct pci_vtscsi_ctrl_an {
 } __attribute__((packed));
 
 /* command-specific response values */
-#define VIRTIO_SCSI_S_OK   0
-#define VIRTIO_SCSI_S_OVERRUN  1
-#define VIRTIO_SCSI_S_ABORTED  2
-#define VIRTIO_SCSI_S_BAD_TARGET   3
-#define VIRTIO_SCSI_S_RESET4
-#define 

svn commit: r334949 - in head/sys/netinet: . tcp_stacks

[Jonathan T. Looney]

Author: jtl
Date: Mon Jun 11 14:27:19 2018
New Revision: 334949
URL: https://svnweb.freebsd.org/changeset/base/334949

Log:
  Change RACK dependency on TCPHPTS from a build-time dependency to a load-
  time dependency.
  
  At present, RACK requires the TCPHPTS option to run. However, because
  modules can be moved from machine to machine, this dependency is really
  best assessed at load time rather than at build time.
  
  Reviewed by:  rrs
  Sponsored by: Netflix
  Differential Revision:https://reviews.freebsd.org/D15756

Modified:
  head/sys/netinet/tcp_hpts.c
  head/sys/netinet/tcp_stacks/rack.c

Modified: head/sys/netinet/tcp_hpts.c
==
--- head/sys/netinet/tcp_hpts.c Mon Jun 11 10:08:22 2018(r334948)
+++ head/sys/netinet/tcp_hpts.c Mon Jun 11 14:27:19 2018(r334949)
@@ -1960,3 +1960,4 @@ tcp_init_hptsi(void *st)
 }
 
 SYSINIT(tcphptsi, SI_SUB_KTHREAD_IDLE, SI_ORDER_ANY, tcp_init_hptsi, NULL);
+MODULE_VERSION(tcphpts, 1);

Modified: head/sys/netinet/tcp_stacks/rack.c
==
--- head/sys/netinet/tcp_stacks/rack.c  Mon Jun 11 10:08:22 2018
(r334948)
+++ head/sys/netinet/tcp_stacks/rack.c  Mon Jun 11 14:27:19 2018
(r334949)
@@ -127,10 +127,6 @@ uma_zone_t rack_pcb_zone;
 struct sysctl_ctx_list rack_sysctl_ctx;
 struct sysctl_oid *rack_sysctl_root;
 
-#ifndef TCPHPTS
-fatal error missing option TCPHSTS in the build;
-#endif
-
 #define CUM_ACKED 1
 #define SACKED 2
 
@@ -9162,3 +9158,4 @@ static moduledata_t tcp_rack = {
 
 MODULE_VERSION(MODNAME, 1);
 DECLARE_MODULE(MODNAME, tcp_rack, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY);
+MODULE_DEPEND(MODNAME, tcphpts, 1, 1, 1);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Warner Losh]

On Mon, Jun 11, 2018 at 7:36 AM, Devin Teske  wrote:

>
>
> > On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
> >
> > Author: kevans
> > Date: Mon Jun 11 01:32:18 2018
> > New Revision: 334939
> > URL: https://svnweb.freebsd.org/changeset/base/334939
> >
> > Log:
> >  lualoader: Allow brand-*.lua for adding new brands
> >
> >  dteske@, I believe, had originally pointed out that lualoader failed to
> >  allow logo-*.lua for new logos to be added. When correcting this
> mistake, I
> >  failed to do the same for brands.
> >
>
> You’re doing an amazing job, Kyle.
>
> I continually see nothing but genuine effort toward feature parity which
> makes me think one day I can pass the reigns.
>
> Yeah, I will always love Forth. It will always hold a special place in my
> heart as that whacky language that simultaneously exudes great power while
> also having the image ability to induce vomiting 冷 by the uninitiated.
>
> However, all that being said, I’d actually like to keep the Ficl boot
> stuff as an option through to 14.0 and here is why ...
>
> Last year we were looking to update from ficl3 to ficl4. That may not
> sound too exciting to most folks, but most folks don’t know the power that
> ficl4 brings — like the capability to use full networking in the loader!
> Can lua do that? How cool would it be to be able to communicate with the
> network from the loader before the kernel is even loaded into memory? I had
> a few hair-brained schemes left for Forth which might be exciting, lol
>

The current boot loader can already communicate via NFS or TFTP today.
Adding http would be easy, https would be harder due to crypto being huge
and space being small (though bear ssl might be small enough).

The last articulated plan in arch@ was that LUA will be default in 12, and
we plan to remove FORTH in 13. Last time I said it there in February, there
was only email agreeing that I could find. This matches the in-person
consensus poll I took at BSDcan as well. I think it would take a very
extraordinary set circumstance and severe problems with LUA to change those
plans.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334939 - head/stand/lua

[Devin Teske]

> On Jun 10, 2018, at 6:32 PM, Kyle Evans  wrote:
> 
> Author: kevans
> Date: Mon Jun 11 01:32:18 2018
> New Revision: 334939
> URL: https://svnweb.freebsd.org/changeset/base/334939
> 
> Log:
>  lualoader: Allow brand-*.lua for adding new brands
> 
>  dteske@, I believe, had originally pointed out that lualoader failed to
>  allow logo-*.lua for new logos to be added. When correcting this mistake, I
>  failed to do the same for brands.
> 

You’re doing an amazing job, Kyle.

I continually see nothing but genuine effort toward feature parity which makes 
me think one day I can pass the reigns.

Yeah, I will always love Forth. It will always hold a special place in my heart 
as that whacky language that simultaneously exudes great power while also 
having the image ability to induce vomiting 冷 by the uninitiated.

However, all that being said, I’d actually like to keep the Ficl boot stuff as 
an option through to 14.0 and here is why ...

Last year we were looking to update from ficl3 to ficl4. That may not sound too 
exciting to most folks, but most folks don’t know the power that ficl4 brings — 
like the capability to use full networking in the loader! Can lua do that? How 
cool would it be to be able to communicate with the network from the loader 
before the kernel is even loaded into memory? I had a few hair-brained schemes 
left for Forth which might be exciting, lol

Anywho, keep up the great work. I love it and support you all the way.
— 
Devin
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334928 - head/lib/libc/stdlib

[Bruce Evans]

On Mon, 11 Jun 2018, Konstantin Belousov wrote:


On Mon, Jun 11, 2018 at 03:48:52PM +1000, Bruce Evans wrote:

Change TYPE to unsigned char[sizeof(old TYPE)] and use memcpy() to assign
the variables to fix this with small churn and without the pessimizations
in this commit.  This gives portable code back to K + memcpy(), and
is as efficient as the above when the above works.  On x86, even gcc-3.3
produces a load and store for memcpy(p, q, sizeof(register_t)) when p and
q are void *.

Change TYPE to unsigned char[n] and use a single memcpy() without a loop
to assign the variables to fix this with larger churn and with different
(smaller?) pessimizations than in this commit.  Setup and initialization
for this method is also simpler.  This uses the newfangled VLA feature,
and since n is variable for qsort(), builtin memcpy() with length n
doesn't work so well.

Either results in the unacceptable stack use.


'unsigned char[sizeof(old TYPE)]' uses no memory and thus no stack provided
memcpy() is optimized to register moves.

Similarly for 'unsigned char[n]', except this might be harder to optimize.
If it uses memory, then it wasn't optimized to register moves.  n must be
split up into blocks that fit in registers, just like the reverse of what
clang does now for combining byte-sized moves into larger blocks that fit
in registers.

Any source code may result in unacceptable stack usage if the compiler
optimizations aren't quite right.  The compiler should do something like
combining assignments of small objects to assignments of objects of size n;
then reblock to fit this in registers.  When this is not done right, parts
that don't fit in registers might be spilled to the stack, and when this
is done wrong the spill size might be nearly n or even larger.

In my example, clang and gcc-4.2.1 get the optimization with the VLA wrong
by putting the VLA on the stack and not doing any reblocking; clang
doesn't use any stack when it generates large code to reblock the byte
assignments (except when it uses AVX, signal handlers use more stack).


I can limit the char[es] and memcpy to some value of es, but I do not
see a point.  I will not object if somebody decides to do it.


The old code reblocked es into smaller objects and got the type punning
for this wrong.

I checked the speed of qsort().  It is O(n*log(n)) for both swaps and
comparisons.  Howver, I think most uses of it have small elements, since
for large data the elements should be keys or pointers to avoid swapping
the data.  The old version is almost optimal for swapping pointers.
clang's sophisticted reblocking of byte swaps is really bad for swapping
pointers: on amd64:

XX  movqplen(%rip), %r10
XX  testq   %r10, %r10
XX  je  .LBB2_18

plen is 8, so don't branch.

XX # %bb.1:# %for.body.lr.ph.i
XX  movqq(%rip), %rcx
XX  movqp(%rip), %rdx
XX  cmpq$32, %r10
XX  jb  .LBB2_12

plen is < 32, so branch.

XX  
XX .LBB2_12:   # %for.body.i8.preheader
XX  leaq-1(%r10), %rsi
XX  movq%r10, %rdi
XX  andq$3, %rdi
XX  je  .LBB2_15

plen is 0 mod 4, so branch.

XX ...
XX .LBB2_15:   # %for.body.i8.prol.loopexit
XX  cmpq$3, %rsi
XX  jb  .LBB2_18

plen - 1 is not below 3, so don't branch.

XX # %bb.16:   # %for.body.i8.preheader.new
XX  xorl%esi, %esi
XX  .p2align4, 0x90
XX .LBB2_17:   # %for.body.i8
XX # =>This Inner Loop Header: Depth=1
XX  movzbl  (%rdx,%rsi), %edi
XX  movzbl  (%rcx,%rsi), %eax
XX  movb%al, (%rdx,%rsi)
XX  movb%dil, (%rcx,%rsi)
XX  movzbl  1(%rdx,%rsi), %edi
XX  movzbl  1(%rcx,%rsi), %eax
XX  movb%al, 1(%rdx,%rsi)
XX  movb%dil, 1(%rcx,%rsi)
XX  movzbl  2(%rdx,%rsi), %edi
XX  movzbl  2(%rcx,%rsi), %eax
XX  movb%al, 2(%rdx,%rsi)
XX  movb%dil, 2(%rcx,%rsi)
XX  movzbl  3(%rdx,%rsi), %edi
XX  movzbl  3(%rcx,%rsi), %eax
XX  movb%al, 3(%rdx,%rsi)
XX  movb%dil, 3(%rcx,%rsi)
XX  addq$4, %rsi

End swapping copying a byte at a time after all.  Swap 4 bytes per iteration.

XX  cmpq%rsi, %r10
XX  jne .LBB2_17

Iterate twice for the 8 byte pointer.

All this instead of 2 loads and 2 stores that the old code might have
generated.

Since es is not always 8, the old code must generate more than 2 loads
and 2 stores -- it will have to reblock using similar branches to the
above.  It only uses 2 block sizes (sizeof(long) and 1), but the compiler
might pessimize this to the same as the above.

clang actually generates enormous^2 code with the current version and
enormous^3 code with the previous version.  For the current version,
1742 lines, with 192 lines for just movups instructions.  For the
previous version, it generates 4823 lines with 576 

svn commit: r334948 - head/sys/dev/bxe

[Dimitry Andric]

Author: dim
Date: Mon Jun 11 10:08:22 2018
New Revision: 334948
URL: https://svnweb.freebsd.org/changeset/base/334948

Log:
  Fix build of bxe with base gcc on i386
  
  Casting from rman_res_t to a pointer results in "cast to pointer from
  integer of different size" warnings with base gcc on i386, so print
  these without casting.  The kva field of struct bxe_bar is of type
  vm_offset_t, which can be 32 or 64 bit, so cast it to uintmax_t before
  printing.
  
  Reviewed by:  markj
  MFC after:3 days
  Differential Revision: https://reviews.freebsd.org/D15733

Modified:
  head/sys/dev/bxe/bxe.c

Modified: head/sys/dev/bxe/bxe.c
==
--- head/sys/dev/bxe/bxe.c  Mon Jun 11 08:42:03 2018(r334947)
+++ head/sys/dev/bxe/bxe.c  Mon Jun 11 10:08:22 2018(r334948)
@@ -12849,12 +12849,12 @@ bxe_allocate_bars(struct bxe_softc *sc)
 sc->bar[i].handle = rman_get_bushandle(sc->bar[i].resource);
 sc->bar[i].kva= (vm_offset_t)rman_get_virtual(sc->bar[i].resource);
 
-BLOGI(sc, "PCI BAR%d [%02x] memory allocated: %p-%p (%jd) -> %p\n",
+BLOGI(sc, "PCI BAR%d [%02x] memory allocated: %#jx-%#jx (%jd) -> 
%#jx\n",
   i, PCIR_BAR(i),
-  (void *)rman_get_start(sc->bar[i].resource),
-  (void *)rman_get_end(sc->bar[i].resource),
+  rman_get_start(sc->bar[i].resource),
+  rman_get_end(sc->bar[i].resource),
   rman_get_size(sc->bar[i].resource),
-  (void *)sc->bar[i].kva);
+  (uintmax_t)sc->bar[i].kva);
 }
 
 return (0);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r334928 - head/lib/libc/stdlib

[Konstantin Belousov]

On Mon, Jun 11, 2018 at 03:48:52PM +1000, Bruce Evans wrote:
> Change TYPE to unsigned char[sizeof(old TYPE)] and use memcpy() to assign
> the variables to fix this with small churn and without the pessimizations
> in this commit.  This gives portable code back to K + memcpy(), and
> is as efficient as the above when the above works.  On x86, even gcc-3.3
> produces a load and store for memcpy(p, q, sizeof(register_t)) when p and
> q are void *.
> 
> Change TYPE to unsigned char[n] and use a single memcpy() without a loop
> to assign the variables to fix this with larger churn and with different
> (smaller?) pessimizations than in this commit.  Setup and initialization
> for this method is also simpler.  This uses the newfangled VLA feature,
> and since n is variable for qsort(), builtin memcpy() with length n
> doesn't work so well.
Either results in the unacceptable stack use.

I can limit the char[es] and memcpy to some value of es, but I do not
see a point.  I will not object if somebody decides to do it.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334947 - head/sys/modules

[Dimitry Andric]

Author: dim
Date: Mon Jun 11 08:42:03 2018
New Revision: 334947
URL: https://svnweb.freebsd.org/changeset/base/334947

Log:
  Disable building aesni with base gcc
  
  Because base gcc does not support the required intrinsics, do not
  attempt to compile the aesni module with it.
  
  Noticed by:   Dan Allen 
  MFC after:3 days

Modified:
  head/sys/modules/Makefile

Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile   Mon Jun 11 08:11:35 2018(r334946)
+++ head/sys/modules/Makefile   Mon Jun 11 08:42:03 2018(r334947)
@@ -627,7 +627,9 @@ _aac=   aac
 _aacraid=  aacraid
 _acpi= acpi
 .if ${MK_CRYPT} != "no" || defined(ALL_MODULES)
+.if ${COMPILER_TYPE} != "gcc" || ${COMPILER_VERSION} > 40201
 _aesni=aesni
+.endif
 .endif
 _amd_ecc_inject=amd_ecc_inject
 _amdsbwd=  amdsbwd
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334946 - head/sys/dev/drm2/i915

[Dimitry Andric]

Author: dim
Date: Mon Jun 11 08:11:35 2018
New Revision: 334946
URL: https://svnweb.freebsd.org/changeset/base/334946

Log:
  Fix build of i915kms with base gcc
  
  Base gcc fails to compile sys/dev/drm2/i915/intel_display.c for i386,
  with the following -Werror warnings:
  
  cc1: warnings being treated as errors
  /usr/src/sys/dev/drm2/i915/intel_display.c:8884: warning:
  initialization from incompatible pointer type
  
  This is due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432, which
  incorrectly interprets the [] as a flexible array member.
  
  Because base gcc does not have a -W flag to suppress this particular
  warning, it requires a rather ugly cast.  To not influence any other
  compiler, put it in a #if/#endif block.
  
  Reviewed by:  kib
  MFC after:3 days
  Differential Revision: https://reviews.freebsd.org/D15744

Modified:
  head/sys/dev/drm2/i915/intel_display.c

Modified: head/sys/dev/drm2/i915/intel_display.c
==
--- head/sys/dev/drm2/i915/intel_display.c  Mon Jun 11 07:57:32 2018
(r334945)
+++ head/sys/dev/drm2/i915/intel_display.c  Mon Jun 11 08:11:35 2018
(r334946)
@@ -8872,7 +8872,15 @@ static int intel_dmi_reverse_brightness(const struct d
 
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
-   .dmi_id_list = &(const struct dmi_system_id[]) {
+   .dmi_id_list =
+#if !defined(__clang__) && !__GNUC_PREREQ__(4, 3)
+   /* gcc 4.2 needs an additional cast, to avoid a bogus
+* "initialization from incompatible pointer type" warning.
+* see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432
+*/
+   (const struct dmi_system_id (*)[])
+#endif
+   &(const struct dmi_system_id[]) {
{
.callback = intel_dmi_reverse_brightness,
.ident = "NCR Corporation",
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r334945 - head/sys/dev/ocs_fc

[Dimitry Andric]

Author: dim
Date: Mon Jun 11 07:57:32 2018
New Revision: 334945
URL: https://svnweb.freebsd.org/changeset/base/334945

Log:
  Fix build of ocs_fs with base gcc on i386
  
  Add a few intermediate casts to uintptr_t to suppress "cast to pointer
  from integer of different size" warnings from gcc.  Also remove a few
  incorrect casts.
  
  Reviewed by:  ram
  MFC after:3 days
  Differential Revision: https://reviews.freebsd.org/D15747

Modified:
  head/sys/dev/ocs_fc/ocs_ioctl.c
  head/sys/dev/ocs_fc/ocs_sport.c

Modified: head/sys/dev/ocs_fc/ocs_ioctl.c
==
--- head/sys/dev/ocs_fc/ocs_ioctl.c Mon Jun 11 05:35:57 2018
(r334944)
+++ head/sys/dev/ocs_fc/ocs_ioctl.c Mon Jun 11 07:57:32 2018
(r334945)
@@ -140,7 +140,7 @@ ocs_process_sli_config (ocs_t *ocs, ocs_ioctl_elxu_mbo

wrobj->host_buffer_descriptor[0].u.data.buffer_address_high = 
ocs_addr32_hi(dma->phys);
 
/* copy the data into the DMA buffer */
-   copyin((void *)mcmd->in_addr, dma->virt, 
mcmd->in_bytes);
+   copyin((void *)(uintptr_t)mcmd->in_addr, dma->virt, 
mcmd->in_bytes);
}
break;
case SLI4_OPC_COMMON_DELETE_OBJECT:
@@ -169,8 +169,8 @@ ocs_process_sli_config (ocs_t *ocs, ocs_ioctl_elxu_mbo
break;
default:
device_printf(ocs->dev, "%s: in=%p (%lld) out=%p 
(%lld)\n", __func__,
-   (void *)mcmd->in_addr, (unsigned long 
long)mcmd->in_bytes,
-   (void *)mcmd->out_addr, (unsigned long 
long)mcmd->out_bytes);
+   (void *)(uintptr_t)mcmd->in_addr, 
(unsigned long long)mcmd->in_bytes,
+   (void *)(uintptr_t)mcmd->out_addr, 
(unsigned long long)mcmd->out_bytes);
device_printf(ocs->dev, "%s: unknown (opc=%#x)\n", 
__func__,
req->opcode);
hexdump(mcmd, mcmd->size, NULL, 0);
@@ -184,7 +184,7 @@ ocs_process_sli_config (ocs_t *ocs, ocs_ioctl_elxu_mbo
return ENXIO;
}
 
-   copyin((void *)mcmd->in_addr, dma->virt, mcmd->in_bytes);
+   copyin((void *)(uintptr_t)mcmd->in_addr, dma->virt, 
mcmd->in_bytes);
 
sli_config->payload.mem.address_low  = ocs_addr32_lo(dma->phys);
sli_config->payload.mem.address_high = ocs_addr32_hi(dma->phys);
@@ -250,7 +250,7 @@ ocs_process_mbx_ioctl(ocs_t *ocs, ocs_ioctl_elxu_mbox_
 
if( SLI4_MBOX_COMMAND_SLI_CONFIG == ((sli4_mbox_command_header_t 
*)mcmd->payload)->command
&& mcmd->out_bytes && dma.virt) {
-   copyout(dma.virt, (void *)mcmd->out_addr, mcmd->out_bytes);
+   copyout(dma.virt, (void *)(uintptr_t)mcmd->out_addr, 
mcmd->out_bytes);
}
 
 no_support:

Modified: head/sys/dev/ocs_fc/ocs_sport.c
==
--- head/sys/dev/ocs_fc/ocs_sport.c Mon Jun 11 05:35:57 2018
(r334944)
+++ head/sys/dev/ocs_fc/ocs_sport.c Mon Jun 11 07:57:32 2018
(r334945)
@@ -781,7 +781,7 @@ __ocs_sport_attached(ocs_sm_ctx_t *ctx, ocs_sm_event_t
case OCS_EVT_ENTER: {
ocs_node_t *node;
 
-   ocs_log_debug(ocs, "[%s] SPORT attached WWPN %016llx WWNN 
%016llx \n", (unsigned long long)sport->display_name,
+   ocs_log_debug(ocs, "[%s] SPORT attached WWPN %016llx WWNN 
%016llx \n", sport->display_name,
sport->wwpn, sport->wwnn);
ocs_sport_lock(sport);
ocs_list_foreach(>node_list, node) {
@@ -805,7 +805,7 @@ __ocs_sport_attached(ocs_sm_ctx_t *ctx, ocs_sm_event_t
}
 
case OCS_EVT_EXIT:
-   ocs_log_debug(ocs, "[%s] SPORT deattached WWPN %016llx WWNN 
%016llx \n", (unsigned long long)sport->display_name,
+   ocs_log_debug(ocs, "[%s] SPORT deattached WWPN %016llx WWNN 
%016llx \n", sport->display_name,
sport->wwpn, sport->wwnn);
if (sport->enable_ini) {
ocs_scsi_ini_del_sport(sport);
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"