which is an elaborate way to cause kernel panic. Change the VOPs
implementation to return EBADF for a reclaimed vnode.
While the calls to vop_bmap should not reach deadfs, it is indeed
possible for vop_ioctl, because the VOP locking protocol is to pass
the vnode to VOP unlocked. The actual panic was observed when ioctl
was called on procfs filedescriptor which pointed to an exited
process.
Reported by: zont
Tested by: pho
MFC after: 1 week
- Pacific/Fiji will go into DST from 21 October 2012 till 20 January 2013.
- Fix offset for Pacific/Tokelau.
- Gaza and West Bank had DST from 29 March to 28 September 2012.
- Syria has DST from April till October
- Morocco had DST from April to September 2012 except for 20 July to 20 August.
- Cuba changed to DST from 1 April 2012 only.
- Haiti has DST between 8 March and 1 November in 2012.
Obtained from: ftp://ftp.iana.org/tz/releases/
- Pacific/Fiji will go into DST from 21 October 2012 till 20 January 2013.
- Fix offset for Pacific/Tokelau.
- Gaza and West Bank had DST from 29 March to 28 September 2012.
- Syria has DST from April till October
- Morocco had DST from April to September 2012 except for 20 July to 20 August.
- Cuba changed to DST from 1 April 2012 only.
- Haiti has DST between 8 March and 1 November in 2012.
Obtained from: ftp://ftp.iana.org/tz/releases/
Compared to __member2struct(), this macro has the following advantages:
- It ensures that the type of the pointer is compatible with the member
field of the structure (or a void pointer).
- It works properly in combination with volatile and const, though
unfortunately it drops these qualifiers from the returned value.
mdf@ proposed to add the container_of() macro, just like Linux has.
Eventually I decided against this, as <sys/param.h> is included all over
the place. It seems container_of() on Linux is specific to the kernel,
not userspace. I'd rather not pollute userspace with this.
I also thought about adding __container_of(), but this would have two
advantages. Xorg seems to already have a __container_of(), which is not
compatible with this version. Also, the underscore in the middle
conflicts with our existing macros (__offsetof, __rangeof, etc).
I'm changing member2struct() to use its old code, as the extra
strictness of this new macro conflicts with existing code (read: cxgb).
MFC after: 1 month
No, this isn't HT/5 and HT/10 support. This is the 11a half/quarter
rate support primarily used by the 4.9GHz and GSM band regulatory
domains.
This is definitely a work in progress.
TODO:
* everything in the last commit;
* lots more interoperability testing with the AR5212 half/quarter rate
support for the relevant chips;
* Do some interop testing on half/quarter rate support between _all_
the 11n chips - AR5416, AR9160, AR9280 (and AR9285/AR9287 when 2GHz
half/quarter rate support is coded up.)
used when running the chips in half/quarter rate.
This sets up some default parameters which are then overridden by the
driver (which manually configures things like slot timing at interface
start time.)
Although this is a copy-and-modify from the AR5212 HAL, I did peek
at the reference HAL and the ath9k driver to see what they did.
Ath9k in particular doesn't hard-code this - instead, their version
of ar5416InitUserSettings() does all of the relevant math.
TODO:
* do the math, not hard code things!
* fix the mac clock calculation for the AR9287; since it runs the
MAC clock at a higher rate, requiring all the duration calculations
to change;
* Do a whole lot more validation for half/quarter rates.
Obtained from: Qualcomm Atheros, Linux ath9k
Some of the math is a little wrong thanks to clocks in 11a mode running
at 44MHz when in fast clock mode (rather than 40MHz, which the chips
before AR9280 ran 11a in). That'll have to be addressed in a future commit.
This fixes the incorrect slot (and likely ACK/RTS timeout) values
which I see when enabling half/quarter rate support on the AR9280.
The resulting math matches the expected calculated default values.
The prev-pointers point to the next-pointers of the previous element --
not the ENTRY structure. The next-pointers are stored in the ENTRY
structures first, so the code would already work correctly. Still, it is
more accurate to use the next-fields.
To prevent misuse of __member2struct() in the future, I've got a patch
that requires the pointer to be passed to this macro to be compatible
with the member of the structure. I'll commit this patch after I've
tested it properly.
MFC after: 1 month.
Idle threads are not allowed to acquire any lock but spinlocks.
Deny any attempt to do so by panicing at the locking operation
when INVARIANTS is on. Then, remove the check on blocking on a
turnstile.
The check in sleepqueues is left because they are not allowed to use
tsleep() either which could happen still.
Reviewed by: bde, jhb, kib
MFC after: 1 week
with TDP_NOSLEEPING on.
The current message has no informations on the thread and wchan
involed, which may be useful in case where dumps have mangled dwarf
informations.
Reported by: kib
Reviewed by: bde, jhb, kib
MFC after: 1 week
Regular LISTs have been implemented in such a way that the prev-pointer
does not point to the previous element, but to the next-pointer stored
in the previous element. This is done to simplify LIST_REMOVE(). This
macro can be implemented without knowing the address of the list head.
Unfortunately this makes it harder to implement LIST_PREV(), which is
why this macro was never here. Still, it is possible to implement this
macro. If the prev-pointer points to the list head, we return NULL.
Otherwise we simply subtract the offset of the prev-pointer within the
structure.
It's not as efficient as traversing forward of course, but in practice
it shouldn't be that bad. In almost all use cases, people will want to
compare the value returned by LIST_PREV() against NULL, so an optimizing
compiler will not emit code that does more branching than TAILQs.
While there, make the code a bit more readable by introducing
__member2struct(). This makes STAILQ_LAST() far more readable.
MFC after: 1 month
The ENOTDIR mapping was introduced in r235266 for kern/128933 based on
an interpretation of the somewhat ambiguous language in the POSIX realpath
specification. The interpretation is inconsistent with Solaris and Linux,
a regression from 9.0, and does not appear to be permitted by the
description of ENOTDIR:
20 ENOTDIR Not a directory. A component of the specified pathname
existed, but it was not a directory, when a directory was
expected.
PR: standards/171577
MFC after: 3 days
is something for make(1) to consume. Bmake gives output such as:
"warning: Couldn't read shell's output for "/bin/sh -c true"
Note we parted from traditional Pmake behavior in r18864 / r18255.
with no output. Add "echo" at the end these shell commands whose output is
assigned to a variable's value to ensure there is some output.
Submitted by: John Van Horne <jvanhorne@juniper.net>
When truss is detaching from very active process it is possible to
hang on waitpid(2) in restore_proc() forever, because
ptrace(PT_SYSCALL) must be called before detaching, to allow the
debugging process to continue execution. Also when truss called with
'-c' argument, it does not print anything after detach, because it
immediately exits from restore_proc().
To fix these two problems make detaching deferred, but then it is
impossible to detach from a process which does not do any system call.
To fix this issue use sigaction(2) instead of signal(3) to disable
SA_RESTART flag for waitpid(2) that makes it non-restartable. Remove
global variable child_pid, because now detaching is handled in context
where child's pid is known.
Reported by: mjg
Tested by: mjg, swills
Approved by: kib (mentor)
MFC after: 2 weeks
