Re: 2D acceleration for Nvidia

[Theo Buehler]

On Sun, Dec 13, 2015 at 01:57:02AM +0100, Juan Francisco Cantero Hurtado wrote:
> On Sat, Dec 12, 2015 at 03:06:01AM +0100, Theo Buehler wrote:
> > On Fri, Dec 11, 2015 at 10:09:20AM +0100, Martin Pieuchot wrote:
> > > Without hardware acceleration my PowerBook G4 12'' with a NVIDIA
> > > GeForce FX Go 5200 is unusable.  Since XAA is no longer supported,
> > > here's a simple EXA backend for nv(4) based on the XAA sources and
> > > Nouveau.  It only implements Solid and Copy but that already makes
> > > a huge difference.
> > > 
> > > To test it you need to regenerate configure scripts for xf86-video-nv
> > > as described in /usr/xenocara/README.
> > > 
> > > I can provide a diff for upstream it the driver is still maintained.
> > > 
> > > I'd like to hear from people using NVidia cards.
> > > 
> > 
> > This is quite an impressive improvement, thanks a lot!  Full screen
> > video becomes watchable.  However, trying to move an xterm with the
> > mouse still isn't fun.
> 
> Try this xorg.conf:
> Section "Device"
>   Identifier "nvidia modesetting"
>   Driver "modesetting"
>   Option "HWCursor" "off"
> EndSection

Thanks for the suggestion, but putting this in a new file
/etc/X11/xorg.conf results in xdm refusing to start both on boot time
and with startx.  I don't know anything about xorg.conf, so it may well
be that I'm missing something obvious.  Here's the resulting Xorg.log

[56.984] (--) checkDevMem: using aperture driver /dev/xf86
[57.018] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode 
(version 3.32)
[57.031] 
X.Org X Server 1.17.4
Release Date: 2015-10-28
[57.031] X Protocol Version 11, Revision 0
[57.031] Build Operating System: OpenBSD 5.8 amd64 
[57.031] Current Operating System: OpenBSD miraculix.home 5.8 
GENERIC.MP#531 amd64
[57.032] Build Date: 11 December 2015  07:02:02AM
[57.032]  
[57.032] Current version of pixman: 0.32.8
[57.032]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[57.032] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[57.032] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 13 08:27:37 
2015
[57.033] (==) Using config file: "/etc/X11/xorg.conf"
[57.033] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[57.034] (==) No Layout section.  Using the first Screen section.
[57.034] (==) No screen section available. Using defaults.
[57.034] (**) |-->Screen "Default Screen Section" (0)
[57.034] (**) |   |-->Monitor ""
[57.034] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[57.034] (**) |   |-->Device "nvidia modesetting"
[57.034] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[57.034] (==) Disabling SIGIO handlers for input devices
[57.034] (==) Automatically adding devices
[57.034] (==) Automatically enabling devices
[57.034] (==) Not automatically adding GPU devices
[57.035] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[57.035] (==) ModulePath set to "/usr/X11R6/lib/modules"
[57.035] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[57.035] (II) Loader magic: 0x110e45931ce0
[57.035] (II) Module ABI versions:
[57.035]X.Org ANSI C Emulation: 0.4
[57.035]X.Org Video Driver: 19.0
[57.035]X.Org XInput driver : 21.0
[57.035]X.Org Server Extension : 9.0
[57.035] (--) PCI:*(0:1:0:0) 10de:0407:106b:00a3 rev 161, Mem @ 
0x9200/16777216, 0x8000/268435456, 0x9000/33554432, I/O @ 
0x7000/128, BIOS @ 0x/131072
[57.035] (II) LoadModule: "glx"
[57.037] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[57.049] (II) Module glx: vendor="X.Org Foundation"
[57.049]compiled for 1.17.4, module version = 1.0.0
[57.049]ABI class: X.Org Server Extension, version 9.0
[57.049] (==) AIGLX enabled
[57.049] (II) LoadModule: "modesetting"
[57.050] (II) Loading /usr/X11R6/lib/modules/drivers/modesetting_drv.so
[57.051] (II) Module modesetting: vendor="X.Org Foundation"
[57.051]compiled for 1.17.4, module version = 1.17.4
[57.051]Module class: X.Org Video Driver
[57.051]ABI class: X.Org Video Driver, version 19.0
[57.051] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[57.052] (EE) open /dev/drm0: Device not configured
[

[WIP] cwm: Keep client on screen while moving or resizing

[Vadim Vygonets]

Hi,

cwm makes a client active only when the mouse pointer enters the
window.  Thus, once a client is off screen and another becomes
active, it's lost forever.

The attached patch keeps clients overlapping with the screen's
view area, handling these cases better:

- Moving client without border off screen (left or up)
- Moving client with a mouse, starting with the pointer outside
  the window
- Resizing partially off-screen client using a keyboard
- Client moving or resizing itself (ConfigureRequest event)

The following cases are still not handled:

- Not all screen's view area being viewable, i.e., covered with
  regions (e.g., XRandR with monitors of different sizes)
- Screen's view area changing size (XRandR monitors rotating or
  disconnecting)
- Non-rectangular clients (XShape)

So here are my thoughts, and your feedback is welcome.

We certainly want to deal with regions and not screens, here and
in some other places where screen_area() is called.  We could use
a function that returns the best region for a client, along the
lines of:

- find the region containing the centre of the window;
- failing that, find the region that has the biggest overlapping
  area with the window;
- if none overlap with it (client fully off screen), find the
  region closest to the window.

We may then cache the region inside client_ctx, if it worth
dealing with cache invalidation.

Regarding region changes, I'd like to see them handled the
following way:

- When a region geometry changes (screen rotating), all clients
  therein should retain the same relative position within the new
  region that they occupied in the old one
- When a region disappears, all its clients should move to
  another region, preferrably to the same one, likewise retaining
  their relative position
