We invite you to work in your spare time for $ 100 per hour
We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email ma...@jobmarketeurope.com and I will answer you personally as soon as possible Sincerely, Mario Hargrove ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
USB over IP
I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: USB over IP
Hi, On 2012-05-21 12:46, Daniel Braniss wrote: I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. I'm not entirely sure about your setup - you write usb based controllers - and then mostly serial... I know it is not strictly speaking usb over ip - but did you look at RFC 2217 ? https://tools.ietf.org/html/rfc2217 There are several projects supporting RFC 2217: http://ser2net.sourceforge.net/ http://sourceforge.net/projects/sercd/ http://sourceforge.net/projects/cyclades-serial/ ser2net and sredird are in FreeBSD ports: http://www.freshports.org/comms/ser2net/ http://www.freshports.org/comms/sredird/ /Uffe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: USB over IP
Hi, On 2012-05-21 12:46, Daniel Braniss wrote: I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. I'm not entirely sure about your setup - you write usb based controllers - and then mostly serial... I know, the word serial is confusing, what I meant is that the USB connection (which could be a mass-storage, camera, etc) is in my case serial (ie rs232) I know it is not strictly speaking usb over ip - but did you look at RFC 2217 ? yes, but it's not relevant to what I'm looking for, I want to send/receive the USB protocol over IP. I only mentioned the serial (rs232) because I don't need speed (as opposed to a camera, audio, etc) cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: USB over IP
something similar is being done in the latest versions of qemu. There is a usb redirection module which is in the form of a client/server architecture where USB packets are sent over IP. These two modules communicate with eachother through a protocol developed specifically for the redirection of USB devices over IP so if I were you I would have a look at the qemu code for some ideas. On Mon, May 21, 2012 at 2:24 PM, Daniel Braniss da...@cs.huji.ac.il wrote: Hi, On 2012-05-21 12:46, Daniel Braniss wrote: I need to control some lab equipment with several usb based controllers (mostly serial) and was wondering if it can be done over IP, there is such a thing called usbip, but couldn't find what 'server' is needed. all the boxes I found are not cheep, but worse, only provide binaries for windows, or linux. I'm not entirely sure about your setup - you write usb based controllers - and then mostly serial... I know, the word serial is confusing, what I meant is that the USB connection (which could be a mass-storage, camera, etc) is in my case serial (ie rs232) I know it is not strictly speaking usb over ip - but did you look at RFC 2217 ? yes, but it's not relevant to what I'm looking for, I want to send/receive the USB protocol over IP. I only mentioned the serial (rs232) because I don't need speed (as opposed to a camera, audio, etc) cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: USB over IP
--047d7b10ce794d5a1004c08b261e Content-Type: text/plain; charset=ISO-8859-1 something similar is being done in the latest versions of qemu. There is a usb redirection module which is in the form of a client/server architecture where USB packets are sent over IP. These two modules communicate with eachother through a protocol developed specifically for the redirection of USB devices over IP so if I were you I would have a look at the qemu code for some ideas. do you know if there is a description of the protocol (rfc?) like there is for iscsi, or ata ip? there is alos the usbip project for linux, maybe it can be ported ... cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
PID/UID namespaces
Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a Process Descriptor. Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. -- PGP: 6141 5FFD 11AE 9844 153E F268 7C98 7268 6B19 6CC9 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ARM + CACHE_LINE_SIZE + DMA
On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote:
On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
Hi,
I'm working on DMA bus implementation for ARM11mpcore platform. I've
looked at implementation in ARM tree, but IMHO it only works with some
assumptions. There is a problem with DMA on memory block which is not
aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent.
Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE.
Then first cache line associated with the buffer can be divided into
two parts, A and B, where A is a memory we know nothing about it and B
is buffer memory. The same stands for last cache line associatted with
the buffer. We have no problem if a memory is coherent. Otherwise it
depends on memory attributes.
1. [no cache] attribute
No problem as memory is coherent.
2. [write throught] attribute
The part A can be invalidated without loss of any data. It's not problem
too.
3. [write back] attribute
In general, there is no way how to keep both parts consistent. At the
start of DMA transaction, the cache line is written back and
invalidated. However, as we know nothing about memory associated with
part A of the cache line, the cache line can be filled again at any
time and messing up DMA transaction if flushed. Even if the cache line
is only filled but not flushed during DMA transaction, we must make it
coherent with memory after that. There is a trick with saving part A
of the line into temporary buffer, invalidating the line, and
restoring part A in current ARM (MIPS) implementation. However, if
somebody is writting to memory associated with part A of the line
during this trick, the part A will be messed up. Moreover, the part A
can be part of another DMA transaction.
To safely use DMA with no coherent memory, a memory with [no cache] or
[write throught] attributes can be used without problem. A memory with
[write back] attribute must be aligned on CACHE_LINE_SIZE.
However, for example mbuf, a buffer for DMA can be part of a structure
which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We
can know that nobody will write to the structure during DMA
transaction, so it's safe to use the buffer event if it's not aligned
on CACHE_LINE_SIZE.
So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and
we want to avoid bounce pages overhead, we must support additional
information to DMA transaction. It should be easy to support the
information about drivers data buffers. However, what about OS data
buffers like mentioned mbufs?
The question is following. Is or can be guaranteed for all or at least
well-known OS data buffers which can be part of DMA access that the
not CACHE_LINE_SIZE aligned buffers are surrounded by data which
belongs to the same object as the buffer and the data is not written
by OS when given to a driver?
Any answer is appreciated. However, 'bounce pages' is not an answer.
Thanks, Svata
I'm adding freebsd-arm@ to the CC list; that's where this has been
discussed before.
Your analysis is correct... to the degree that it works at all right
now, it's working by accident. At work we've been making the good
accident a bit more likely by setting the minimum allocation size to
arm_dcache_align in kern_malloc.c. This makes it somewhat less likely
that unrelated objects in the kernel are sharing a cache line, but it
also reduces the effectiveness of the cache somewhat.
Another factor, not mentioned in your analysis, is the size of the IO
operation. Even if the beginning of the DMA buffer is cache-aligned, if
the size isn't exactly a multiple of the cache line size you still have
the partial flush situation and all of its problems.
It's not guaranteed that data surrounding a DMA buffer will be untouched
during the DMA, even when that surrounding data is part of the same
conceptual object as the IO buffer. It's most often true, but certainly
not guaranteed. In addition, as Mark pointed out in a prior reply,
sometimes the DMA buffer is on the stack, and even returning from the
function that starts the IO operation affects the cacheline associated
with the DMA buffer. Consider something like this:
void do_io()
{
int buffer;
start_read(buffer);
// maybe do other stuff here
wait_for_read_done();
}
start_read() gets some IO going, so before it returns a call has been
made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets
done on the cacheline containing the variable 'buffer'. The act of
returning from the start_read() function causes that cacheline to get
reloaded, so now the stale pre-DMA value of the variable 'buffer' is in
cache again. Right after that, the DMA completes so that ram
Re: Need to revert behavior of OpenSSH to the old key order ...
Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting rsa, then dsa to dsa, then rsa was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? --- On Thu, 5/17/12, Jason Hellenthal jhellent...@dataix.net wrote: I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. Everything goes just fine, but when I am done, existing clients are now presented with this message: WARNING: DSA key found for host hostname in /root/.ssh/known_hosts:12 DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... The authenticity of host 'hostname (10.1.2.3)' can't be established but keys of different type are already known for this host. RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. Are you sure you want to continue connecting (yes/no) You must be using different keys for your server than the one that has been generated before the upgrade. Just copy your keys over to the new location and restart the server daemon and you should be fine. copy /etc/ssh/* - /usr/local/etc/ssh/ You didn't read that error message. Sorry I misread that. Decieving message... That is not the standard key mismatch error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). Have you attempted to change that order via sshd_config and placing the DSA directive before the RSA one ? -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
OK guys I've been talking with another user who can recreate this crash and the last bit of information we've learned seems to be leaning towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. I'm still trying to test this myself, but the other user was able to recreate my crash pretty much on demand. The fix was to not use the first NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the crash does not seem to be reproducible anymore. Before: $ vmstat -i interrupt total rate irq1: atkbd0 378 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1687237 1 irq18: em0 mpt0319094024539 cpu0: timer236770821400 Total 556552503940 After: $ vmstat -i interrupt total rate irq1: atkbd0 38 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 2811 15 irq17: em2 5 0 cpu0: timer71013398 irq256: mpt0 12163 68 Total 86073483 Is there any other way we can make mpt0 get its own dedicated IRQ without having to do this? The problem is that it causes us to have to make rc.conf changes, pf.conf changes, and who knows what other software could be on these machines that is trying to bind to a specific NIC... Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Something wrong with curs_threads(3X) ?
Hi, In curs_threads(3X), at the beginning of the manual: typedef int (*NCURSES_WINDOW_CB)(WINDOW *, void *); typedef int (*NCURSES_SCREEN_CB)(SCREEN *, void *); int set_escdelay(int size); int set_tabsize(int size); int use_screen(SCREEN *scr, NCURSES_WINDOW_CB func, void *data); int use_window(WINDOW *win, NCURSES_SCREEN_CB func, void *data); use_screen = NCURSES_WINDOW_CB use_window = NCURSES_SCREEN_CB Target is not matched, I'm really confused. So I open /usr/include/curses.h, and find these: extern NCURSES_EXPORT(int) use_screen (SCREEN *, NCURSES_SCREEN_CB, void *); extern NCURSES_EXPORT(int) use_window (WINDOW *, NCURSES_WINDOW_CB, void *); Seems much proper. So is this a bug? -- Best regards, Yanhui Shen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On May 21, 2012, at 12:41 PM, Mark Felder wrote: OK guys I've been talking with another user who can recreate this crash and the last bit of information we've learned seems to be leaning towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. I'm still trying to test this myself, but the other user was able to recreate my crash pretty much on demand. The fix was to not use the first NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the crash does not seem to be reproducible anymore. Before: $ vmstat -i interrupt total rate irq1: atkbd0 378 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1687237 1 irq18: em0 mpt0319094024539 cpu0: timer236770821400 Total 556552503940 After: $ vmstat -i interrupt total rate irq1: atkbd0 38 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 2811 15 irq17: em2 5 0 cpu0: timer71013398 irq256: mpt0 12163 68 Total 86073483 Is there any other way we can make mpt0 get its own dedicated IRQ without having to do this? The problem is that it causes us to have to make rc.conf changes, pf.conf changes, and who knows what other software could be on these machines that is trying to bind to a specific NIC... Thanks! You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: hint.mpt.0.msi_enable=1 -Andrew -- Andrew Boyerabo...@averesystems.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 09:18:32AM -0700, Jason Usher wrote: Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting rsa, then dsa to dsa, then rsa was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? OpenBSD ? http://www.openssh.org/list.html --- On Thu, 5/17/12, Jason Hellenthal jhellent...@dataix.net wrote: I have some old 6.x FreeBSD systems that need their OpenSSH upgraded. Everything goes just fine, but when I am done, existing clients are now presented with this message: WARNING: DSA key found for host hostname in /root/.ssh/known_hosts:12 DSA key fingerprint 4c:29:4b:6e:b8:6b:fa:49... The authenticity of host 'hostname (10.1.2.3)' can't be established but keys of different type are already known for this host. RSA key fingerprint is a3:22:3d:cf:f2:46:09:f2.. Are you sure you want to continue connecting (yes/no) You must be using different keys for your server than the one that has been generated before the upgrade. Just copy your keys over to the new location and restart the server daemon and you should be fine. copy /etc/ssh/* - /usr/local/etc/ssh/ You didn't read that error message. Sorry I misread that. Decieving message... That is not the standard key mismatch error that you assumed it was. Look at it again - it is saying that we do have a key for this server of type DSA, but the client is receiving one of type RSA, etc. The keys are the same - they have not changed at all - they are just being presented to clients in the reverse order, which is confusing them and breaking automated, key-based login. I need to take current ssh server behavior (rsa, then dss) and change it back to the old order (dss, then rsa). Have you attempted to change that order via sshd_config and placing the DSA directive before the RSA one ? -- - (2^(N-1)) -- - (2^(N-1)) pgpwYbPqW1wk8.pgp Description: PGP signature
We invite you to a remote job $ 100 per hour helping sick people
We invite you to work in the remote assistant position. This work takes 2-3 hours per week and requires absolutely no investment. The essence of this work for incoming client requests in your city. The starting salary is about 2500 EUR per month + bonuses. You get paid your salary every 2 weeks and your bonuses after fulfilling each task! We guarantee work for everyone. But we accept applications this week only! Therefore, you should write a request right now. And you will start earning money, starting from next week. Please indicate in the request: Your name: Your email address: City of residence: Please send the request to my email col...@topeuropajobs.com,and I will answer you personally as soon as possible Sincerely, Collin Burns ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Mon, 21 May 2012 12:01:19 -0500, Andrew Boyer abo...@averesystems.com wrote: You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: hint.mpt.0.msi_enable=1 Currently implementing this on the known crashy servers. I've been looking around and all of our VM's that do NOT crash also do not share interrupts between em0/mpt0. Thank you very much if this is the fix we will be SO grateful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ARM + CACHE_LINE_SIZE + DMA
Hi Ian (and list), just commenting on the mbuf part : On Monday 21 May 2012 18:20:21 Ian Lepore wrote: On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: On Thu, May 17, 2012 at 10:07 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: Hi, ... What I can do in a driver it's not so simple in case of OS buffers like mbufs. I can check how mbufs are used in current implementation and say, yes, it's safe to use them unaligned. However, it can be changed in next release if anybody won't take care of it. It would be nice to have a maintained list of OS buffers which are DMA safe in respect of CACHE_LINE_SIZE. Is the flag and the list interesting for somebody else? I don't have a definitive answer for this, but my assumption has always been that once an mbuf is handed to a driver (for example, when it's added to an interface's send queue), the driver then owns that mbuf and nothing else in the system will touch it until the driver makes a call to hand it off or free it. If that assumption is true, a driver could make good use of a BUS_DMA_UNALIGNED_SAFE flag with mbufs. The part that scares me about my assumption is the m_ext.ref_cnt field of the mbuf. Its existance seems to imply that multiple entities concurrently have an interest in the data. On the other hand, the lack of any built in provisions for locking seems to imply that concurrent access isn't happening, or perhaps it implies that any required synchronization is temporal rather than lock-based. I've never found anything in writing that explains mbuf usage conventions at this level of detail. This assumption isn't always true. 'man 9 mbuf' mentions this, but not in one place. M_WRITABLE() can be used to tell wether or not you're allowed to modify an mbuf. If it returns false, you can create a writable copy of the mbuf and alter the copy instead of the original. A writable copy of an mbuf can be made using m_dup(). Writing to non-writable mbuf's will cause data corruption in e.g. BPF and TCP retransmits (even in the non-SMP case). Regards, -- Daan Vreeken Vitsch Electronics http://Vitsch.nl tel: +31-(0)40-7113051 KvK nr: 17174380 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need to revert behavior of OpenSSH to the old key order ...
I may have missed some emails in this thread, but did you try this suggestion: But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. -- garance On 5/21/12 12:18 PM, Jason Usher wrote: Folks, Is there a better list for this - perhaps freebsd-security ? I originally posted to -hackers because it *appears* that reverting rsa, then dsa to dsa, then rsa was a simple change to myproposal.h, but since that doesn't work, and since I haven't gotten any replies here ... Thoughts ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad entries
in the grp list due to memory allocation failures while building a
new entry.
Before committing, I wanted to run it past others to see if there
were any problems with it.
%%%
@@ -477,6 +475,13 @@
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ for (freepos = 0;
freepos strpos; freepos++)
+ if
(grp-ng_str[freepos] != NULL)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
%%%
Like this?
if (len 0) {
grp-ng_str[strpos] = (char *)
malloc(len + 1);
+ if (grp-ng_str[strpos] ==
NULL) {
+ int freepos;
+ for (freepos = 0;
freepos strpos; freepos++)
+
free(grp-ng_str[freepos]);
+ free(grp);
+ return(1);
+ }
bcopy(spos, grp-ng_str[strpos],
len + 1);
}
There are a few return without space between the keyword and return value.
Do you recommend I fix all those instances in the file, or just the instances
in this patch?
Thanks,
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: PID/UID namespaces
On 5/21/12 6:47 AM, David Windsor wrote: Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a Process Descriptor. Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? kinda Note terribly explicitly, but somewhere in our collective subconscious.. Thanks, David PS: Excuse my ignorance of anything related to BSD, as I come from a Linux background. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: PID/UID namespaces
On 21 May 2012 14:47, David Windsor dwind...@gmail.com wrote: Hi, While doing some research on FreeBSD jails, I came across an item in the jails' TODO: - be able to have a separate PID space for it - be able to specify a separate UID space for it In other projects, these goals have been accomplished using namespaces. I tried to see if PID/UID namespaces existed in BSD and came across something called Capsicum, a sandboxing project which does not appear to implement outright namespaces for descriptors like PID/UID, but uses something called a Process Descriptor. Is namespacing of PIDs and UIDs an eventual goal of the jails project of FreeBSD? It would certainly prevent many common problems when setting up jails; UID collision is much more common than you'd think, given that the default UIDs remain the same. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ARM + CACHE_LINE_SIZE + DMA
On Mon, May 21, 2012 at 11:20 AM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote: On Thu, May 17, 2012 at 10:07 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. ... My suggestion of making a temporary writable mapping was the answer to how to correctly change memory attributes on a page which is in use, at least in the existing code, which is for a single processor. You don't need, and won't even use, the temporary mapping. You would make it just because doing so invokes logic in arm/arm/pmap.c which will find all existing virtual mappings of the given physical pages, and disable caching in each of those existing mappings. In effect, it makes all existing mappings of the physical pages DMA_COHERENT. When you later free the temporary mapping, all other existing mappings are changed back to being cacheable (as long as no more than one of the mappings that remain is writable). I don't know that making a temporary mapping just for its side effect of changing other existing mappings is a good idea, it's just a quick and easy thing to do if you want to try changing all existing mappings to non-cacheable. It could be that a better way would be to have the busdma_machdep code call directly to lower-level routines in pmap.c to change existing mappings without making a new temporary mapping in the kernel pmap. The actual changes to the existing mappings are made by pmap_fix_cache() but that routine isn't directly callable right now. Also, as far as I know all of this automatic disabling of cache for multiple writable mappings applies only to VIVT cache architectures. I'm not sure how the pmap code is going to change to support VIPT and PIPT caches, but it may no longer be true that making a second writable mapping of a page will lead to changing all existing mappings to non-cacheable. -- Ian We don't want to carry the VIVT cache fixing code to VIPT/PIPT. I like the x86 approach of marking the page with a cache type (default/device/uncached/etc). The page mapping routines (for example pmap_qenter() on a clustered write) will honor that cache type in all future mappings. It is easy to implement. Other allocations, such as page tables, can benefit from an attributed allocation too. I also like having a separate allocator for the sub-page bus_dmamem_alloc() requests that want uncached buffers. These entries can stick around for a long time. If we just malloced the entries, then the other threads that happen to allocate data from the same page are penalized with uncached buffers too. --Mark. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/12 12:02, Guy Helmer wrote:
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad
entries in the grp list due to memory allocation failures while
building a new entry.
Before committing, I wanted to run it past others to see if
there were any problems with it.
%%% @@ -477,6 +475,13 @@ if (len 0) { grp-ng_str[strpos] =
(char *) malloc(len + 1); + if
(grp-ng_str[strpos] == NULL)
{ + for (freepos = 0;
freepos strpos; freepos++) +
if (grp-ng_str[freepos] != NULL) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); + } bcopy(spos,
grp-ng_str[strpos], len + 1);
%%%
Like this?
if (len 0) { grp-ng_str[strpos] = (char *) malloc(len + 1); +
if (grp-ng_str[strpos] == NULL) { +
int freepos; + for
(freepos = 0; freepos strpos; freepos++) +
free(grp-ng_str[freepos]); +
free(grp); +return(1); +
} bcopy(spos, grp-ng_str[strpos], len + 1); }
There are a few return without space between the keyword and
return value.
Do you recommend I fix all those instances in the file, or just the
instances in this patch?
I'd recommend fixing them all (note that you could run into a bigger
commit as the switch() is not style(9) conformant at this time) and we
normally do it in two different commits (one style, and another
functional) when possible.
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJPupePAAoJEG80Jeu8UPuz52wH/RVJXpCyea+ep08XDx82D7tG
us+ujKa1aNOUumzwJRsJ4SNVBiyc+hqCtb8s7FjjeF4/SJk8oei/I1/M1JIyMuIh
FawSB8rNJCbn/u9Od19iOeh/f/IDeCN+q8OrUK5mqQ7G1KDcHs12h86AFlm9HA7K
8UyxneTkPfKhED6hkgSll6bqYAJLeR5jJ3CCGvBeXxNgzJyyAhICWv0UgzUpcY9d
l2beuIXc57toDaLrbWkooLfQclDWPWyyPXq7okexQAq8OUjqmQFE+EhcYsIbtBkH
uBW67jhH81MZf/Ryl83VeqT9IChOySAU0YiwOQxaxdlqR53VAenAY0sWS1QvuX8=
=drgy
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: PID/UID namespaces
In message cadlo838vov_xi+a_wjd3h7e_d4qi+odjynhpoim5bbzawnx...@mail.gmail.com , Chris Rees writes: It would certainly prevent many common problems when setting up jails; UID collision is much more common than you'd think, given that the default UIDs remain the same. Uhm... jails have separate UID/GID spaces. Filesystems mounted or visible in multiple jails act as shared UID/GID (sub-)spaces for those jails, but there is now way to avoid that, it's a direct consequence of the sharing of the filesystems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: PID/UID namespaces
On 21 May 2012 20:57, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cadlo838vov_xi+a_wjd3h7e_d4qi+odjynhpoim5bbzawnx...@mail.gmail.com , Chris Rees writes: It would certainly prevent many common problems when setting up jails; UID collision is much more common than you'd think, given that the default UIDs remain the same. Uhm... jails have separate UID/GID spaces. Filesystems mounted or visible in multiple jails act as shared UID/GID (sub-)spaces for those jails, but there is now way to avoid that, it's a direct consequence of the sharing of the filesystems. Yes, beg pardon, my mistake-- that's what I was meaning to refer to. I still have a patch in GNATS for the docs about that, but it's been the subject of amazing controversy. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Review of changes for getnetgrent.c
On May 21, 2012, at 2:29 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/12 12:02, Guy Helmer wrote:
On May 18, 2012, at 6:09 PM, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On 05/18/12 14:58, Guy Helmer wrote:
To close PR bin/83340, I have this change worked up to resolve
memory allocation failure handling and avoid creating bad
entries in the grp list due to memory allocation failures while
building a new entry.
Before committing, I wanted to run it past others to see if
there were any problems with it.
%%% @@ -477,6 +475,13 @@ if (len 0) { grp-ng_str[strpos] =
(char *) malloc(len + 1); + if
(grp-ng_str[strpos] == NULL)
{ + for (freepos = 0;
freepos strpos; freepos++) +
if (grp-ng_str[freepos] != NULL) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); +} bcopy(spos,
grp-ng_str[strpos], len + 1);
%%%
Like this?
if (len 0) { grp-ng_str[strpos] = (char *) malloc(len + 1); +
if (grp-ng_str[strpos] == NULL) { +
int freepos; + for
(freepos = 0; freepos strpos; freepos++) +
free(grp-ng_str[freepos]); +
free(grp); +
return(1); +
} bcopy(spos, grp-ng_str[strpos], len + 1); }
There are a few return without space between the keyword and
return value.
Do you recommend I fix all those instances in the file, or just the
instances in this patch?
I'd recommend fixing them all (note that you could run into a bigger
commit as the switch() is not style(9) conformant at this time) and we
normally do it in two different commits (one style, and another
functional) when possible.
OK, thank you.
Guy
This message has been scanned by ComplianceSafe, powered by Palisade's
PacketSure.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Need to revert behavior of OpenSSH to the old key order ...
--- On Mon, 5/21/12, Garance A Drosehn g...@freebsd.org wrote: But have you tried it in this order ? HostKey /usr/local/etc/ssh/ssh_host_key HostKey /usr/local/etc/ssh/ssh_host_dsa_key HostKey /usr/local/etc/ssh/ssh_host_rsa_key HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. Anyone ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ARM + CACHE_LINE_SIZE + DMA
On Thu, 17 May 2012 11:01:34 -0500 Mark Tinguely marktingu...@gmail.com wrote: On Thu, May 17, 2012 at 8:20 AM, Svatopluk Kraus onw...@gmail.com wrote: Hi, I'm working on DMA bus implementation for ARM11mpcore platform. I've looked at implementation in ARM tree, but IMHO it only works with some assumptions. There is a problem with DMA on memory block which is not aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. Then first cache line associated with the buffer can be divided into two parts, A and B, where A is a memory we know nothing about it and B is buffer memory. The same stands for last cache line associatted with the buffer. We have no problem if a memory is coherent. Otherwise it depends on memory attributes. 1. [no cache] attribute No problem as memory is coherent. 2. [write throught] attribute The part A can be invalidated without loss of any data. It's not problem too. 3. [write back] attribute In general, there is no way how to keep both parts consistent. At the start of DMA transaction, the cache line is written back and invalidated. However, as we know nothing about memory associated with part A of the cache line, the cache line can be filled again at any time and messing up DMA transaction if flushed. Even if the cache line is only filled but not flushed during DMA transaction, we must make it coherent with memory after that. There is a trick with saving part A of the line into temporary buffer, invalidating the line, and restoring part A in current ARM (MIPS) implementation. However, if somebody is writting to memory associated with part A of the line during this trick, the part A will be messed up. Moreover, the part A can be part of another DMA transaction. To safely use DMA with no coherent memory, a memory with [no cache] or [write throught] attributes can be used without problem. A memory with [write back] attribute must be aligned on CACHE_LINE_SIZE. However, for example mbuf, a buffer for DMA can be part of a structure which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We can know that nobody will write to the structure during DMA transaction, so it's safe to use the buffer event if it's not aligned on CACHE_LINE_SIZE. So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and we want to avoid bounce pages overhead, we must support additional information to DMA transaction. It should be easy to support the information about drivers data buffers. However, what about OS data buffers like mentioned mbufs? The question is following. Is or can be guaranteed for all or at least well-known OS data buffers which can be part of DMA access that the not CACHE_LINE_SIZE aligned buffers are surrounded by data which belongs to the same object as the buffer and the data is not written by OS when given to a driver? Any answer is appreciated. However, 'bounce pages' is not an answer. Thanks, Svata Sigh. A several ideas by several people, but a good answer has not been created yet. SMP will make this worse. To make things worse, there are drivers that use memory from the stack as DMA buffers. I was hoping that mbufs are pretty well self-contained, unless you expect to modify them while DMA is happening. This is on my to-do list. --Mark. Drivers that do DMA from memory that was not allocated by proper busdma methods or load buffers for DMA using not properly constrained busdma tags are broken drivers. We did not have a busdma tag inheritance from parent bus to child devices before, but now we should just take advantage of that and just make cache line alignment a requirement for the platform. USB is firmly in that 'broken' category btw and is currently being worked around by the USB_HOST_ALIGN hack on MIPS, which suffers from the very same cache coherency issues you describe. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Need to revert behavior of OpenSSH to the old key order ...
On Mon, May 21, 2012 at 02:26:27PM -0700, Jason Usher wrote: --- On Mon, 5/21/12, Garance A Drosehn g...@freebsd.org wrote: ???But have you tried it in this order ? ???HostKey /usr/local/etc/ssh/ssh_host_key ???HostKey /usr/local/etc/ssh/ssh_host_dsa_key ???HostKey /usr/local/etc/ssh/ssh_host_rsa_key ???HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key Which is to say, have your sshd_config file list multiple hostkey's, and then restart sshd after making that change? I tried a similar change and it seemed to have some effect on what clients saw when connecting, but I can't tell if it has the effect that you want. The order of HostKey directives in sshd_config does not change the actual order. In newer implementations, RSA is provided first, no matter how you configure the sshd_config. As I mentioned before, removing RSA completely is sort of a fix, but I can't do that because some people might actually be explicitly using RSA, and they would all break. Anyone ? The problem to me seems to be on the client end. Where the new ssh installation is attempting RSA authentication first rather than DSA and your ssh server has just now caught up to the clients. If I were you, I would just make an announcement providing the host fingerprints to clients and asking them to update known_hosts appropriately, rather than creating a virtual fix for sshd that you will have to maintain yourself. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
