> That does still leave me a little uneasy as far as the microcode
> licenses go. I don't know that we can distribute signed copies of some
> of them, and we obviously can't sign at the user end.
You seem to put them in signed rpm packages ?
--
To unsubscribe from this list: send the line "uns
On Wed, 31 Oct 2012 17:17:43 +
Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 05:21:21PM +0000, Alan Cox wrote:
> > On Wed, 31 Oct 2012 17:10:48 +
> > Matthew Garrett wrote:
> > > The kernel is signed. The kernel doesn't check the signature on the
> &
On Wed, 31 Oct 2012 17:10:48 +
Matthew Garrett wrote:
> On Wed, Oct 31, 2012 at 05:03:34PM +0000, Alan Cox wrote:
> > On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
> > Jiri Kosina wrote:
> > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
&g
> >> Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
> >> from that artificial image.
> > It's not signed. It won't reboot from that image.
>
> So then to hibernate the kernel must have a signing key?
No.
If you break the kernel so you can patch swap we already lost.
If
On Wed, 31 Oct 2012 15:56:35 +
Matthew Garrett wrote:
> 1) Gain root.
> 2) Modify swap partition directly.
> 3) Force reboot.
> 4) Win.
>
> Root should not have the ability to elevate themselves to running
> arbitrary kernel code. Therefore, the above attack needs to be
> impossible.
To p
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Jiri Kosina wrote:
> On Wed, 31 Oct 2012, Alan Cox wrote:
>
> > All this depends on your threat model. If I have physical access to
> > suspend/resume your machine then you already lost. If I don't have
> > physical access
> > Let me see if setting "whinedays" to "0" will turn off the automated
> > whines while letting people set up custom whines as they needed. If that
> > doesn't work, then I'll set "whinedays" to 3650, so at least this way
> > the only bugs you'll get whines about will be those that have been "NEW
> > is basically DMA-ing arbitrary data over the whole RAM. I am currently not
> > able to imagine a scenario how this could be made "secure" (without
> > storing private keys to sign the hibernation image on the machine itself
> > which, well, doesn't sound secure either).
That's what the TPM is
> I don't want to flame on this topic, but you are not right here. As far as I
> can
> see, a big chunk of Linux storage and file system developers are/were
> employed by
> the "gold-plated storage" manufacturers, starting from FusionIO, SGI and
> Oracle.
>
> You know, RedHat from recent time
> If you just want to wipe a disk, you shouldn't be using /dev/urandom for that
> purpose.
If you want to wipe a disk issue a security erase command via hdparm.
There is no guarantee that simply writing crap all over it will re-use
the same sectors of physical media, and for a flash drive it cause
On Fri, 26 Oct 2012 14:57:31 -0700
Min Zhang wrote:
> On Fri, Oct 26, 2012 at 7:19 AM, Alan Cox wrote:
>
> > So we only need to check this in serial8250_handle_irq when IIR indicates
> > a data timeout interrupt ?
> >
> > Can we do
> >
On Fri, 26 Oct 2012 10:11:45 +0200
Guillaume Juan wrote:
> From: Guillaume Juan
>
> If gsm->tty happens to be NULL in gsmld_output, avoid crashing the kernel
> (the crash is replaced by a warning dump).
More important is fixing the bug completely. I agree there is a bug I
don't think your fix
actually get him to
apply it have never had a reply from anyone who has raised it
So apply it anyway
Signed-off-by: Alan Cox
---
fs/notify/fanotify/fanotify.c |1 +
1 file changed, 1 insertion(+)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index aeb5b5a
On Sun, 28 Oct 2012 11:04:46 +0100
Jiri Slaby wrote:
> On 10/02/2012 12:13 AM, Greg KH wrote:
> > On Mon, Oct 01, 2012 at 11:48:58PM +0200, Jiri Slaby wrote:
> >> On 10/01/2012 08:30 PM, Greg KH wrote:
> >>> Stanislav Kozina (2):
> >>> tty: Fix possible race in n_tty_read()
> >>
> >> The (p
On Fri, 26 Oct 2012 14:45:02 -0400
Rik van Riel wrote:
> Intel has an architectural guarantee that the TLB entry causing
> a page fault gets invalidated automatically. This means
> we should be able to drop the local TLB invalidation.
>
> Because of the way other areas of the page fault code wor
IMHO absent any reason to make the allocation change we should keep the
existing behaviour. Absent any reason to fiddle with the code we should
leave it alone.
It's delicate, tricky, tiny and works. Don't fiddle.
For the size question if the default behaviour is to pack them in
then a caller can
> It is racing. For "too much work for irq", here is sequence events
> analyzed by a Motorola engineer:
Thanks - this is enormously helpful in understanding the report.
> 5) The LSR indicates that the transmitter needs data,
> but also indicates the presence of data in the FIFO (0x61 in t
On Thu, 25 Oct 2012 15:37:43 -0400
Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools (lkvm) guest running latest
> -next kernel,
> I've stumbled on the following spew:
Looks real enough but its not a tty/vt layer spew. This is all coming out
of the core framebuffer
From: Alan Cox
More relevantly what about termination and locks ?
Anyway the array check is useless so remove it.
Signed-off-by: Alan Cox
---
kernel/irq/manage.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 4c69326
From: Alan Cox
If new_nsproxy is set we will always call switch_task_namespaces and then
set new_nsproxy back to NULL so the reassignment and fall through check
are redundant
Signed-off-by: Alan Cox
---
kernel/fork.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
From: Alan Cox
The second error check is unreachable because the lock function
isn't assigned to ret
Signed-off-by: Alan Cox
---
drivers/power/max17042_battery.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/max17042_battery.c b/drivers/
(Resending to the list as the maintainer is not responding to direct email)
From: Alan Cox
The mtip driver lifted this code from elsewhere and then added a special
handling check for SEC_ERASE_UNIT. If the caller tries to do a security
erase but passes no output data for the command then outbuf
> > Hopefully, eventually the storage developers will realize the value
> > behind ordered commands and learn corresponding SCSI facilities to
> > deal with them.
>
> Eventually, drive manufacturers will realize that trying to price
> guage people who want advanced features such as TCQ, DIF/DIX, i
On Wed, 24 Oct 2012 12:36:04 -0700
"H. Peter Anvin" wrote:
> Minor concern: it should do the wait for ready before sending each command.
Can we get a command line to do this quirk too - it strikes me that if
the MSIs rely upon it then it may be something Windows always does so
will be useful to
n",
> + printk(KERN_ERR "%s: word length not supported\n",
> __func__);
Looks fine me although the bfin_uart one should just be picking a
suitable bit length and reporting back the one it uses not printing
errors 8)
Acked-by: Alan Cox
On Wed, 24 Oct 2012 10:06:36 +0100
"David Laight" wrote:
> > Looks the problem is worse than above, not only bitfields are affected, the
> > adjacent fields might be involved too, see:
> >
> >http://lwn.net/Articles/478657/
>
> Not mentioned in there is that even with x86/amd64 give
> Added module parameter skip_rdi_check to opt out this workaround.
NAK. Anything like this should be runtime.
> Tested on Radisys ATCA 46XX which uses FPGA 16550-compatible and
> other generic 16550 UART. It takes from an hour to days to reproduce by
> pumping inputs to serial console continousl
> 1. The ldisc drops the contents of tty_buffer on hangup (rather than
> waiting for completion). Maybe for other devices this isn't so
> noticeable because the ldisc can mostly keep up with the device, but on
> firewire the ldisc lags well behind. Right now, this driver works around
> this by hold
> That (walking all parent nodes) is probably the safest thing to do. I'm
> not sure whether it's optimal. It would likely depend on whether you
> can meaningfully have a bridge that's faster on the downstream side than
> on the upstream.
This is architecture goo at heart - would this be bett
refcounting in the interrupt service routines and other hot paths
> after we are done. This is because we do not need to handle races
> among ISRs, timers, hangups and others, because tty_port lives as long
> as an interrupt/timer tick may occur. Unlike tty_struct.
Looks good to me working throu
> [ 689.950596] gma500 :00:02.0: Backlight lvds set brightness 7a127a12
> [ 689.950627] [drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on
> minor 0
It's got the LVDS configured it seems and the brightness was already set
up. That should be harmless.
> Besides the VGA the driver
o work on a relative UART port
> base address, as well as the 8250_pci code to make it register 2 UART ports
> for CE4100 and pass the port index down to all consumers.
>
> Signed-off-by: Florian Fainelli
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsub
> > + skb_headlen(skb),
> > + DMA_TO_DEVICE);
> > + desc[frag].addr_lo = dma_addr & 0x;
> > + desc[frag].addr_hi = dma_
> a later stores, and stores are viewed in program order, so all x86
> stores have "release consistency" modulo the theoretical PPro bugs
> (that I don't think we actually ever saw in practice).
We did seem the for real. The PPro is on its way out however so I hardly
thing we care about optimising
On Tue, 16 Oct 2012 16:49:32 +0200
Borislav Petkov wrote:
> Hi all,
>
> a bunch of my boxes started showing this on 3.7-rc1 (and maybe earlier):
>
> [4.667077] ata4.00: failed to get Identify Device Data, Emask 0x1
> [4.675071] ata4.00: failed to get Identify Device Data, Emask 0x1
Can
From: Alan Cox
This happens to do the right thing in all cases on fibre channel but not on
other media types
Signed-off-by: Alan Cox
---
drivers/message/fusion/mptscsih.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion
From: Alan Cox
If elf_core_dump is called and fill_note_info fails in the kmalloc then
it returns 0 but has not yet initialised all the needed fields. As a result
we do a kfree(randomness) after correctly skipping the thread data.
Signed-off-by: Alan Cox
---
fs/binfmt_elf.c |4 +++-
1
> Greg, Alan, what about this series? Is there anything else I should do?
Other than resending it now the merge window is closed - I can't think of
anything.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Mon, 15 Oct 2012 21:41:20 +0200
"Mikko C." wrote:
> Hi,
> we keep getting kernel panics on our CentOS 6.3 server, running about 40
> KVM virtual machines.
>
> Here's the screenshot of the trace: http://i.imgur.com/yaRyF.png
>
> # uname -a
> Linux srv010 2.6.32-71.el6.x86_64 #1 SMP Fri May 2
On Mon, 15 Oct 2012 10:39:45 -0600
Jason Gunthorpe wrote:
> On Mon, Oct 15, 2012 at 08:35:09AM +, peter.hu...@infineon.com wrote:
> > > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> >
> > > Using open/close is an interesting idea, but it wouldn't work. open()
> > > is cod
> I realize that fips_enabled is only for crazy people, but it's exactly
> code like this that limits it to only crazy people. Is there some
> *reason* for this?
Presumably its so a typical server with reboot on panic will reboot so
the attacker can hide the attempt better ;-)
Alan
--
To unsubsc
> The people which are responsible that the chips for "consumer"-HW and
> laptops got their (already included) ECC functionality disabled should
> get hit with Googles (now 3y old) study on that topic all the day.
> Leaving customers in danger by not offering them at least the
> possibility to
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
[l/
> We have reproduced this on multiple hardware environments, using 3.2
> (/proc/version_signature gives "Ubuntu 3.2.0-29.46-generic 3.2.24").
> Anecdotally we believe the situation has worsened since 3.0.
I've certainly seen this on 3.0 and 3.2, but do you still see it on
3.5/6 ?
--
To unsubscribe
> > The alignment is fine (the offset of the u16 is 8 bytes), but
> > unfortunately with the metag port of gcc, sizeof(struct
> > scsi_varlen_cdb_hdr) is rounded up to a 4 byte boundary (even though the
> > largest data member alignment is only 2 bytes), which is 12 bytes
> > instead of 10.
>
> Th
ffer
> can not be done for the original SIO device.
>
> Signed-off-by: Jarkko Huijts
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Sun, 7 Oct 2012 21:56:45 +0800
Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference should be moved below the NULL test.
The !dev check just wants removing I think - it's a bogus check in the
first place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
> I have the same objection as before: using platform device solely for
> the purpose of passing some data from board code to the driver. Surely
> there are other ways of passing this bit of data... What about, for
> example, making it an empty weak symbol so that board code could
> override it wit
> Actually this is Joe's version of the patch. Joe, people started hitting
> the bug [1]. Could you resend your patch?
>
> [1] https://patchwork.kernel.org/patch/1339221/
>
> BTW what scares me that nobody noticed that bug until this is in the
> Linus's tree. Do people use -next at all or am I th
> I don't know how to handle the /dev/ptmx issue properly from within
> devtmpfs, does anyone? Proposals are always welcome, the last time this
> came up a week or so ago, I don't recall seeing any proposals, just a
> general complaint.
Is it really a problem - devtmpfs is optional. It's a proble
On Wed, 3 Oct 2012 23:18:06 +0200
Kay Sievers wrote:
> On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote:
>
> > As for the firmware path, maybe we should
> > change that to be modified by userspace (much like /sbin/hotplug was) in
> > a proc file so that distros can override the location if they n
> If this happens, I _really_ want to bring back the CONFIG options I had in
> an earlier version of this patch. I want to be able to declare the default
> at build time, and not leave a system vulnerable from boot until sysctls
> get set.
If your early boot code trusts a random writeable user dir
On Wed, 3 Oct 2012 13:05:15 -0700
Kees Cook wrote:
> Hi Nick,
>
> 3.6 introduced link restrictions:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
>
> It sounds like you've got symlinks in a world-writable directory, and
>
> So the bug had been latent and it only showed up with such low cock
> rates.
clock ?
Perhaps Greg can tweak the description as it goes in - otherwise all
fine with me
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Hooper
Signed-off-by: Alan Cox
---
arch/x86/kernel/reboot.c |8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 52190a9..4e8ba39 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -358,14 +358,6 @@ static
> +/* Is this for UART emulation on ARC Instruction Set Simulator (ISS)
> */ +int __attribute__((weak)) running_on_iss;
Why not pass a quirks field in your platform data instead - much
cleaner than a global.
> +static void arc_serial_set_ldisc(struct uart_port *port, int ld)
> +{
> +}
If you don'
From: Alan Cox
The second error check is unreachable because the lock function
isn't assigned to ret
Signed-off-by: Alan Cox
---
drivers/power/max17042_battery.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/max17042_battery.c b/drivers/
> Signed-off-by: Alexey Brodkin
Seems sensible to me.
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> +int __attribute__((weak)) running_on_iss;
Globals really ought to have sensible names, if they must exist at all.
Why is this needed ?
> +#define ARC_SERIAL_DEV_NAME "ttyS"
ttyS is reserved by the 8250 driver. Use a different name
> /* ttySxx per Documentation/devices.txt */
> +#define ARC_
On Fri, 28 Sep 2012 15:40:32 +0800
Zhang Rui wrote:
> >From 6077a62f2865201ab6727ca7d628ee5e43aa57e1 Mon Sep 17 00:00:00 2001
> From: Zhang Rui
> Date: Fri, 24 Aug 2012 15:18:25 +0800
> Subject: [RFC PATCH 5/6] ACPI: Introduce ACPI I2C controller enumeration
> driver
>
> This driver is able to
> Remove panic calls from drivers/tty/pty.c
>
> There is no need to panic the system if the allocation/registration of
> the pty drivers fails. Instead return an error and fail the module load.
>
> Signed-off-by: Ryan Mallon
NAK
this is pointless complexity
This is early boot up code.
> > Otherwise - TICOGPKT is specific to pty devices. Please therefore put it
> > in the pty.c code and note that not all platforms use asm-geneic TTY
> > ioctls so check carefully they all build.
>
> I put it into tty_ioctl.c simply because TIOCPKT was there already so
> I thought it's good idea t
> Well, sure inside our tool before doing checkpoint we stop all
> tasks which are part of dumpee process tree. This unfortunatly
> doesn't apply to these ioctl calls. Peter, any idea how to deal
> with that?
I suspect you can't deal with that. Which isn't to say you can't still
build something us
> Alan, Greg, what's opinion? This flags fetching is the same as say fetching
> of termios settings, once fetched they can be changed immediately, and it's
> up to caller what to do with termios settings. No?
I think you need to explain what you expect to be doing with it, and why
it is safe in th
> as far as I know, nested locks are fine provided that you always take them in
> the same order and release them in the opposite order (lock A, lock B,
> unlock B, unlock A). So my conclusion is that nested spinlocks require
> potential regmap users of sta2x11 registers to take the sta2x11-mfd spi
On Tue, 25 Sep 2012 16:35:20 +0100
David Howells wrote:
> Alan Cox wrote:
>
> > Generate a certificate that is valid from a few minutes before the
> > wallclock time. It's a certificate policy question not a kernel hackery
> > one.
>
> That doesn't see
On Tue, 25 Sep 2012 16:09:54 +0100
David Howells wrote:
>
> The X.509 certificate has a pair of times in it that delineate the valid
> period of the cert, and I'm checking that the system clock is within the
> bounds they define before permitting you to use the cert. I've been setting
> the exp
t 9600 bauds it gives a timeout of 4 characters, which is
> the timeout on the 8250 UART.
>
> Signed-off-by: Christophe Leroy
Looks good tome - series Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
> The issue is/was, that root can inject code at runtime which is then
> executed in kernel environment.
Yes there are lots of other ways to do this too. The constraint we use
for it is CAP_SYS_RAWIO. With that capability you can totally do raw
hardware access and the like so requiring it for runt
On Sun, 23 Sep 2012 16:40:07 +0200
richard -rw- weinberger wrote:
> Hi!
>
> I'm booting 3.6-rc6 using KVM and observe the following output:
> $ tty
> /dev/tty0
> $ cat /sys/class/tty/tty0/active
> tty1
>
> Why does the active file say I'm on tty1?
> There is no tty1, I'm on tty0.
> (Also "who"
> > Guys, you mean something like below? Look, I must admit I'm not really
> > sure if I've done all locking right, and there is no need for additional
> > kref counting on tty_struct. Could you please check if it looks more-less
> > sane (I've tested it but still...)
This still doesn't answer th
> I could not find any indication that this problem has been fixed yet
> in 3.6rc.
Should be fixed in the very latest 3.6-rc. I got a report from someone
else that I could duplicate and pin down exactly. It's made somewhat
more complicated by the fact that another bug got introduced and then
fixed
From: Alan Cox
load_elf_interp has interp_map_addr carefully described as
"uninitialized_var" and marked so as to avoid a warning. However
if you trace the code it is passed into load_elf_interp and then
this value is checked against NULL.
As this return value isn't used this i
Could do with double checking...
From: Alan Cox
If elf_core_dump is called and fill_note_info fails in the kmalloc then
it returns 0 but has not yet initialised all the needed fields. As a result
we do a kfree(randomness) after correctly skipping the thread data.
Signed-off-by: Alan Cox
stem either.
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 19 Sep 2012 14:31:36 +1000
Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the usb tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/usb/serial/vizzini.c: In function 'vizzini_set_termios':
> drivers/usb/serial/vizzini.c:454:22: error: invalid typ
On Tue, 18 Sep 2012 14:00:03 -0500
Jaeden Amero wrote:
> The RS-485 TIOCSRS485 and TIOCGRS485 ioctls are 32-bit compatible, so
> in order to call them on 64-bit systems from 32-bit user mode, we add
> them to the ioctl pointer list as compatible ioctls.
>
> Signed-off-by: Jaeden Amero
Added to
On Tue, 18 Sep 2012 18:34:12 +0100
David Howells wrote:
> Alan Cox wrote:
>
> > Why do this in the kernel.That appears to be completely insane.
>
> A number of reasons:
>
> (1) The UEFI signature/key database may contain ASN.1 X.509 certificates and
> we
O> +/* make sure the offsets array isn't truncated */
> + if (table->num * sizeof(table->offset[0]) +
> + sizeof(struct resource_table) > entry->size) {
> + sproc_err(sproc, "resource table incomplete\n");
> + return NULL;
None of these checks appear to be r
On Mon, 17 Sep 2012 11:49:30 +0100
Alan Cox wrote:
> From: Alan Cox
>
> oom_score_adj_write doesn't terminate the string as it should. Also fix
> sched_autogroup_write and other copy/pastes of the bug.
>
> Signed-off-by: Alan Cox
> Cc: Horses
Ok ignore this one
On Mon, 17 Sep 2012 14:18:19 +0300
Dan Carpenter wrote:
> I don't think anyone really cares about this but just for laughs here
> is the warning:
>
> drivers/tty/synclink.c:5418 usc_process_rxoverrun_sync() warn: potential
> memory corrupting cast 8 vs 2 bytes
> drivers/tty/synclink.c:6414 mgsl
> (a) Since all the mappings have been removed, so why don't the fd's get
> released ?
Because your code is buggy.
Firstly its files it keeps a reference to not file handles, so your close
closes the file handle. You do however end up with lots of file structs
pinned and that's because you've go
On Mon, 17 Sep 2012 11:29:08 +0100
Matt Fleming wrote:
> From: Matt Fleming
>
> The efi_enabled variable has come to mean "Do we have EFI runtime
> services available?". However, lack of EFI runtime services does not
> mean that we should switch to using the VGA console. Provided that the
> boo
My only disagreement here would be putting it in the ia64 paths. If
someone does the same for x86-32 (and this is EFI so it'll presumbly
smell the same on all platforms) then we'll want the same.
Better I think to generically catch the 0/0 case.
Alan
--
To unsubscribe from this list: send the li
From: Alan Cox
oom_score_adj_write doesn't terminate the string as it should. Also fix
sched_autogroup_write and other copy/pastes of the bug.
Signed-off-by: Alan Cox
Cc: Horses
---
fs/proc/base.c |2 ++
fs/proc/task_mmu.c |1 +
2 files changed, 3 insertions(+)
diff --git
> At least with a recent modern distro I can't imagine this to be an
> issue. I expect we could have a kernel build option that removed the
> mknod system call and a modern distro wouldn't notice.
A few things beyond named pipes will break. PCMCIA I believe still
depends on ugly mknod hackery of
> One piece of the puzzle is that we should be able to allow unprivileged
> device node creation and access for any device on any filesystem
> for which it unprivileged access is safe.
Which devices are "safe" is policy for all interesting and useful cases,
as are file permissions, security tags,
> Yes, postgress performs loads better with it's spinlocks, but due to
> that, it necessarily _hates_ preemption. How the is the scheduler
> supposed to know that any specific userland task _really_ shouldn't be
> preempted at any specific time, else bad things follow?
You provide a shared page f
On Fri, 14 Sep 2012 01:30:06 +0400
Alexey Khoroshilov wrote:
> tty_port_tty_get() can return NULL after port hangup that may happen anytime.
> The patch adds checks that tty_port_tty_get() returns nonNULL around places
> where tty is actually used.
I don't believe you can simply skip the process
On Fri, 14 Sep 2012 00:50:05 +0100
David Howells wrote:
> Add an ASN.1 BER/DER/CER decoder. This uses the bytecode from the ASN.1
> compiler in the previous patch to inform it as to what to expect to find in
> the
> encoded byte stream. The output from the compiler also tells it what
> functi
t_char routine. IIUC, Alan is less unhappy about it. As a
> result, clear_irq() callback dropped.
Ok that has my ack. Some of it is not pretty but debugger hooks that
have to run behind the OS while debugging it never are.
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line &quo
On Thu, 13 Sep 2012 16:54:01 +0400
Cyrill Gorcunov wrote:
> On Thu, Sep 13, 2012 at 01:51:31PM +0100, Alan Cox wrote:
> > > +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> > > +{
> > > + int locked = test_bit(TTY_PTY_LOCK, &tty->fla
> +static int pty_get_lock(struct tty_struct *tty, int __user *arg)
> +{
> + int locked = test_bit(TTY_PTY_LOCK, &tty->flags);
> + if (put_user(locked, arg))
> + return -EFAULT;
Now explain exactly how this doesn't race with another thread chanigng
the lock setting ?
The other
> +ssize_t blk_filter_store(struct request_queue *q,
> + const char *page, size_t count, int rw)
> +{
> + unsigned long okbits[BLK_SCSI_CMD_PER_LONG], *target_okbits;
> + bool set;
> + const char *p = page;
> + char *endp;
> + int start = -1, cmd;
> +
> +
O
> + if (!q->cmd_filter) {
> + q->cmd_filter = kmalloc(sizeof(struct blk_cmd_filter),
> + GFP_KERNEL);
> + blk_set_cmd_filter_defaults(q->cmd_filter);
Out of memory - memset - oops
--
To unsubscribe from this list: send the line "uns
On Wed, 12 Sep 2012 13:23:43 +0200
Paolo Bonzini wrote:
> Using /dev/sg for scanners is blocked from unprivileged users. Reimplement
> this using customizable command filters, so that the sysfs knobs will work
> in this case too.
>
> Cc: linux-is...@vger.kernel.org
> Signed-off-by: Paolo Bonzin
> Of course, if Alan is OK with this, I'm more than OK too. :-)
It may well be better.
> (But the polling routines would need to clear all interrupts, not
> just rx/tx. For example, if the controller indicated some error, and
> nobody clears it, then we'll start reentering infinitely.)
For a lot
On Tue, 11 Sep 2012 02:35:00 -0700
Anton Vorontsov wrote:
> This patch implements a new callback: clear_irqs. It is used for the
This bit I still really don't like. I would like to know what the generic
IRQ folks thing about it and if Thomas Gleixner has any brilliant ideas
here. I don't think
> +struct kgdb_nmi_tty_priv {
> + struct tty_port port;
> + int opened;
> + struct tasklet_struct tlet;
> + STRUCT_KFIFO(char, KGDB_NMI_FIFO_SIZE) fifo;
I don't see where "opened" is used.
> +static const struct tty_operations kgdb_nmi_tty_ops = {
> + .open = kgdb_n
On Tue, 11 Sep 2012 00:43:21 +0300
Tomas Winkler wrote:
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/mei_dev.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
> index 96d3e79..adb35fb 100644
> ---
701 - 800 of 5738 matches
Mail list logo