- A relative position is something like (in pseudocode):
{ (client.x - region.x) / (region.w - client.w),
  (client.y - region.y) / (region.h - client.h) }
  (whatever's in the corner or in the middle stays there, etc.)
- It's possible to keep hidden clients in place after an XRandR
  event until they're shown, but probably not worth it

To achieve this, screen_update_geometry() may be changed like so:

- initialize new regions;
- for every old region, find the best matching new region, along
  the lines of the algorithm above;
- for every client:
  - find the best matching old region;
  - note relative position within it;
  - move the client to the appropriate relative position in the
new region found in the step above;
  - if the client is {h,v}maximized or fullscreen, resize;
  - ensure client is still visible (with the calculation above,
clients that are partially off-screen may become fully so
after moving);
- free old regions.

The simplest way to handle shaped clients I can think of is to
require them to be fully visible, i.e., that each of their four
corners (that they don't have) is inside a region.

Have I forgot any other cases that may move clients off screen?
My paranoia tells me to call client_keep_visible() from
client_cycle()...  Or maybe just call client_setactive() from
there.

What do you think?

Vadik.

-- 
An artist should be fit for the best society and keep out of it.
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.311
diff -u -r1.311 calmwm.h
--- calmwm.h	12 Nov 2015 21:28:03 -	1.311
+++ calmwm.h	12 Dec 2015 17:39:11 -
@@ -394,6 +394,7 @@
 void			 client_getsizehints(struct client_ctx *);
 void			 client_hide(struct client_ctx *);
 void 			 client_htile(struct client_ctx *);
+int			 client_keep_visible(struct client_ctx *);
 void			 client_lower(struct client_ctx *);
 void			 client_map(struct client_ctx *);
 void			 client_msg(struct client_ctx *, Atom, Time);
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 17:39:12 -
@@ -442,6 +442,29 @@
 	client_config(cc);
 }
 
+int
+client_keep_visible(struct client_ctx *cc)
+{
+	struct screen_ctx	*sc = cc->sc;
+	int			 changed = 0;
+
+	if (cc->geom.x + cc->geom.w + (int)(cc->bwidth * 2) <= 0) {
+		cc->geom.x = -(cc->geom.w + (cc->bwidth * 2) - 1);
+		changed = 1;
+	} else if (cc->geom.x >= sc->view.w) {
+		cc->geom.x = sc->view.w - 1;
+		changed = 1;
+	}
+	if (cc->geom.y + cc->geom.h + (int)(cc->bwidth * 2) <= 0) {
+		cc->geom.y = -(cc->geom.h + (cc->bwidth * 2) - 1);
+		changed = 1;
+	} else if (cc->geom.y >= sc->view.h) {
+		cc->geom.y = sc->view.h - 1;
+		changed = 1;
+	}
+	return(changed);
+}
+
 void
 client_move(struct client_ctx *cc)
 {
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.126
diff -u -r1.126 kbfunc.c
--- kbfunc.c	17 Nov 2015 14:32:38 -	

Re: radeon_ring_test_lockup / radeon_sa_bo_manager_fini *ERROR*

[Alexis de BRUYN]

On 12/11/15 16:22, Jonathan Gray wrote:

You likely want to remove the radeonsi binary built against
an older version of Mesa.

rm /usr/X11R6/lib/modules/dri/radeonsi_dri.so

Thank you Jonathan, problem solved.


Building a new one requires a newer llvm than ports has and building
Mesa itself with gcc 4.9.

This solved my other problem "Pictures are "blurred" in certain cases 
after snapshot upgrade (radeonrdrm related?)" [1]


[1]: https://www.marc.info/?l=openbsd-misc=144985262923092=2

--
Alexis de BRUYN

Re: Pull tmpfs fix from NetBSD

[Marc Espie]

On Fri, Dec 11, 2015 at 10:05:14AM -0700, Bob Beck wrote:
> 
> 
> 
> On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote:
> > Here's the PR:
> > 
> > https://gnats.netbsd.org/50381
> > 
> > And the commit:
> > 
> > https://marc.info/?l=netbsd-source-changes=144694603617544=2
> > 
> > We have very few local changes to tmpfs and we share the
> > KASSERT(de->td_node == NULL), so I think this applies to us.
> > 
> > Thoughts? ok?
> > 
> > 
> > Index: sys/tmpfs/tmpfs_subr.c
> > ===
> > RCS file: /cvsroot/src/sys/fs/tmpfs/tmpfs_subr.c,v
> > retrieving revision 1.96.4.1
> > retrieving revision 1.96.4.1.2.1
> > diff -u -p -r1.96.4.1 -r1.96.4.1.2.1
> > --- sys/fs/tmpfs/tmpfs_subr.c   22 Dec 2014 02:05:08 -  1.96.4.1
> > +++ sys/fs/tmpfs/tmpfs_subr.c   8 Nov 2015 01:27:10 -   
> > 1.96.4.1.2.1
> > @@ -451,6 +451,7 @@ tmpfs_alloc_dirent(tmpfs_mount_t *tmp, c
> > nde->td_namelen = len;
> > memcpy(nde->td_name, name, len);
> > nde->td_seq = TMPFS_DIRSEQ_NONE;
> > +   nde->td_node = NULL; /* for asserts */
> >  
> > *de = nde;
> > return 0;
> > 
> 
> Well, that diff won't apply directly, and in my opinion this is a safter way, 
> considering
> the tmpfs code, to accomplish the same thing.
> 
> Index: tmpfs/tmpfs_mem.c
> ===
> RCS file: /cvs/src/sys/tmpfs/tmpfs_mem.c,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 tmpfs_mem.c
> --- tmpfs/tmpfs_mem.c 14 Mar 2015 03:38:52 -  1.7
> +++ tmpfs/tmpfs_mem.c 11 Dec 2015 17:01:06 -
> @@ -151,7 +151,7 @@ tmpfs_dirent_get(struct tmpfs_mount *mp)
>   if (!tmpfs_mem_incr(mp, sizeof(struct tmpfs_dirent))) {
>   return NULL;
>   }
> - return pool_get(_dirent_pool, PR_WAITOK);
> + return pool_get(_dirent_pool, PR_ZERO|PR_WAITOK);
>  }
Looks good to me. Don't see any point in any comment or extra code.

11n: finish A-MPDU Rx path

[Stefan Sperling]

This patch completes net80211 support for receiving A-MPDUs.

This is a required feature of 11n. Technically, sending A-MPDUS
is required, too, but since we're not trying to get certified by
the Wifi Alliance we can postpone this until later. Devices we
interoperate with won't care if we don't send them.

A-MPDUs are aggregate frames containing several MPDUs (i.e. several
full 802.11 frames with MAC headers). Each subframe is separated by
a delimiter which contains the length and CRC of the subframe, and a
trailer for padding. If you'd like to see a visual illustration,
search the web yourself, or look at this one: 
http://m.eet.com/media/1110804/802fig6.gif

These frames are used to avoid overhead of separate ACKs for
individual 802.11 frames. From the point of view of 11a/b/g STAs
the medium is reserved by the AP for the entire period during
which an A-MPDU is sent by the AP or another 11n STA.

Multicast frames are never sent in an A-MPDU. Before A-MPDUs
can be sent a Block Ack agreement must be established between
2 peers. A Block Ack agreement is identified by an arbitrarily
chosen traffic identifier value (TID) and the peer's MAC address.
Once an agreement is set up, the hardware/firmware on each side
keeps track of successfully received and failed subframes of
an A-MPDU and signals success or failure of subframes to the
peer via a bitmap contained in a BlockAck response frame.
This BlockAck response is invisible to the driver and net80211 layers.

Subframes received successfully are passed up to the driver and
net80211 layer, where they appear like regular 802.11 frames.
Subframes are matched to an existing BlockAck agreement with the
peer (ieee80211_node) based on the TID in their MAC header.
Because subframes may be received out of sequence, the net80211 layer
has to buffer subframes which cannot yet be passed to the upper
layers of the network stack since their sequence number is too new.
The net80211 layer is aware of the current sequence number window
and slides it forward as needed after either passing subframes
up the stack or discarding the entire set of buffered frames in
case the window has moved forward too far.

Note that there is an injection attack against A-MPDUs which we can do
nothing about at the driver level: https://github.com/rpp0/aggr-inject
The problem is rooted in poorly written wireless device firmware code
responsible for splitting A-MPDU frames into subframes.
The attack is possible on unencrypted wifi only.
Once OpenBSD starts sending A-MPDUs we can prevent this attack being
performed through OpenBSD by not sending A-MPDUs on unencrypted networks.

Most of the implementation was written by damien@ years ago and
was already committed back then. This diff adds the missing pieces
and fixes a few bugs. The changes are:

 - In ieee80211_input(), do A-MPDU processing before duplicate
   detection based on sequence number. The previous order was
   wrong since subframes are passed into ieee80211_input() twice,
   once before going through the buffer for reordering and once
   after being sent back into ieee80211_input() from the buffer.

 - Don't forget to set ba->ba_ni in ieee80211_recv_addba_req()
   so we don't crash in ieee80211_rx_ba_timeout().

 - In ieee80211_recv_addba_req(), tweak the logic to deny BlockAck
   requests if the driver has no callback for doing so. This shouldn't
   happen in production but helps during development while adding 11n
   support to a driver.

 - Implement ieee80211_ba_del() which cleans up BlockAck state kept
   in the ieee80211_node structure. This is called when the node
   resets all of its state or when the node is freed.

 - Increase the minimum and maximum lifetime for BlockAck agrements.
   There seem to be no values given in the spec, and neither Linux
   nor FreeBSD seem to enforce any limits. The existing minimum is
   too short for BlockAck to be effective because the agreement may
   already be cancelled before the first A-MPDU arrives. I chose the
   new values arbitrarily. These values may be tuned in the future if
   necessary.

Tested against several APs.

OK?

Index: net80211/ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.142
diff -u -p -r1.142 ieee80211_input.c
--- net80211/ieee80211_input.c  15 Nov 2015 11:14:17 -  1.142
+++ net80211/ieee80211_input.c  12 Dec 2015 08:49:12 -
@@ -280,6 +280,43 @@ ieee80211_input(struct ifnet *ifp, struc
tid = 0;
}
 
+#ifndef IEEE80211_NO_HT
+   if (type == IEEE80211_FC0_TYPE_DATA && hasqos &&
+   !(rxi->rxi_flags & IEEE80211_RXI_AMPDU_DONE)) {
+   int ba_state = ni->ni_rx_ba[tid].ba_state;
+
+   /* 
+* If Block Ack was explicitly requested, check
+* if we have a BA agreement for this RA/TID.
+*/
+   if ((qos & IEEE80211_QOS_ACK_POLICY_MASK) ==
+  

Re: 11n: finish A-MPDU Rx path

[Martin Pieuchot]

On 12/12/15(Sat) 10:59, Stefan Sperling wrote:
> This patch completes net80211 support for receiving A-MPDUs.
> 
> This is a required feature of 11n. Technically, sending A-MPDUS
> is required, too, but since we're not trying to get certified by
> the Wifi Alliance we can postpone this until later. Devices we
> interoperate with won't care if we don't send them.
> 
> A-MPDUs are aggregate frames containing several MPDUs (i.e. several
> full 802.11 frames with MAC headers). Each subframe is separated by
> a delimiter which contains the length and CRC of the subframe, and a
> trailer for padding. If you'd like to see a visual illustration,
> search the web yourself, or look at this one: 
> http://m.eet.com/media/1110804/802fig6.gif
> 
> These frames are used to avoid overhead of separate ACKs for
> individual 802.11 frames. From the point of view of 11a/b/g STAs
> the medium is reserved by the AP for the entire period during
> which an A-MPDU is sent by the AP or another 11n STA.
> 
> Multicast frames are never sent in an A-MPDU. Before A-MPDUs
> can be sent a Block Ack agreement must be established between
> 2 peers. A Block Ack agreement is identified by an arbitrarily
> chosen traffic identifier value (TID) and the peer's MAC address.
> Once an agreement is set up, the hardware/firmware on each side
> keeps track of successfully received and failed subframes of
> an A-MPDU and signals success or failure of subframes to the
> peer via a bitmap contained in a BlockAck response frame.
> This BlockAck response is invisible to the driver and net80211 layers.
> 
> Subframes received successfully are passed up to the driver and
> net80211 layer, where they appear like regular 802.11 frames.
> Subframes are matched to an existing BlockAck agreement with the
> peer (ieee80211_node) based on the TID in their MAC header.
> Because subframes may be received out of sequence, the net80211 layer
> has to buffer subframes which cannot yet be passed to the upper
> layers of the network stack since their sequence number is too new.
> The net80211 layer is aware of the current sequence number window
> and slides it forward as needed after either passing subframes
> up the stack or discarding the entire set of buffered frames in
> case the window has moved forward too far.
> 
> Note that there is an injection attack against A-MPDUs which we can do
> nothing about at the driver level: https://github.com/rpp0/aggr-inject
> The problem is rooted in poorly written wireless device firmware code
> responsible for splitting A-MPDU frames into subframes.
> The attack is possible on unencrypted wifi only.
> Once OpenBSD starts sending A-MPDUs we can prevent this attack being
> performed through OpenBSD by not sending A-MPDUs on unencrypted networks.
> 
> Most of the implementation was written by damien@ years ago and
> was already committed back then. This diff adds the missing pieces
> and fixes a few bugs. The changes are:
> 
>  - In ieee80211_input(), do A-MPDU processing before duplicate
>detection based on sequence number. The previous order was
>wrong since subframes are passed into ieee80211_input() twice,
>once before going through the buffer for reordering and once
>after being sent back into ieee80211_input() from the buffer.
> 
>  - Don't forget to set ba->ba_ni in ieee80211_recv_addba_req()
>so we don't crash in ieee80211_rx_ba_timeout().
> 
>  - In ieee80211_recv_addba_req(), tweak the logic to deny BlockAck
>requests if the driver has no callback for doing so. This shouldn't
>happen in production but helps during development while adding 11n
>support to a driver.
> 
>  - Implement ieee80211_ba_del() which cleans up BlockAck state kept
>in the ieee80211_node structure. This is called when the node
>resets all of its state or when the node is freed.
> 
>  - Increase the minimum and maximum lifetime for BlockAck agrements.
>There seem to be no values given in the spec, and neither Linux
>nor FreeBSD seem to enforce any limits. The existing minimum is
>too short for BlockAck to be effective because the agreement may
>already be cancelled before the first A-MPDU arrives. I chose the
>new values arbitrarily. These values may be tuned in the future if
>necessary.
> 
> Tested against several APs.
> 
> OK?

ok mpi@

> Index: net80211/ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 ieee80211_input.c
> --- net80211/ieee80211_input.c15 Nov 2015 11:14:17 -  1.142
> +++ net80211/ieee80211_input.c12 Dec 2015 08:49:12 -
> @@ -280,6 +280,43 @@ ieee80211_input(struct ifnet *ifp, struc
>   tid = 0;
>   }
>  
> +#ifndef IEEE80211_NO_HT
> + if (type == IEEE80211_FC0_TYPE_DATA && hasqos &&
> + !(rxi->rxi_flags & IEEE80211_RXI_AMPDU_DONE)) {
> + int ba_state = 

Re: initial 802.11n implementation

[Stefan Sperling]

On Sat, Dec 12, 2015 at 11:56:47AM +0100, Martin Pieuchot wrote:
> On 12/12/15(Sat) 00:19, Stefan Sperling wrote:
> > Index: net80211/ieee80211_input.c
> > ===
> > RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> > retrieving revision 1.142
> > diff -u -p -r1.142 ieee80211_input.c
> > --- net80211/ieee80211_input.c  15 Nov 2015 11:14:17 -  1.142
> > +++ net80211/ieee80211_input.c  11 Dec 2015 22:43:24 -
> > @@ -1569,10 +1597,13 @@ ieee80211_recv_probe_resp(struct ieee802
> >  */
> > if (ni->ni_flags & IEEE80211_NODE_QOS) {
> > /* always prefer EDCA IE over Wi-Fi Alliance WMM IE */
> > -   if (edcaie != NULL)
> > -   ieee80211_parse_edca_params(ic, edcaie);
> > -   else if (wmmie != NULL)
> > -   ieee80211_parse_wmm_params(ic, wmmie);
> > +   if ((edcaie != NULL &&
> > +ieee80211_parse_edca_params(ic, edcaie) == 0) ||
> > +   (wmmie != NULL &&
> > +ieee80211_parse_wmm_params(ic, wmmie) == 0))
> > +   ni->ni_flags |= IEEE80211_NODE_QOS;
> > +   else
> > +   ni->ni_flags &= ~IEEE80211_NODE_QOS;
> 
> I like the code unification but I find a bit confusing that
> IEEE80211_NODE_QOS is checked/set twice.
> 
> What should a client do if QoS has been negotiated during
> association and then the kernel fails tp parse EDCA/WMMIE
> params?  Is it correct to unset IEEE80211_NODE_QOS here? 

This change is not about what happens during association,
but about what happens earlier.

My iwlwifi AP sends no EDCA but WME, and it does so only in
beacons and probe responses, but *not* during assocation
(i.e. not in assoc response frames).

These elements can exist in any management frame so we have to
check twice, once in the beacon/probe response RX code path, and
once in the assoc response RX code path. The latter check already
exists in CVS today and I'm not removing it. Perhaps damien@ got 
this wrong and these elements are never actually sent in assoc
responses, but who knows -- they are vendor-specific elements.

If we do not set the NODE_QOS flag for some reason, 11n won't work.
So if we fail to parse the elements even though they were provided,
11n won't work. I hope such elements are not compliant with Wifi
Alliance requirements but I cannot read their documents...

> You have my ok.

Does this apply to the split up versions I'm sending, too?
They're slightly different since I found some small bugs while
splitting up the diff. I intend to commit the smaller patches.

11n: HT negotiation fixes

[Stefan Sperling]

Some APs will not negotiate 11n (aka HT) if the vendor-specific WME
(Wireless Multimedia Extensions) info element is missing in probe
and association requests. WME info essentially tells the other end
that we're QoS capable, which is a requirement for 11n (e.g. A-MPDUs
are sent in QoS data frames).
The 802.11-2012 standard defines other ways of indicating QoS support
which we already use. WME is not part of this standard but I'm adding
it for interoperability. FreeBSD and Linux send a WME info element, too.
Since this is an ugly vendor-specific element I decided to use magic
numbers instead of IEEE80211_ defines. I have no document explaining
what these numbers really mean, and Linux and FreeBSD use different
terminology. I put the names FreeBSD uses in comments.

Also, fix bugs where the wrong flag was checked to determine whether
11n-related elements should be included in management frames.
If 11n mode is enabled (F_HTON flag) we can always include 11n related
elements in management frames we send out, regardless of whether the
other STAs or APs support 11n.
The NODE_HT flag is only set once HT has been negotiated with a peer,
i.e. after exchanging assoc request and response with the AP.
Checking this flag earlier, e.g. in ieee80211_get_assoc_resp(), is wrong.

Index: net80211/ieee80211_output.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_output.c,v
retrieving revision 1.101
diff -u -p -r1.101 ieee80211_output.c
--- net80211/ieee80211_output.c 24 Nov 2015 12:32:53 -  1.101
+++ net80211/ieee80211_output.c 12 Dec 2015 10:12:58 -
@@ -94,6 +94,7 @@ structmbuf *ieee80211_get_addba_resp(st
struct ieee80211_node *, u_int8_t, u_int8_t, u_int16_t);
 struct mbuf *ieee80211_get_delba(struct ieee80211com *,
struct ieee80211_node *, u_int8_t, u_int8_t, u_int16_t);
+uint8_t *ieee80211_add_wme_info(uint8_t *, struct ieee80211com *);
 #endif
 struct mbuf *ieee80211_get_sa_query(struct ieee80211com *,
struct ieee80211_node *, u_int8_t);
@@ -831,6 +832,26 @@ ieee80211_add_qos_capability(u_int8_t *f
return frm;
 }
 
+#ifndef IEEE80211_NO_HT
+/*
+ * Add a Wifi-Alliance WME (aka WMM) info element to a frame.
+ * WME is a requirement for Wifi-Alliance compliance and some
+ * 11n APs will not negotiate HT if this element is missing.
+ */
+uint8_t *
+ieee80211_add_wme_info(uint8_t *frm, struct ieee80211com *ic)
+{
+   *frm++ = IEEE80211_ELEMID_VENDOR;
+   *frm++ = 7;
+   memcpy(frm, MICROSOFT_OUI, 3); frm += 3;
+   *frm++ = 2; /* OUI type */
+   *frm++ = 0; /* OUI subtype */
+   *frm++ = 1; /* version */
+   *frm++ = 0; /* info */
+
+   return frm;
+}
+#endif
 /*
  * Add an RSN element to a frame (see 802.11-2012 8.4.2.27)
  */
@@ -1097,7 +1118,7 @@ ieee80211_get_probe_req(struct ieee80211
2 + min(rs->rs_nrates, IEEE80211_RATE_SIZE) +
((rs->rs_nrates > IEEE80211_RATE_SIZE) ?
2 + rs->rs_nrates - IEEE80211_RATE_SIZE : 0) +
-   ((ni->ni_flags & IEEE80211_NODE_HT) ? 28 : 0));
+   ((ic->ic_flags & IEEE80211_F_HTON) ? 28 + 9 : 0));
if (m == NULL)
return NULL;
 
@@ -1107,8 +1128,10 @@ ieee80211_get_probe_req(struct ieee80211
if (rs->rs_nrates > IEEE80211_RATE_SIZE)
frm = ieee80211_add_xrates(frm, rs);
 #ifndef IEEE80211_NO_HT
-   if (ni->ni_flags & IEEE80211_NODE_HT)
+   if (ic->ic_flags & IEEE80211_F_HTON) {
frm = ieee80211_add_htcaps(frm, ic);
+   frm = ieee80211_add_wme_info(frm, ic);
+   }
 #endif
 
m->m_pkthdr.len = m->m_len = frm - mtod(m, u_int8_t *);
@@ -1278,7 +1301,7 @@ ieee80211_get_assoc_req(struct ieee80211
(((ic->ic_flags & IEEE80211_F_RSNON) &&
  (ni->ni_rsnprotos & IEEE80211_PROTO_WPA)) ?
2 + IEEE80211_WPAIE_MAXLEN : 0) +
-   ((ni->ni_flags & IEEE80211_NODE_HT) ? 28 : 0));
+   ((ic->ic_flags & IEEE80211_F_HTON) ? 28 + 9 : 0));
if (m == NULL)
return NULL;
 
@@ -1310,8 +1333,10 @@ ieee80211_get_assoc_req(struct ieee80211
(ni->ni_rsnprotos & IEEE80211_PROTO_WPA))
frm = ieee80211_add_wpa(frm, ic, ni);
 #ifndef IEEE80211_NO_HT
-   if (ni->ni_flags & IEEE80211_NODE_HT)
+   if (ic->ic_flags & IEEE80211_F_HTON) {
frm = ieee80211_add_htcaps(frm, ic);
+   frm = ieee80211_add_wme_info(frm, ic);
+   }
 #endif
 
m->m_pkthdr.len = m->m_len = frm - mtod(m, u_int8_t *);
@@ -1347,7 +1372,7 @@ ieee80211_get_assoc_resp(struct ieee8021
2 + rs->rs_nrates - IEEE80211_RATE_SIZE : 0) +
((ni->ni_flags & IEEE80211_NODE_QOS) ? 2 + 18 : 0) +
((status == IEEE80211_STATUS_TRY_AGAIN_LATER) ? 2 + 7 : 0) +
-   ((ni->ni_flags & IEEE80211_NODE_HT) ? 28 + 24 : 0));
+   ((ic->ic_flags & IEEE80211_F_HTON) ? 28 + 24 : 0));
if (m == 

Re: 11n: HT negotiation fixes

[Martin Pieuchot]

On 12/12/15(Sat) 11:34, Stefan Sperling wrote:
> Some APs will not negotiate 11n (aka HT) if the vendor-specific WME
> (Wireless Multimedia Extensions) info element is missing in probe
> and association requests. WME info essentially tells the other end
> that we're QoS capable, which is a requirement for 11n (e.g. A-MPDUs
> are sent in QoS data frames).
> The 802.11-2012 standard defines other ways of indicating QoS support
> which we already use. WME is not part of this standard but I'm adding
> it for interoperability. FreeBSD and Linux send a WME info element, too.
> Since this is an ugly vendor-specific element I decided to use magic
> numbers instead of IEEE80211_ defines. I have no document explaining
> what these numbers really mean, and Linux and FreeBSD use different
> terminology. I put the names FreeBSD uses in comments.
> 
> Also, fix bugs where the wrong flag was checked to determine whether
> 11n-related elements should be included in management frames.
> If 11n mode is enabled (F_HTON flag) we can always include 11n related
> elements in management frames we send out, regardless of whether the
> other STAs or APs support 11n.
> The NODE_HT flag is only set once HT has been negotiated with a peer,
> i.e. after exchanging assoc request and response with the AP.
> Checking this flag earlier, e.g. in ieee80211_get_assoc_resp(), is wrong.

ok mpi@

> Index: net80211/ieee80211_output.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_output.c,v
> retrieving revision 1.101
> diff -u -p -r1.101 ieee80211_output.c
> --- net80211/ieee80211_output.c   24 Nov 2015 12:32:53 -  1.101
> +++ net80211/ieee80211_output.c   12 Dec 2015 10:12:58 -
> @@ -94,6 +94,7 @@ struct  mbuf *ieee80211_get_addba_resp(st
>   struct ieee80211_node *, u_int8_t, u_int8_t, u_int16_t);
>  struct   mbuf *ieee80211_get_delba(struct ieee80211com *,
>   struct ieee80211_node *, u_int8_t, u_int8_t, u_int16_t);
> +uint8_t *ieee80211_add_wme_info(uint8_t *, struct ieee80211com *);
>  #endif
>  struct   mbuf *ieee80211_get_sa_query(struct ieee80211com *,
>   struct ieee80211_node *, u_int8_t);
> @@ -831,6 +832,26 @@ ieee80211_add_qos_capability(u_int8_t *f
>   return frm;
>  }
>  
> +#ifndef IEEE80211_NO_HT
> +/*
> + * Add a Wifi-Alliance WME (aka WMM) info element to a frame.
> + * WME is a requirement for Wifi-Alliance compliance and some
> + * 11n APs will not negotiate HT if this element is missing.
> + */
> +uint8_t *
> +ieee80211_add_wme_info(uint8_t *frm, struct ieee80211com *ic)
> +{
> + *frm++ = IEEE80211_ELEMID_VENDOR;
> + *frm++ = 7;
> + memcpy(frm, MICROSOFT_OUI, 3); frm += 3;
> + *frm++ = 2; /* OUI type */
> + *frm++ = 0; /* OUI subtype */
> + *frm++ = 1; /* version */
> + *frm++ = 0; /* info */
> +
> + return frm;
> +}
> +#endif
>  /*
>   * Add an RSN element to a frame (see 802.11-2012 8.4.2.27)
>   */
> @@ -1097,7 +1118,7 @@ ieee80211_get_probe_req(struct ieee80211
>   2 + min(rs->rs_nrates, IEEE80211_RATE_SIZE) +
>   ((rs->rs_nrates > IEEE80211_RATE_SIZE) ?
>   2 + rs->rs_nrates - IEEE80211_RATE_SIZE : 0) +
> - ((ni->ni_flags & IEEE80211_NODE_HT) ? 28 : 0));
> + ((ic->ic_flags & IEEE80211_F_HTON) ? 28 + 9 : 0));
>   if (m == NULL)
>   return NULL;
>  
> @@ -1107,8 +1128,10 @@ ieee80211_get_probe_req(struct ieee80211
>   if (rs->rs_nrates > IEEE80211_RATE_SIZE)
>   frm = ieee80211_add_xrates(frm, rs);
>  #ifndef IEEE80211_NO_HT
> - if (ni->ni_flags & IEEE80211_NODE_HT)
> + if (ic->ic_flags & IEEE80211_F_HTON) {
>   frm = ieee80211_add_htcaps(frm, ic);
> + frm = ieee80211_add_wme_info(frm, ic);
> + }
>  #endif
>  
>   m->m_pkthdr.len = m->m_len = frm - mtod(m, u_int8_t *);
> @@ -1278,7 +1301,7 @@ ieee80211_get_assoc_req(struct ieee80211
>   (((ic->ic_flags & IEEE80211_F_RSNON) &&
> (ni->ni_rsnprotos & IEEE80211_PROTO_WPA)) ?
>   2 + IEEE80211_WPAIE_MAXLEN : 0) +
> - ((ni->ni_flags & IEEE80211_NODE_HT) ? 28 : 0));
> + ((ic->ic_flags & IEEE80211_F_HTON) ? 28 + 9 : 0));
>   if (m == NULL)
>   return NULL;
>  
> @@ -1310,8 +1333,10 @@ ieee80211_get_assoc_req(struct ieee80211
>   (ni->ni_rsnprotos & IEEE80211_PROTO_WPA))
>   frm = ieee80211_add_wpa(frm, ic, ni);
>  #ifndef IEEE80211_NO_HT
> - if (ni->ni_flags & IEEE80211_NODE_HT)
> + if (ic->ic_flags & IEEE80211_F_HTON) {
>   frm = ieee80211_add_htcaps(frm, ic);
> + frm = ieee80211_add_wme_info(frm, ic);
> + }
>  #endif
>  
>   m->m_pkthdr.len = m->m_len = frm - mtod(m, u_int8_t *);
> @@ -1347,7 +1372,7 @@ ieee80211_get_assoc_resp(struct ieee8021
>   2 + rs->rs_nrates - IEEE80211_RATE_SIZE : 0) +
>   ((ni->ni_flags & IEEE80211_NODE_QOS) ? 2 + 18 : 0) +
>   

Re: initial 802.11n implementation

[Martin Pieuchot]

On 12/12/15(Sat) 00:19, Stefan Sperling wrote:
> On Sat, Dec 12, 2015 at 12:09:17AM +0100, Stefan Sperling wrote:
> > Here's an updated diff, which applies to -current, for testing.
> > I'll spend some time tomorrow splitting this up into smaller
> > chunks for review with explanations of the changes.
> > 
> > No known problems exist with this diff.
> > Please test anywhere, even without iwm(4). Thanks.
> > 
> 
> For some reason, a rouge pci/if_iwm.c file sneaked into
> the previous diff. Sorry about that.  

> Index: net80211/ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 ieee80211_input.c
> --- net80211/ieee80211_input.c15 Nov 2015 11:14:17 -  1.142
> +++ net80211/ieee80211_input.c11 Dec 2015 22:43:24 -
> @@ -1569,10 +1597,13 @@ ieee80211_recv_probe_resp(struct ieee802
>*/
>   if (ni->ni_flags & IEEE80211_NODE_QOS) {
>   /* always prefer EDCA IE over Wi-Fi Alliance WMM IE */
> - if (edcaie != NULL)
> - ieee80211_parse_edca_params(ic, edcaie);
> - else if (wmmie != NULL)
> - ieee80211_parse_wmm_params(ic, wmmie);
> + if ((edcaie != NULL &&
> +  ieee80211_parse_edca_params(ic, edcaie) == 0) ||
> + (wmmie != NULL &&
> +  ieee80211_parse_wmm_params(ic, wmmie) == 0))
> + ni->ni_flags |= IEEE80211_NODE_QOS;
> + else
> + ni->ni_flags &= ~IEEE80211_NODE_QOS;

I like the code unification but I find a bit confusing that
IEEE80211_NODE_QOS is checked/set twice.

What should a client do if QoS has been negotiated during
association and then the kernel fails tp parse EDCA/WMMIE
params?  Is it correct to unset IEEE80211_NODE_QOS here? 

But I don't think this should prevent you from committing this.
You have my ok.

11n: Finish A-MSDU receive

[Stefan Sperling]

A-MSDU frames are aggregates which contain MSDUs (ethernet frames) as
subframes, rather than MPDUs (802.11 frames) as A-MPDUs do.
Each subframe has a header containing sender and target MAC address
and the subframe's length. For a visual illustration, see
http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2014_2/remi/img/A-MSDU.png

The 802.11 standard requires 11n STAs to receive and send A-MSDUs.
As with A-MPDUs, we only implement receive for now.

Since the subframes are ethernet frames they go directly to the interface
input queue via ieee80211_deliver_data(), rather than to ieee80211_input().

damien@ added code for A-MSDU Rx years ago and it works mostly out of
the box. This diff adds an upper bounds check on the subframe length,
and a clean exit at the bottom of the loop for fully processed A-MSDUs
without which we'd normally terminate the loop via the error handling
path of the m_pullup() call at the top of the loop.

Tested against several APs. Only two of my APs send A-MSDUs (fritzbox
and Linux iwlwifi). With the Linux iwlwifi AP I'm seeing A-MSDU decryption
failures which I believe is caused by an intel firmware bug since the frame
sent by the AP has the wrong kind of encryption header (not CCMP).
The fritzbox AP uses a CCMP header as mandated by the standard so no
problem there.

Note that A-MPDUs may contain A-MSDUs in subframes. The iwlwifi AP
sends frames like this (unencrypted, though ;) so I could confirm
that this works as expected.

Index: net80211/ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.143
diff -u -p -r1.143 ieee80211_input.c
--- net80211/ieee80211_input.c  12 Dec 2015 11:25:46 -  1.143
+++ net80211/ieee80211_input.c  12 Dec 2015 13:04:29 -
@@ -1061,6 +1061,13 @@ ieee80211_amsdu_decap(struct ieee80211co
len -= LLC_SNAPFRAMELEN;
}
len += ETHER_HDR_LEN;
+   if (len > m->m_pkthdr.len) {
+   /* stop processing A-MSDU subframes */
+   DPRINTF(("A-MSDU subframe too long (%d)\n", len));
+   ic->ic_stats.is_rx_decap++;
+   m_freem(m);
+   break;
+   }
 
/* "detach" our A-MSDU subframe from the others */
n = m_split(m, len, M_NOWAIT);
@@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co
}
ieee80211_deliver_data(ic, m, ni);
 
+   if (n->m_len == 0) {
+   m_freem(n);
+   break;
+   }
m = n;
/* remove padding */
pad = ((len + 3) & ~3) - len;

Re: 11n: Finish A-MSDU receive

[Mark Kettenis]

> Date: Sat, 12 Dec 2015 15:32:58 +0100
> From: Stefan Sperling 
> 
> On Sat, Dec 12, 2015 at 03:08:00PM +0100, Mark Kettenis wrote:
> > > @@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co
> > >   }
> > >   ieee80211_deliver_data(ic, m, ni);
> > >  
> > > + if (n->m_len == 0) {
> > > + m_freem(n);
> > > + break;
> > > + }
> > 
> > Can this really happen?  I would expect that m_split() would have
> > returned NULL if we'd tried to split the packet in a way that there is
> > nothing left.  Not sure if that can happen though, but ouldn't it be a
> > bug if it did?
> 
> It's definitely happening during my testing.
> An empty mbuf is the result of a successful split with an empty remainder
> (note the second to last line):
> 
> ieee80211_amsdu_decap: A-MSDU mbuf 0xff0009378900 m_len=3072 
> m_pkthdr.len=3072 hdrlen=26
> ieee80211_amsdu_decap: 0 mbuf 0xff0009378900 m_len=3046 m_pkthdr.len=3046
> ieee80211_amsdu_decap: subframe DA=34:13:e8:29:7f:61 SA=34:13:e8:29:7f:61 
> len=1508
> ieee80211_amsdu_decap: m_split returned 0xff00cbb43900 m_len=1524 
> m_pkthdr.len=1524
> ieee80211_amsdu_decap: delivering mbuf 0xff0009378900 m_len=1514 
> m_pkthdr.len=1514
> ieee80211_amsdu_decap: mbuf 0xff00cbb43900 pad=2
> ieee80211_amsdu_decap: 1 mbuf 0xff00cbb43900 m_len=1522 m_pkthdr.len=1522
> ieee80211_amsdu_decap: subframe DA=34:13:e8:29:7f:61 SA=34:13:e8:29:7f:61 
> len=1508
> ieee80211_amsdu_decap: m_split returned 0xff00cbb43a00 m_len=0 
> m_pkthdr.len=0
> ieee80211_amsdu_decap: delivering mbuf 0xff00cbb43900 m_len=1514 
> m_pkthdr.len=1514
> 
> This should be the if (remain == 0) code path in m_split.
> I could add more printfs in there to show what happens.
> I believe a NULL return would indicate an error.

Actually, you're probably going through the if (m0->m_flags &
M_PKTHDR) code path in m_split(), which will indeed create an empty
mbuf.  Guess there is some room for optimization there, but it is fine
not to worry about this at this stage.

Re: 11n: Finish A-MSDU receive

[Mark Kettenis]

> Date: Sat, 12 Dec 2015 14:26:19 +0100
> From: Stefan Sperling 
> 
> A-MSDU frames are aggregates which contain MSDUs (ethernet frames) as
> subframes, rather than MPDUs (802.11 frames) as A-MPDUs do.
> Each subframe has a header containing sender and target MAC address
> and the subframe's length. For a visual illustration, see
> http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2014_2/remi/img/A-MSDU.png
> 
> The 802.11 standard requires 11n STAs to receive and send A-MSDUs.
> As with A-MPDUs, we only implement receive for now.
> 
> Since the subframes are ethernet frames they go directly to the interface
> input queue via ieee80211_deliver_data(), rather than to ieee80211_input().
> 
> damien@ added code for A-MSDU Rx years ago and it works mostly out of
> the box. This diff adds an upper bounds check on the subframe length,
> and a clean exit at the bottom of the loop for fully processed A-MSDUs
> without which we'd normally terminate the loop via the error handling
> path of the m_pullup() call at the top of the loop.
> 
> Tested against several APs. Only two of my APs send A-MSDUs (fritzbox
> and Linux iwlwifi). With the Linux iwlwifi AP I'm seeing A-MSDU decryption
> failures which I believe is caused by an intel firmware bug since the frame
> sent by the AP has the wrong kind of encryption header (not CCMP).
> The fritzbox AP uses a CCMP header as mandated by the standard so no
> problem there.
> 
> Note that A-MPDUs may contain A-MSDUs in subframes. The iwlwifi AP
> sends frames like this (unencrypted, though ;) so I could confirm
> that this works as expected.
> 
> Index: net80211/ieee80211_input.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
> retrieving revision 1.143
> diff -u -p -r1.143 ieee80211_input.c
> --- net80211/ieee80211_input.c12 Dec 2015 11:25:46 -  1.143
> +++ net80211/ieee80211_input.c12 Dec 2015 13:04:29 -
> @@ -1061,6 +1061,13 @@ ieee80211_amsdu_decap(struct ieee80211co
>   len -= LLC_SNAPFRAMELEN;
>   }
>   len += ETHER_HDR_LEN;
> + if (len > m->m_pkthdr.len) {
> + /* stop processing A-MSDU subframes */
> + DPRINTF(("A-MSDU subframe too long (%d)\n", len));
> + ic->ic_stats.is_rx_decap++;
> + m_freem(m);
> + break;
> + }
>  
>   /* "detach" our A-MSDU subframe from the others */
>   n = m_split(m, len, M_NOWAIT);
> @@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co
>   }
>   ieee80211_deliver_data(ic, m, ni);
>  
> + if (n->m_len == 0) {
> + m_freem(n);
> + break;
> + }

