Signed-off-by: YOSHIFUJI Hideaki
---
drivers/firewire/net.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index df6a1ca..2b27bff 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -270,7 +270,7 @
At Fri, 18 Jan 2013 17:21:38 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.0.60 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
T
On Sunday 20 of January 2013, Woody Suwalski wrote:
> Arkadiusz Miskiewicz wrote:
> > On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
> >> On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> >>> On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote:
> Hi.
> >
At Fri, 18 Jan 2013 17:19:18 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.27 release.
> There are 21 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
T
At Fri, 18 Jan 2013 17:16:25 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.7.4 release.
> There are 33 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Th
From: Torsten Kaiser
Commit fb59581404ab7ec5075299065c22cb211a9262a9 removed
xfs_flushinval_pages() and changed its callers to use
filemap_write_and_wait() and truncate_pagecache_range() directly.
But in xfs_swap_extents() this change accidental switched the argument
for 'tip' to 'ip'. This pat
On Sun, Jan 20, 2013 at 03:58:13AM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
NAK for two reasons:
a) the original Nokia kernel used a separate g_file_storage gadget to
use Mass Storage mode, use that
b) there is no commit log
--
balbi
signature.asc
Description: Digital si
Hi,
On Fri, Jan 18, 2013 at 03:43:59PM -0800, Greg KH wrote:
> On Mon, Jan 14, 2013 at 10:55:48AM +0800, fangxiaozhi 00110321 wrote:
> >
> > From: fangxiaozhi
> >
> > 1. Optimize the matching rules with new macro for Huawei USB storage
> >devices, to avoid to load USB storage driver for the
On Jan 20 YOSHIFUJI Hideaki wrote:
> It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
> the device has already checked it.
>
> Signed-off-by: YOSHIFUJI Hideaki
> ---
> drivers/firewire/net.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fire
On 01/19/2013 03:01 PM, Pali Rohár wrote:
> bq27xxx batteries have a lot of properties, more than power_supply interface.
> Some of them can be usefull for userspace applications (like CI bit) but
> does not make sense to add bq specified property to power_supply interface.
> When bq27x00_battery i
On 01/18/2013 02:38 PM, Jesper Nilsson wrote:
> On Wed, Jan 16, 2013 at 11:30:44PM +0100, Cong Ding wrote:
>> The pointer tty is dereferened in line 3135, so it is not necessary to check
>> null again in line 3140.
>
> I don't know if we actually need to check the parameter tty from being null,
>
On Sunday 20 January 2013 10:25:37 Felipe Balbi wrote:
> On Sun, Jan 20, 2013 at 03:58:13AM +0100, Pali Rohár wrote:
> > Signed-off-by: Pali Rohár
>
> NAK for two reasons:
>
> a) the original Nokia kernel used a separate g_file_storage
> gadget to use Mass Storage mode, use that
>
> b) there is
On 01/18/2013 08:25 AM, Thierry Reding wrote:
> A duplicate definition of the port variable was introduced in the
> interrupt handler, which causes the build to break. The fix is to
> rename the variable to tport, which is already properly used in
> subsequent code.
>
> Signed-off-by: Thierry Redi
From: Borislav Petkov
Add a helper function to return cpufreq_driver->name.
Signed-off-by: Borislav Petkov
---
drivers/cpufreq/cpufreq.c | 14 ++
include/linux/cpufreq.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
From: Borislav Petkov
Andreas reports in https://bugzilla.kernel.org/show_bug.cgi?id=51741
that with his Gentoo config, acpi-cpufreq wasn't enabled and powernow-k8
couldn't handoff properly to acpi-cpufreq leading to running without
P-state support (i.e., cores are constantly in P0).
To alleavia
From: Borislav Petkov
Now that the majority of x86 CPUs out there are supported by
acpi-cpufreq, we want it to load first and, in the AMD case, drop to
powernow-k8 only on K8s. If, however, both powernow-k8 and acpi-cpufreq
are built-in, the link order matters. Correct that.
Signed-off-by: Boris
From: Borislav Petkov
Make it hotplug-safe and cleanup formatting.
Signed-off-by: Borislav Petkov
---
drivers/cpufreq/powernow-k8.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
inde
From: Borislav Petkov
Check whether we've actually already loaded acpi-cpufreq before
requesting it.
Signed-off-by: Borislav Petkov
---
drivers/cpufreq/powernow-k8.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drive
From: Matthew Garrett
de3ed81d746d ("[CPUFREQ] Change link order of x86 cpufreq modules")
changed cpufreq drivers link order so that powernow-k8 gets loaded first
due to earlier K8s having BIOS bugs.
However, now that acpi-cpufreq supports both AMD and Intel CPUs with HW
P-states, we want to loa
From: Borislav Petkov
Hi all,
here are a couple of patches fixing acpi-cpufreq and powernow-k8 loading
sequence and handoff.
Patch 0001 should be in Rafael's tree already but I'm adding it here for
the sake of completeness. Basically, we want to address all possible
cases of powernow-k8 and acp
On Sun, Jan 20, 2013 at 06:06:21AM +0100, Mike Galbraith wrote:
> Sounds as though any patches you submit land on your dinner plate just
> like potatoes. Hand the cook a pot of half peeled potatoes, he/she may
> say try again.
And how he/she would say it! I've seen serious fights spring up from
ha
Hello,
See below for a part of the logging on this F2A85X-UP4 with AMD
a10-5800k. Box was raid checking I guess.
Jan 20 03:42:08 s3 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.10" x-pid="3031" x-info="http://www.rsyslog.com";]
rsyslogd was HUPed
Jan 20 04:11:17 s3 kernel: AMD-Vi: Compl
I know just the guy, CCed. :-)
On Sun, Jan 20, 2013 at 11:33:19AM +0100, Udo van den Heuvel wrote:
>
> Hello,
>
> See below for a part of the logging on this F2A85X-UP4 with AMD
> a10-5800k. Box was raid checking I guess.
>
>
> Jan 20 03:42:08 s3 rsyslogd: [origin software="rsyslogd"
> swVersi
Stefan Richter wrote:
> On Jan 20 YOSHIFUJI Hideaki wrote:
>> It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
>> the device has already checked it.
>>
>> Signed-off-by: YOSHIFUJI Hideaki
>> ---
>> drivers/firewire/net.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
Hello,
On 2013-01-20 11:36, Borislav Petkov wrote:
> I know just the guy, CCed. :-)
Thanks for the quick response!
I found this similar case:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073384
Kind regards,
Udo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hi,
anyone seen this already? I've got this this morning when resuming
and this is -rc4+ (+ tip/master) but without any other cpufreq and
powernow-k8 patches.
It says below "[last unloaded: acpi_cpufreq]" because I played with
loading and unloading powernow-k8 and acpi-cpufreq yesterday but ...
Namjae Jeon writes:
> From: Namjae Jeon
>
> When searching a directory for names, we can stop checking for further
> entries if we detect End of Directory, i.e. if (de->name[0] == 0x00).The
> current code traverses the cluster chain of a directory until a hit is
> found or till the last cluster
Namjae Jeon writes:
> We rewrite patch as your suggestion using dummy inode. Would please
> you review below patch code ?
Looks like good as initial. Clean and shorter.
Next is, we have to think about race. I.e. if real inode was made, what
happens? Is there no race?
Thanks.
> Subject: [PATCH
On Sun, Jan 20, 2013 at 11:40:20AM +0100, Udo van den Heuvel wrote:
> Hello,
>
> On 2013-01-20 11:36, Borislav Petkov wrote:
> > I know just the guy, CCed. :-)
>
> Thanks for the quick response!
> I found this similar case:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073384
Yes, this
I used the following method since 2.4 version
1. copy .config from the old kernel
2. make oldconfig
(2-1. make dep)
3. make && make modules && make modules_install && make install
and then change the symbolic link of kernel header in /usr/include
to the compiled kernel header.
Works well from 2.4.0
Hello Jörg,
On 2013-01-20 12:19, Jörg Rödel wrote:
> On Sun, Jan 20, 2013 at 11:40:20AM +0100, Udo van den Heuvel wrote:
>> Hello,
>>
>> On 2013-01-20 11:36, Borislav Petkov wrote:
>>> I know just the guy, CCed. :-)
>>
>> Thanks for the quick response!
>> I found this similar case:
>> https://bugs
Cache control is an eMMC feature and in therefore should be
part of MMC's bus resume operations, performed in mmc_suspend,
rather than in the generic mmc_suspend_host().
Signed-off-by: Maya Erez
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..b438bb2 100644
--- a/dr
On Sun, Jan 20, 2013 at 12:25:07PM +0100, Udo van den Heuvel wrote:
> Hello Jörg,
>
> Hardware issue? What is wrong c.q. happening?
I think it falls under Erratum 455 (which does not mention IOMMU
specifically). Point is, there is a hardware workaround for this to make
the IOMMU work, but your BI
On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> gating for the IOMMU.
Right, Udo, you can try Gigabyte first.
Btw, can't we add a quirk to disable NB clock gating? Maybe Boris and
Jacob could help. CCed.
Guys,
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> > Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> > gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
Btw, you're running the l
On 2013-01-20 12:48, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
>> Yes, the BIOS vendor can fix this issue. They need to disable NB clock
>> gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
I just did so and referred to the kernel.org bug
On Sun, Jan 20, 2013 at 12:48:28PM +0100, Borislav Petkov wrote:
> On Sun, Jan 20, 2013 at 12:40:11PM +0100, Jörg Rödel wrote:
> > Yes, the BIOS vendor can fix this issue. They need to disable NB clock
> > gating for the IOMMU.
>
> Right, Udo, you can try Gigabyte first.
>
> Btw, can't we add a q
On 2013-01-20 12:50, Borislav Petkov wrote:
>> Right, Udo, you can try Gigabyte first.
>
> Btw, you're running the latest BIOS from them, I assume?
Nope. But I am beyond their first released BIOS, I am running one of
their beta BIOSes. I am two beta updates behind current with F3g.
They list as d
On 01/17/2013 12:47 PM, Alexander Holler wrote:
> Am 17.01.2013 02:49, schrieb Axel Lin:
>
> Thanks, yes, I missed it the initialization of the spinlock.
>
> Below is my ack.
>
> Regards,
>
> Alexander
>
>> Signed-off-by: Axel Lin
>
> Acked-by: Alexander Holler
Applied to togreg branch of i
On Sun, Jan 20, 2013 at 12:59:59PM +0100, Udo van den Heuvel wrote:
> On 2013-01-20 12:50, Borislav Petkov wrote:
> >> Right, Udo, you can try Gigabyte first.
> >
> > Btw, you're running the latest BIOS from them, I assume?
>
> Nope. But I am beyond their first released BIOS, I am running one of
Hello.
I'm experiencing two regressions in 3.8-rcX.
Regression:
(1) Console shows nothing, which makes it impossible to determine whether
the system is working or not.
(2) SCSI_SYM53C8XX_2 cannot register IRQ, showing below messages upon load.
PCI: enabling device :00:0c.0
On Sunday 20 of January 2013, Arkadiusz Miskiewicz wrote:
> On Sunday 20 of January 2013, Woody Suwalski wrote:
> > Arkadiusz Miskiewicz wrote:
> > > On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote:
> > >> On Saturday 19 of January 2013, Greg Kroah-Hartman wrote:
> > >>> On Fri, Jan 18,
On Thu, Jan 10, 2013 at 01:41:04PM -0500, Matt Porter wrote:
> The edma_slave_config() implementation depends on the
> direction field such that it will not properly configure
> a slave channel when called without direction set.
>
> This fixes the implementation so that the slave config
> is copie
On 1/17/13, Amit Daniel Kachhap wrote:
> Below fixes are done to support falling threshold interrupt,
> * Falling interrupt status macro corrected according to exynos5 data sheet.
> * The get trend function modified to calculate trip temperature correctly.
> * The clearing of interrupt status in t
- Original Message -
> From: "Mike Galbraith"
> To: "Tom St Denis"
> Cc: "Eric Dumazet" , "Waskiewicz Jr, Peter P"
> , "David Miller"
> , "steffen klassert" ,
> herb...@gondor.apana.org.au,
> linux-kernel@vger.kernel.org, net...@vger.kernel.org, "Michal Kubecek"
>
> Sent: Sunday, 20
- Original Message -
> From: "Borislav Petkov"
> To: "Mike Galbraith"
> Cc: "Tom St Denis" , "Eric Dumazet"
> , "Waskiewicz Jr, Peter P"
> , "David Miller" ,
> "steffen klassert"
> , herb...@gondor.apana.org.au,
> linux-kernel@vger.kernel.org, net...@vger.kernel.org,
> "Michal Kubece
On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote:
> The call is implemented as follows:
>
> struct dmaengine_chan_caps
> *dma_get_channel_caps(struct dma_chan *chan,
> enum dma_transfer_direction dir);
>
> The dma transfer direction parameter may
On Thu, Jan 10, 2013 at 02:07:04PM -0500, Matt Porter wrote:
> +/* struct dmaengine_chan_caps - expose capability of a channel
> + * Note: each channel can have same or different capabilities
> + *
> + * This primarily classifies capabilities into
> + * a) APIs/ops supported
> + * b) channel physic
On 20 January 2013 12:29, Maya Erez wrote:
> Cache control is an eMMC feature and in therefore should be
> part of MMC's bus resume operations, performed in mmc_suspend,
> rather than in the generic mmc_suspend_host().
>
> Signed-off-by: Maya Erez
>
> diff --git a/drivers/mmc/core/core.c b/driver
On Thu, Jan 10, 2013 at 02:07:05PM -0500, Matt Porter wrote:
> Implement device_channel_caps().
>
> EDMA has a finite set of PaRAM slots available for linking
> a multi-segment SG transfer. In order to prevent any one
> channel from consuming all PaRAM slots to fulfill a large SG
> transfer, the d
Am 20.01.2013 13:56, schrieb Tom St Denis:
You should really try running checkpatch.pl over code that's already in the
kernel before you call out new contributors on it.
How is this supposed to not be adversarial when I can't even use the Kernel
source itself as a reference?
In case of the
James Courtier-Dutton wrote:
> I have been given a linux kernel sources tar file.
> It contains a modified version of the linux kernel.
> It is just source files, without any "git" history.
> What I would like to do is compare this with the mainline linux kernel
> git tree, and find the tag from th
- Original Message -
> From: "Alexander Holler"
> To: "Tom St Denis"
> Cc: "Borislav Petkov" , "Eric Dumazet" ,
> "Waskiewicz Jr, Peter P"
> , "David Miller" ,
> "steffen klassert"
> , herb...@gondor.apana.org.au,
> linux-kernel@vger.kernel.org, net...@vger.kernel.org,
> "Michal Kube
On Thu, Jan 17, 2013 at 12:36:28PM -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> This is not arch perfmon, but older CPUs will just ignore it. This makes
> it possible to do at least some TSX measurements from a KVM guest
>
> Cc: a...@redhat.com
> Cc: g...@redhat.com
> v2: Various fixes to add
On Sunday, January 20, 2013 11:24:24 AM Borislav Petkov wrote:
> From: Borislav Petkov
>
> Hi all,
>
> here are a couple of patches fixing acpi-cpufreq and powernow-k8 loading
> sequence and handoff.
>
> Patch 0001 should be in Rafael's tree already but I'm adding it here for
> the sake of comp
On Sun, 2013-01-20 at 07:55 -0500, Tom St Denis wrote:
>
> - Original Message -
> > From: "Mike Galbraith"
> > To: "Tom St Denis"
> > Cc: "Eric Dumazet" , "Waskiewicz Jr, Peter P"
> > , "David Miller"
> > , "steffen klassert" ,
> > herb...@gondor.apana.org.au,
> > linux-kernel@vger.ke
On Tue, Jan 15, 2013 at 01:19:48AM +0100, Cong Ding wrote:
> the pointer cfg is dereferenced in line 594, so it's no reason to check null
> again in line 620.
>
> Signed-off-by: Cong Ding
> ---
> drivers/dma/mmp_pdma.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --
On Tue, Jan 15, 2013 at 01:23:48AM +0100, Cong Ding wrote:
> the variable chan is dereferenced in line 635, so it is no reason to check
> null again in line 641.
>
> Signed-off-by: Cong Ding
> ---
> drivers/dma/sh/shdma-base.c |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/driver
Indeed neither the device nor the lower drivers check protocol checksums.
But the CRCs of the encapsulating 1394 packets are checked in hardware.
Shall protocol checksums be verified regardless?
Yes, because packets may come from off-link source.
Hm, I can't see any off-link packets coming
From: Rafael J. Wysocki
Since ACPI power resources are going to be used more extensively on
new hardware platforms, it is necessary to allow user space (powertop
in particular) to look at the lists of power resources corresponding
to different power states of devices for diagnostics and control
p
Hi Greg,
The following patch series is about exporting ACPI power resources to user
space that will be necessary for PM diagnostics on new platforms (powertop is
the target). Still, existing systems can also benefit from that, like my
oldish HP nx6325 on which the patches have been tested.
Patch
From: Rafael J. Wysocki
Since ACPI power resources are going to be used more extensively on
new hardware platforms, it becomes necessary for user space (powertop
in particular) to observe some properties of those resources for
diagnostics purposes.
For this reason, export the reference counts of
From: Rafael J. Wysocki
The most convenient way to expose ACPI power resources lists of a
device is to put symbolic links to sysfs directories representing
those resources into special attribute groups in the device's sysfs
directory. For this purpose, it is necessary to be able to add
symbolic
This is calling list_del() inside a loop which is a problem when we try
move to the next item on the list. I've converted it to use the _safe
version. And also, as a cleanup, I've converted it to use
list_for_each_entry instead of list_for_each.
Signed-off-by: Dan Carpenter
---
Static analysis
- Original Message -
> From: "Mike Galbraith"
> To: "Tom St Denis"
> Cc: "Eric Dumazet" , "Waskiewicz Jr, Peter P"
> , "David Miller"
> , "steffen klassert" ,
> herb...@gondor.apana.org.au,
> linux-kernel@vger.kernel.org, net...@vger.kernel.org, "Michal Kubecek"
>
> Sent: Sunday, 20 J
Stephan Gatzka wrote:
>
>>> Indeed neither the device nor the lower drivers check protocol checksums.
>>> But the CRCs of the encapsulating 1394 packets are checked in hardware.
>>> Shall protocol checksums be verified regardless?
>>
>> Yes, because packets may come from off-link source.
>>
>
> H
"Off-link source" means the source exists on the different L2
network. In other words, source is connected via router(s).
ethernet firewire
Host -- Router Host
O.k., understood. But the receiving router verifies the checksum of
incoming pack
From: Sebastian Wankerl
Enclose the macro into braces so that it can be closed by a semicolon
Signed-off-by: Sebastian Wankerl
Signed-off-by: Sebastian Ehrenfels
---
drivers/staging/wlan-ng/prism2mgmt.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
dif
From: Sebastian Wankerl
Formated pr_debug() calls
Signed-off-by: Sebastian Wankerl
Signed-off-by: Sebastian Ehrenfels
---
drivers/staging/wlan-ng/prism2mgmt.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/driver
On 01/09/2013 11:14 AM, Preeti U Murthy wrote:
> Here comes the point of making both load balancing and wake up
> balance(select_idle_sibling) co operative. How about we always schedule
> the woken up task on the prev_cpu? This seems more sensible considering
> load balancing consid
Hi Dave,
I've figured a pull request is easier ;-)
Changes since the patchbomb on dri-devel:
- Added a patch to adjust the new omapdrm code in 3.8-rc4, reviewed by Rob
Clark on irc (hence also why the baseline of this pull is 3.8-rc4).
- Slightly fixed/clarified some commit messages and fixed o
On Sun, Jan 20, 2013 at 4:08 PM, Rob Clark wrote:
> One thing I've run into in the past when trying to make changes in drm
> core, and Daniel Vetter has mentioned the same, is that it is a bit of
> a pain to compile test things for the arm drivers that do not support
> CONFIG_ARCH_MULTIPLATFORM.
Stephan Gatzka wrote:
>
>> "Off-link source" means the source exists on the different L2
>> network. In other words, source is connected via router(s).
>>
>> ethernet firewire
>> Host -- Router Host
>>
>
> O.k., understood. But the receiving route
>>> The blocked load of a cluster will be high if the blocked tasks have
>>> run recently. The contribution of a blocked task will be divided by 2
>>> each 32ms, so it means that a high blocked load will be made of recent
>>> running tasks and the long sleeping tasks will not influence the load
>>>
Hi,
Can anybody provide any inputs/suggestions/improvements on the following.
According to my experiments these proved to be a useful utility during low
memory condition on the embedded devices.
Is there something wrong I am doing?
Please provide your suggestions.
Thanks,
Pintu
>___
On 20 January 2013 13:27, Clemens Ladisch wrote:
> James Courtier-Dutton wrote:
>> I have been given a linux kernel sources tar file.
>> It contains a modified version of the linux kernel.
>> It is just source files, without any "git" history.
>> What I would like to do is compare this with the ma
You then get into issues like: do we have to ban prelink as a result?
Mimi Zohar wrote:
>On Thu, 2013-01-17 at 10:51 -0500, Vivek Goyal wrote:
>> On Thu, Jan 17, 2013 at 10:37:01AM -0500, Mimi Zohar wrote:
>> > On Tue, 2013-01-15 at 16:34 -0500, Vivek Goyal wrote:
>> > > If a binary is signed, v
There were no break statements in this switch statement so everything
used the default settings. Per Walter Harms's suggestion, I've replaced
the switch statement and done a little cleanup.
Signed-off-by: Dan Carpenter
---
v2: Make additional style fixes as well while we're messing with the
On Sun, Jan 20, 2013 at 12:37:34PM +, Vinod Koul wrote:
> On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote:
> > The call is implemented as follows:
> >
> > struct dmaengine_chan_caps
> > *dma_get_channel_caps(struct dma_chan *chan,
> > enum dma_tran
On Sun, Jan 20, 2013 at 12:52:43PM +, Vinod Koul wrote:
> On Thu, Jan 10, 2013 at 02:07:04PM -0500, Matt Porter wrote:
> > +/* struct dmaengine_chan_caps - expose capability of a channel
> > + * Note: each channel can have same or different capabilities
> > + *
> > + * This primarily classifies
On Thu, 2013-01-17 at 16:52 -0500, Vivek Goyal wrote:
> On Thu, Jan 17, 2013 at 11:46:57PM +0200, Kasatkin, Dmitry wrote:
> > On Thu, Jan 17, 2013 at 10:55 PM, Vivek Goyal wrote:
> > > On Thu, Jan 17, 2013 at 03:33:47PM -0500, Frank Ch. Eigler wrote:
> > >> Vivek Goyal writes:
> > >>
> > >> > [..
On Sun, Jan 20, 2013 at 01:03:21PM +, Vinod Koul wrote:
> On Thu, Jan 10, 2013 at 02:07:05PM -0500, Matt Porter wrote:
> > Implement device_channel_caps().
> >
> > EDMA has a finite set of PaRAM slots available for linking
> > a multi-segment SG transfer. In order to prevent any one
> > channe
On Sun, 2013-01-20 at 08:17 -0800, H. Peter Anvin wrote:
> You then get into issues like: do we have to ban prelink as a result?
Once you change a file, the original signature shouldn't match. If you
really trust prelink, then make prelink a trusted application that can
resign the modified file.
On 01/20/2013 08:55 AM, Mimi Zohar wrote:
> On Sun, 2013-01-20 at 08:17 -0800, H. Peter Anvin wrote:
>> You then get into issues like: do we have to ban prelink as a result?
>
> Once you change a file, the original signature shouldn't match. If you
> really trust prelink, then make prelink a trus
On 01/20/2013 07:07 AM, Tom St Denis wrote:
In all likelihood I will submit a revised CMAC patch but it'll take
time before I can get business hours to work on it. So instead of
having a maintainer just touch it up we're all going to lose out
because of pride?
It's not about pride. It is ab
On Thu, 2013-01-17 at 12:36 -0500, Vivek Goyal wrote:
> On Thu, Jan 17, 2013 at 11:32:45AM -0500, Mimi Zohar wrote:
>
> [..]
> > > > At this point, why would you want yet another method for signing files?
> > >
> > > Are you saying that append signature instead of putting them in a section
> > >
- Original Message -
> From: "H. Peter Anvin"
> To: "Tom St Denis"
> Cc: "Mike Galbraith" , "Eric Dumazet"
> , "Waskiewicz Jr, Peter P"
> , "David Miller" ,
> "steffen klassert"
> , herb...@gondor.hengli.com.au,
> linux-kernel@vger.kernel.org, net...@vger.kernel.org,
> "Michal Kubecek"
On Sun, 2013-01-20 at 10:07 -0500, Tom St Denis wrote:
> In all likelihood I will submit a revised CMAC patch but it'll take
> time before I can get business hours to work on it. So instead of
> having a maintainer just touch it up we're all going to lose out
> because of pride?
Yes -- but it wou
- Original Message -
> From: "David Dillow"
> To: "Tom St Denis"
> Cc: linux-kernel@vger.kernel.org, net...@vger.kernel.org
> Sent: Sunday, 20 January, 2013 11:34:52 AM
> Subject: Re: IPsec AH use of ahash
>
> On Sun, 2013-01-20 at 10:07 -0500, Tom St Denis wrote:
> > In all likelihood I
> > signalfd is a special descriptor, so I think it
> > is not a big deal, that it works a bit strange.
>
> Sure, but the more we special case things, the uglier the ABI as a
> whole becomes. So special casing should be avoided as far as we can.
>
> > If all other would
> > decides, that a new s
On Sun, 2013-01-20 at 12:40 -0500, Tom St Denis wrote:
> > On Sun, 2013-01-20 at 10:07 -0500, Tom St Denis wrote:
> > > In all likelihood I will submit a revised CMAC patch but it'll take
> > > time before I can get business hours to work on it. So instead of
> > > having a maintainer just touch i
Hi Andrey,
On Sun, Jan 20, 2013 at 6:41 PM, Andrew Vagin wrote:
>
>> > signalfd is a special descriptor, so I think it
>> > is not a big deal, that it works a bit strange.
>>
>> Sure, but the more we special case things, the uglier the ABI as a
>> whole becomes. So special casing should be avoide
- Original Message -
> From: "David Dillow"
> To: "Tom St Denis"
> Cc: linux-kernel@vger.kernel.org, net...@vger.kernel.org
> Sent: Sunday, 20 January, 2013 1:11:11 PM
> Subject: Re: IPsec AH use of ahash
>
> On Sun, 2013-01-20 at 12:40 -0500, Tom St Denis wrote:
> > > On Sun, 2013-01-
On Sun, Jan 20, 2013 at 6:20 AM, Suho Park wrote:
> I used the following method since 2.4 version
> 1. copy .config from the old kernel
> 2. make oldconfig
> (2-1. make dep)
> 3. make && make modules && make modules_install && make install
> and then change the symbolic link of kernel header in /u
add lkml/cc's.
On 01/18, Linus Torvalds wrote:
>
> On Fri, Jan 18, 2013 at 10:55 AM, Oleg Nesterov wrote:
> >
> > Or we can do this after wait_task_inactive() but then we need to take
> > ->siglock again.
>
> Yes. We absolutely need siglock, since that would be exactly what
> would protect us aga
Cleanup and preparation for the next change.
signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.
Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a t
putreg() assumes that the tracee is not running and pt_regs_access()
can safely play with its stack. However a killed tracee can return
from ptrace_stop() to the low-level asm code and do RESTORE_REST,
this means that debugger can actually read/modify the kernel stack
until the tracee does SAVE_RES
arch/ia64/kernel/ptrace.c:thread_matches() has no users since e868a55c
"[IA64] remove find_thread_for_addr()", remove it.
And this allows us to unexport ptrace_check_attach().
Signed-off-by: Oleg Nesterov
---
arch/ia64/kernel/ptrace.c | 27 ---
include/linux/ptrace.h
wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
Change it to use TASK_NORMAL and add the WARN_ON().
TASK_ALL has no other users, probably can be killed.
Signed-off-by: Oleg Nesterov
---
kernel/sched/core.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --gi
On 01/20, Oleg Nesterov wrote:
>
> > And we'd need to make sure to re-set the WAKEKILL flag not just in all
> > the callers of ptrace_check_attach(), but also in the failure case of
> > wait_task_inactive(). I'm not sure it can actually fail if we cleared
> > WAKEKILL, but it's all pretty subtle.
>
1 - 100 of 304 matches
Mail list logo