Can this really happen?  I would expect that m_split() would have
returned NULL if we'd tried to split the packet in a way that there is
nothing left.  Not sure if that can happen though, but ouldn't it be a
bug if it did?

>   m = n;
>   /* remove padding */
>   pad = ((len + 3) & ~3) - len;
> 
> 

[patch] sys_execve: clean up code that prepares args and env

[Maxim Pugachev]

Hi,

This patch removes copypasted code that prepares args and env in exec
system call.


Index: sys/kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.173
diff -u -p -r1.173 kern_exec.c
--- sys/kern/kern_exec.c5 Dec 2015 10:11:53 -   1.173
+++ sys/kern/kern_exec.c12 Dec 2015 17:34:43 -
@@ -77,6 +77,12 @@ const struct kmem_va_mode kv_exec = {
.kv_map = _map
 };

+struct argcontext
+{
+   char *buffer;
+   char *bptr;
+};
+
 /*
  * Map the shared signal code.
  */
@@ -231,6 +237,58 @@ bad1:
return (error);
 }

+void
+copy_fake_args(struct exec_package *pack, struct argcontext *argctx,
+long *count)
+{
+   char **fake_args_vec = pack->ep_fa;
+
+   while (*fake_args_vec != NULL) {
+   char *arg = *fake_args_vec;
+
+   while (*arg)
+   *argctx->bptr++ = *arg++;
+
+   *argctx->bptr++ = '\0';
+
+   free(*fake_args_vec, M_EXEC, 0);
+
+   fake_args_vec++;
+   (*count)++;
+   }
+
+   free(pack->ep_fa, M_EXEC, 0);
+   pack->ep_flags &= ~EXEC_HASARGL;
+}
+
+int
+copy_strings(char * const *src, struct argcontext *argctx, long *count)
+{
+   int error;
+   size_t len;
+   size_t maxlen = argctx->buffer + ARG_MAX - argctx->bptr;
+   char *sp;
+
+   while (1) {
+   if ((error = copyin(src, , sizeof(sp))) != 0)
+   return error;
+   if (!sp)
+   break;
+   if ((error = copyinstr(sp, argctx->bptr, maxlen, )) != 0) {
+   if (error == ENAMETOOLONG)
+   error = E2BIG;
+   return error;
+   }
+
+   maxlen -= len;
+   argctx->bptr += len;
+   src++;
+   (*count)++;
+   }
+
+   return 0;
+}
+
 /*
  * exec system call
  */
@@ -242,13 +300,13 @@ sys_execve(struct proc *p, void *v, regi
syscallarg(char *const *) argp;
syscallarg(char *const *) envp;
} */ *uap = v;
+   struct argcontext argctx;
int error;
struct exec_package pack;
struct nameidata nid;
struct vattr attr;
struct ucred *cred = p->p_ucred;
-   char *argp;
-   char * const *cpp, *dp, *sp;
+   char * const *cpp;
 #ifdef KTRACE
char *env_start;
 #endif
@@ -261,7 +319,6 @@ sys_execve(struct proc *p, void *v, regi
char *stack;
struct ps_strings arginfo;
struct vmspace *vm = pr->ps_vmspace;
-   char **tmpfap;
extern struct emul emul_native;
 #if NSYSTRACE > 0
int wassugid = ISSET(pr->ps_flags, PS_SUGID | PS_SUGIDEXEC);
@@ -317,38 +374,23 @@ sys_execve(struct proc *p, void *v, regi
pack.ep_flags = 0;

/* see if we can run it. */
-   if ((error = check_exec(p, )) != 0) {
+   if ((error = check_exec(p, )) != 0)
goto freehdr;
-   }

/* XXX -- THE FOLLOWING SECTION NEEDS MAJOR CLEANUP */
-
+
/* allocate an argument buffer */
-   argp = km_alloc(NCARGS, _exec, _pageable, _waitok);
+   argctx.buffer = km_alloc(NCARGS, _exec, _pageable, _waitok);
 #ifdef DIAGNOSTIC
-   if (argp == NULL)
-   panic("execve: argp == NULL");
+   if (argctx.buffer == NULL)
+   panic("execve: argctx.buffer == NULL");
 #endif
-   dp = argp;
+   argctx.bptr = argctx.buffer;
argc = 0;

/* copy the fake args list, if there's one, freeing it as we go */
-   if (pack.ep_flags & EXEC_HASARGL) {
-   tmpfap = pack.ep_fa;
-   while (*tmpfap != NULL) {
-   char *cp;
-
-   cp = *tmpfap;
-   while (*cp)
-   *dp++ = *cp++;
-   *dp++ = '\0';
-
-   free(*tmpfap, M_EXEC, 0);
-   tmpfap++; argc++;
-   }
-   free(pack.ep_fa, M_EXEC, 0);
-   pack.ep_flags &= ~EXEC_HASARGL;
-   }
+   if (pack.ep_flags & EXEC_HASARGL)
+   copy_fake_args(, , );

/* Now get argv & environment */
if (!(cpp = SCARG(uap, argp))) {
@@ -359,21 +401,9 @@ sys_execve(struct proc *p, void *v, regi
if (pack.ep_flags & EXEC_SKIPARG)
cpp++;

-   while (1) {
-   len = argp + ARG_MAX - dp;
-   if ((error = copyin(cpp, , sizeof(sp))) != 0)
-   goto bad;
-   if (!sp)
-   break;
-   if ((error = copyinstr(sp, dp, len, )) != 0) {
-   if (error == ENAMETOOLONG)
-   error = E2BIG;
-   goto bad;
-   }
-   dp += len;
-   cpp++;
-   argc++;

Re: 11n: Finish A-MSDU receive

[Stefan Sperling]

On Sat, Dec 12, 2015 at 03:08:00PM +0100, Mark Kettenis wrote:
> > @@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co
> > }
> > ieee80211_deliver_data(ic, m, ni);
> >  
> > +   if (n->m_len == 0) {
> > +   m_freem(n);
> > +   break;
> > +   }
> 
> Can this really happen?  I would expect that m_split() would have
> returned NULL if we'd tried to split the packet in a way that there is
> nothing left.  Not sure if that can happen though, but ouldn't it be a
> bug if it did?

It's definitely happening during my testing.
An empty mbuf is the result of a successful split with an empty remainder
(note the second to last line):

ieee80211_amsdu_decap: A-MSDU mbuf 0xff0009378900 m_len=3072 
m_pkthdr.len=3072 hdrlen=26
ieee80211_amsdu_decap: 0 mbuf 0xff0009378900 m_len=3046 m_pkthdr.len=3046
ieee80211_amsdu_decap: subframe DA=34:13:e8:29:7f:61 SA=34:13:e8:29:7f:61 
len=1508
ieee80211_amsdu_decap: m_split returned 0xff00cbb43900 m_len=1524 
m_pkthdr.len=1524
ieee80211_amsdu_decap: delivering mbuf 0xff0009378900 m_len=1514 
m_pkthdr.len=1514
ieee80211_amsdu_decap: mbuf 0xff00cbb43900 pad=2
ieee80211_amsdu_decap: 1 mbuf 0xff00cbb43900 m_len=1522 m_pkthdr.len=1522
ieee80211_amsdu_decap: subframe DA=34:13:e8:29:7f:61 SA=34:13:e8:29:7f:61 
len=1508
ieee80211_amsdu_decap: m_split returned 0xff00cbb43a00 m_len=0 
m_pkthdr.len=0
ieee80211_amsdu_decap: delivering mbuf 0xff00cbb43900 m_len=1514 
m_pkthdr.len=1514

This should be the if (remain == 0) code path in m_split.
I could add more printfs in there to show what happens.
I believe a NULL return would indicate an error.

To get above values printed I used the following debug printfs:

Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.145
diff -u -p -r1.145 ieee80211_input.c
--- ieee80211_input.c   12 Dec 2015 13:56:10 -  1.145
+++ ieee80211_input.c   12 Dec 2015 14:30:43 -
@@ -1021,15 +1021,22 @@ ieee80211_amsdu_decap(struct ieee80211co
struct ether_header *eh;
struct llc *llc;
int len, pad;
+   int i = 0;
+
+   printf("%s: A-MSDU mbuf %p m_len=%d m_pkthdr.len=%d hdrlen=%d\n", 
__func__,
+   m, m->m_len, m->m_pkthdr.len, hdrlen);
 
/* strip 802.11 header */
m_adj(m, hdrlen);
 
for (;;) {
+   printf("%s: %d mbuf %p m_len=%d m_pkthdr.len=%d\n", __func__,
+   i++, m, m->m_len, m->m_pkthdr.len);
/* process an A-MSDU subframe */
if (m->m_len < ETHER_HDR_LEN + LLC_SNAPFRAMELEN) {
m = m_pullup(m, ETHER_HDR_LEN + LLC_SNAPFRAMELEN);
if (m == NULL) {
+   printf("%s: m_pullup failed\n", __func__);
ic->ic_stats.is_rx_decap++;
break;
}
@@ -1037,8 +1044,11 @@ ieee80211_amsdu_decap(struct ieee80211co
eh = mtod(m, struct ether_header *);
/* examine 802.3 header */
len = ntohs(eh->ether_type);
+   printf("%s: subframe DA=%s SA=%s len=%d\n", __func__,
+   ether_sprintf(eh->ether_dhost),
+   ether_sprintf(eh->ether_shost), len);
if (len < LLC_SNAPFRAMELEN) {
-   DPRINTF(("A-MSDU subframe too short (%d)\n", len));
+   printf("A-MSDU subframe too short (%d)\n", len);
/* stop processing A-MSDU subframes */
ic->ic_stats.is_rx_decap++;
m_freem(m);
@@ -1063,7 +1073,7 @@ ieee80211_amsdu_decap(struct ieee80211co
len += ETHER_HDR_LEN;
if (len > m->m_pkthdr.len) {
/* stop processing A-MSDU subframes */
-   DPRINTF(("A-MSDU subframe too long (%d)\n", len));
+   printf("A-MSDU subframe too long (%d)\n", len);
ic->ic_stats.is_rx_decap++;
m_freem(m);
break;
@@ -1073,10 +1083,18 @@ ieee80211_amsdu_decap(struct ieee80211co
n = m_split(m, len, M_NOWAIT);
if (n == NULL) {
/* stop processing A-MSDU subframes */
+   printf("%s: m_split failed mbuf %p m_len=%d "
+   "m_pkthdr.len=%d\n", __func__, m, m->m_len,
+   m->m_pkthdr.len);
ic->ic_stats.is_rx_decap++;
m_freem(m);
break;
}
+   printf("%s: m_split returned %p m_len=%d m_pkthdr.len=%d\n",
+   __func__, n, n->m_len, n->m_pkthdr.len);
+
+   printf("%s: delivering mbuf %p m_len=%d m_pkthdr.len=%d\n",
+   

Re: cwm: Three tiny patches

[Vadim Vygonets]

Pressed the wrong button, sent before writing text.  Sorry about
that.

Hi!  Have some patches for cwm.

cwm-cycling-urgency.diff
Don't clear urgency flag while cycling

cwm-ignored-borders.diff
Don't put border on ignored clients when returning from fullscreen

cwm-minsize.diff
Remove redundant minimum client size adjustment
(minw and minh are always positive since mid-November)

Vadik.

-- 
When in doubt, be yourself.  And if that fails, su root.
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 17:26:39 -
@@ -219,13 +219,15 @@
 		client_draw_border(oldcc);
 	}
 
-	/* If we're in the middle of cycing, don't change the order. */
-	if (!sc->cycling)
+	/* If we're in the middle of cycing, don't change the order or
+	 * clear the urgency flag. */
+	if (!sc->cycling) {
 		client_mtf(cc);
+		cc->flags &= ~CLIENT_URGENCY;
+	}
 
 	curcc = cc;
 	cc->flags |= CLIENT_ACTIVE;
-	cc->flags &= ~CLIENT_URGENCY;
 	client_draw_border(cc);
 	conf_grab_mouse(cc->win);
 	xu_ewmh_net_active_window(sc, cc->win);
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 17:25:16 -
@@ -297,7 +297,8 @@
 		return;
 
 	if (cc->flags & CLIENT_FULLSCREEN) {
-		cc->bwidth = Conf.bwidth;
+		if (!(cc->flags & CLIENT_IGNORE))
+			cc->bwidth = Conf.bwidth;
 		cc->geom = cc->fullgeom;
 		cc->flags &= ~(CLIENT_FULLSCREEN | CLIENT_FREEZE);
 		goto resize;
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 18:04:59 -
@@ -898,9 +898,6 @@
 	if (cc->hint.maxh)
 		cc->geom.h = MIN(cc->geom.h, cc->hint.maxh);
 
-	cc->geom.w = MAX(cc->geom.w, 1);
-	cc->geom.h = MAX(cc->geom.h, 1);
-
 	cc->dim.w = (cc->geom.w - cc->hint.basew) / cc->hint.incw;
 	cc->dim.h = (cc->geom.h - cc->hint.baseh) / cc->hint.inch;
 }

[patch] cwm: Fix screen_area(), remove unused fields from region_ctx

[Vadim Vygonets]

Hi,

In screen_area(), if no matching region is found, the gap will
effectively be applied one time too many.  Additionally,
region_ctx.work is never used, and .area is the same as .view, so
I removed these (except .view).

After this patch, screen_ctx.work is only used in
xu_ewmh_net_workarea(), so it can be removed later.

Vadik.

-- 
If there was anything that depressed him more than his own
cynicism, it was that quite often it still wasn't as cynical as
real life.
-- Terry Pratchett, "Guards! Guards!"
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.311
diff -u -r1.311 calmwm.h
--- calmwm.h	12 Nov 2015 21:28:03 -	1.311
+++ calmwm.h	12 Dec 2015 17:28:02 -
@@ -218,9 +218,7 @@
 struct region_ctx {
 	TAILQ_ENTRY(region_ctx)	 entry;
 	int			 num;
-	struct geom		 area;
 	struct geom		 view; /* viewable area */
-	struct geom		 work; /* workable area, gap-applied */
 };
 TAILQ_HEAD(region_ctx_q, region_ctx);
 
Index: screen.c
===
RCS file: /cvs/xenocara/app/cwm/screen.c,v
retrieving revision 1.79
diff -u -r1.79 screen.c
--- screen.c	11 Nov 2015 14:22:01 -	1.79
+++ screen.c	12 Dec 2015 17:28:03 -
@@ -142,12 +142,12 @@
 screen_area(struct screen_ctx *sc, int x, int y, int flags)
 {
 	struct region_ctx	*rc;
-	struct geom		 area = sc->work;
+	struct geom		 area = sc->view;
 
 	TAILQ_FOREACH(rc, >regionq, entry) {
-		if ((x >= rc->area.x) && (x < (rc->area.x + rc->area.w)) &&
-		(y >= rc->area.y) && (y < (rc->area.y + rc->area.h))) {
-			area = rc->area;
+		if ((x >= rc->view.x) && (x < (rc->view.x + rc->view.w)) &&
+		(y >= rc->view.y) && (y < (rc->view.y + rc->view.h))) {
+			area = rc->view;
 			break;
 		}
 	}
@@ -189,15 +189,10 @@
 
 			rc = xmalloc(sizeof(*rc));
 			rc->num = i;
-			rc->area.x = ci->x;
-			rc->area.y = ci->y;
-			rc->area.w = ci->width;
-			rc->area.h = ci->height;
 			rc->view.x = ci->x;
 			rc->view.y = ci->y;
 			rc->view.w = ci->width;
 			rc->view.h = ci->height;
-			rc->work = screen_apply_gap(sc, rc->view);
 			TAILQ_INSERT_TAIL(>regionq, rc, entry);
 
 			XRRFreeCrtcInfo(ci);
@@ -210,7 +205,6 @@
 		rc->view.y = 0;
 		rc->view.w = DisplayWidth(X_Dpy, sc->which);
 		rc->view.h = DisplayHeight(X_Dpy, sc->which);
-		rc->work = screen_apply_gap(sc, rc->view);
 		TAILQ_INSERT_TAIL(>regionq, rc, entry);
 	}
 

Re: 2D acceleration for Nvidia

[Juan Francisco Cantero Hurtado]

On Sat, Dec 12, 2015 at 03:06:01AM +0100, Theo Buehler wrote:
> On Fri, Dec 11, 2015 at 10:09:20AM +0100, Martin Pieuchot wrote:
> > Without hardware acceleration my PowerBook G4 12'' with a NVIDIA
> > GeForce FX Go 5200 is unusable.  Since XAA is no longer supported,
> > here's a simple EXA backend for nv(4) based on the XAA sources and
> > Nouveau.  It only implements Solid and Copy but that already makes
> > a huge difference.
> > 
> > To test it you need to regenerate configure scripts for xf86-video-nv
> > as described in /usr/xenocara/README.
> > 
> > I can provide a diff for upstream it the driver is still maintained.
> > 
> > I'd like to hear from people using NVidia cards.
> > 
> 
> This is quite an impressive improvement, thanks a lot!  Full screen
> video becomes watchable.  However, trying to move an xterm with the
> mouse still isn't fun.

Try this xorg.conf:
Section "Device"
Identifier "nvidia modesetting"
Driver "modesetting"
Option "HWCursor" "off"
EndSection
 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

[patch] kern/exec_script: return error when the shell name is not specified

[Maxim Pugachev]

Hi,

In a case when the shell name is not specified (i.e. just "#!" without
a path), don't run the heavy logic that checks shell, simply return
ENOENT.

Also, as a tiny improvement: avoid a loop when calculating shell's args length.


Index: sys/kern/exec_script.c
===
RCS file: /cvs/src/sys/kern/exec_script.c,v
retrieving revision 1.36
diff -u -p -r1.36 exec_script.c
--- sys/kern/exec_script.c  10 Sep 2015 18:10:35 -  1.36
+++ sys/kern/exec_script.c  12 Dec 2015 21:18:22 -
@@ -69,7 +69,7 @@ exec_script_makecmds(struct proc *p, str
 {
int error, hdrlinelen, shellnamelen, shellarglen;
char *hdrstr = epp->ep_hdr;
-   char *cp, *shellname, *shellarg, *oldpnbuf;
+   char *cp, *endcp, *shellname, *shellarg, *oldpnbuf;
char **shellargp = NULL, **tmpsap;
struct vnode *scriptvp;
uid_t script_uid = -1;
@@ -103,6 +103,7 @@ exec_script_makecmds(struct proc *p, str
for (cp = hdrstr + EXEC_SCRIPT_MAGICLEN; cp < hdrstr + hdrlinelen;
cp++) {
if (*cp == '\n') {
+   endcp = cp;
*cp = '\0';
break;
}
@@ -119,21 +120,23 @@ exec_script_makecmds(struct proc *p, str
cp++)
;

+   /* return error when the shell name is not specified */
+   if (cp == endcp)
+   return ENOENT;
+
/* collect the shell name; remember its length for later */
shellname = cp;
shellnamelen = 0;
-   if (*cp == '\0')
-   goto check_shell;
for ( /* cp = cp */ ; *cp != '\0' && *cp != ' ' && *cp != '\t'; cp++)
shellnamelen++;
-   if (*cp == '\0')
+   if (cp == endcp)
goto check_shell;
*cp++ = '\0';

/* skip spaces before any argument */
for ( /* cp = cp */ ; *cp == ' ' || *cp == '\t'; cp++)
;
-   if (*cp == '\0')
+   if (cp == endcp)
goto check_shell;

/*
@@ -142,9 +145,7 @@ exec_script_makecmds(struct proc *p, str
 * behaviour.
 */
shellarg = cp;
-   for ( /* cp = cp */ ; *cp != '\0'; cp++)
-   shellarglen++;
-   *cp++ = '\0';
+   shellarglen = endcp - cp;

 check_shell:
/*

Re: [patch] malloc: size that was passed to free() should land into the same bucket

[Maxim Pugachev]

On Wed, Dec 9, 2015 at 9:26 PM, Maxim Pugachev  wrote:
> Hi,
>
> Currently two checks in free() function confirm the correctness of
> freedsize argument. I think that it's better to check that provided
> freedsize fall into the same bucket that was recorded in kmemusage
> struct: it covers both cases.

Ping?

Re: Use off_t for lineno in csplit

[Michael McConville]

Mark Kettenis wrote:
> It really is confusing to use off_t for something that's not a byte
> offset.  If integer overflow really is an issue you care about, use
> "long long".

ok for the below diff to update my grep change?

> Note that on many non-BSD systems off_t is still a 32-bit integer, at
> least by default.  So using off_t doesn't help portability.  Search
> the interwebs for "Large File Summit" for the full horror story!

Thanks for the reference.  :-)  Interesting read.


Index: grep.h
===
RCS file: /cvs/src/usr.bin/grep/grep.h,v
retrieving revision 1.23
diff -u -p -r1.23 grep.h
--- grep.h  7 Dec 2015 18:50:06 -   1.23
+++ grep.h  11 Dec 2015 02:18:02 -
@@ -43,7 +43,7 @@
 
 typedef struct {
size_t   len;
-   off_tline_no;
+   long longline_no;
off_toff;
char*file;
char*dat;
Index: util.c
===
RCS file: /cvs/src/usr.bin/grep/util.c,v
retrieving revision 1.51
diff -u -p -r1.51 util.c
--- util.c  7 Dec 2015 18:50:06 -   1.51
+++ util.c  11 Dec 2015 02:18:02 -
@@ -623,7 +623,7 @@ printline(str_t *line, int sep, regmatch
if (nflag) {
if (n)
putchar(sep);
-   printf("%lld", (long long)line->line_no);
+   printf("%lld", line->line_no);
++n;
}
if (bflag) {

PermitRootLogin - installer vs sshd defaults

[Raf Czlonka]

Hi all,

In April, sshd(8)'s PermitRootLogin option's default setting has been
changed to 'no'[0], then to 'without-password'[1], which in turn got
renamed to 'prohibit-password'[2].

At the same time as the latter, the installer's default suggested answer
has been changed to 'no'[3]:

"Allow root ssh login? (yes, no, prohibit-password)" no

I test snapshots on a number of physical and virtual machines on regular
basis. Recently I upgraded storage on one of the former - got an SSD
and ran a clean install. I like the installer's defaults so happily
accepted those when prompted, then after a couple of hours I upgraded to
the newest snapshot. As I like to know what changes between snapshots,
I always run sysmerge(8) with '-d' option, amongst other things.
Upon upgrading to the next snapshot and running sysmerge, I had been
presented with this diff:

-PermitRootLogin no
+#PermitRootLogin prohibit-password

>From clean install using defaults to a new snapshot within a couple of
hours and straight away I was informed that my settings deviate from the
software defaults, even though I hadn't changed a thing after install
- had I done so, information like that would have been expected. Worth
mentioning is the fact that the above was the *only* message I got from
sysmerge. Unless I had made post-install changes to config files on my
system, I would have expected sysmerge not to produce *any* output.

This email is not as much about PermitRootLogin option in sshd_config or
which setting is "better" as the default, as it is about the installer
vs software defaults, in other words "consistency" - PermitRootLogin
simply happens to be the *only* inconsistency.

Finally, a couple of questions:

1. Shouldn't the installer's suggested default answers reflect the
defaults on the system, and if not, why?

2. Shouldn't PermitRootLogin default settings be synchronised as per the
above, and if not, why?

Regards,

Raf

[0] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.diff?r1=1.94=1.95=h
[1] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.diff?r1=1.95=1.96=h
[2] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.diff?r1=1.96=1.97=h
[3] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub.diff?r1=1.853=1.854=h

cwm: Three tiny patches

[Vadim Vygonets]

-- 
You mean you need drugs to hallucinate?  (K)
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 17:26:39 -
@@ -219,13 +219,15 @@
 		client_draw_border(oldcc);
 	}
 
-	/* If we're in the middle of cycing, don't change the order. */
-	if (!sc->cycling)
+	/* If we're in the middle of cycing, don't change the order or
+	 * clear the urgency flag. */
+	if (!sc->cycling) {
 		client_mtf(cc);
+		cc->flags &= ~CLIENT_URGENCY;
+	}
 
 	curcc = cc;
 	cc->flags |= CLIENT_ACTIVE;
-	cc->flags &= ~CLIENT_URGENCY;
 	client_draw_border(cc);
 	conf_grab_mouse(cc->win);
 	xu_ewmh_net_active_window(sc, cc->win);
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 17:25:16 -
@@ -297,7 +297,8 @@
 		return;
 
 	if (cc->flags & CLIENT_FULLSCREEN) {
-		cc->bwidth = Conf.bwidth;
+		if (!(cc->flags & CLIENT_IGNORE))
+			cc->bwidth = Conf.bwidth;
 		cc->geom = cc->fullgeom;
 		cc->flags &= ~(CLIENT_FULLSCREEN | CLIENT_FREEZE);
 		goto resize;
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.214
diff -u -r1.214 client.c
--- client.c	12 Nov 2015 18:33:30 -	1.214
+++ client.c	12 Dec 2015 18:04:59 -
@@ -898,9 +898,6 @@
 	if (cc->hint.maxh)
 		cc->geom.h = MIN(cc->geom.h, cc->hint.maxh);
 
-	cc->geom.w = MAX(cc->geom.w, 1);
-	cc->geom.h = MAX(cc->geom.h, 1);
-
 	cc->dim.w = (cc->geom.w - cc->hint.basew) / cc->hint.incw;
 	cc->dim.h = (cc->geom.h - cc->hint.baseh) / cc->hint.inch;
 }

Re: Use off_t for lineno in csplit

[Mark Kettenis]

> Date: Sat, 12 Dec 2015 16:26:30 -0500
> From: Michael McConville 
> 
> Mark Kettenis wrote:
> > It really is confusing to use off_t for something that's not a byte
> > offset.  If integer overflow really is an issue you care about, use
> > "long long".
> 
> ok for the below diff to update my grep change?

Fine with me.

> Index: grep.h
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.h,v
> retrieving revision 1.23
> diff -u -p -r1.23 grep.h
> --- grep.h7 Dec 2015 18:50:06 -   1.23
> +++ grep.h11 Dec 2015 02:18:02 -
> @@ -43,7 +43,7 @@
>  
>  typedef struct {
>   size_t   len;
> - off_tline_no;
> + long longline_no;
>   off_toff;
>   char*file;
>   char*dat;
> Index: util.c
> ===
> RCS file: /cvs/src/usr.bin/grep/util.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 util.c
> --- util.c7 Dec 2015 18:50:06 -   1.51
> +++ util.c11 Dec 2015 02:18:02 -
> @@ -623,7 +623,7 @@ printline(str_t *line, int sep, regmatch
>   if (nflag) {
>   if (n)
>   putchar(sep);
> - printf("%lld", (long long)line->line_no);
> + printf("%lld", line->line_no);
>   ++n;
>   }
>   if (bflag) {
> 

Re: [patch] malloc: add info about the largest consumers of memory

[Maxim Pugachev]

On Wed, Dec 9, 2015 at 8:03 PM, Maxim Pugachev  wrote:
> Hi,
>
> This patch adds additional informational to ddb's "show malloc"
> command about the largest consumers of memory.

Ping?

Re: [patch] malloc: size that was passed to free() should land into the same bucket

[Bob Beck]

On Sun, Dec 13, 2015 at 12:30:54AM +0300, Maxim Pugachev wrote:
> On Wed, Dec 9, 2015 at 9:26 PM, Maxim Pugachev  wrote:
> > Hi,
> >
> > Currently two checks in free() function confirm the correctness of
> > freedsize argument. I think that it's better to check that provided
> > freedsize fall into the same bucket that was recorded in kmemusage
> > struct: it covers both cases.
> 
> Ping?

You're not being ignored.  I have pinged the tedu for you :) 

-Bob

Re: [patch] malloc: size that was passed to free() should land into the same bucket

[Maxim Pugachev]

>> Ping?
>
> You're not being ignored.  I have pinged the tedu for you :)

Great, thank you, Bob :)