On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
wrote:
>
>> 2.a. If task A has sufficient capabilities to send signals to task B, then
>> task A is already in position to do anything it wants with task B, including
>> killing it outright.
>
> Not entirely true.
>
> - We have securirty models
On Sat, Dec 6, 2014 at 6:23 AM, Bastien ROUCARIES
wrote:
>
>
> See senfd recvfd in gnulib. It wirk even under solaris
>
What's so special about a thin wrapper around domain sockets/named
fifos (solaris style)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, Dec 3, 2014 at 9:41 PM, Richard Cochran
wrote:
> In any case, I find it hard to believe that the traditional method is
> really so bad. The explanation of why this new way is needed boils
> down to: "unix programming is so hard to get right."
Surely, this can be said about any new featur
I would like to present my second attempt at file descriptor duplication over
Posix.1b real-time signal transport. All the constructive points raised
in the previous discussion are believed to be addressed.
To this end, I would like to address some concerns raised in the preceding
discussion:
1.
within the siginfo data).
Signed-off-by: Alex Dubov
---
arch/x86/syscalls/syscall_32.tbl | 2 +
arch/x86/syscalls/syscall_64.tbl | 1 +
include/asm-generic/siginfo.h | 1 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/siginfo.h | 1 +
init/Kconfig
On Wed, Dec 3, 2014 at 2:40 PM, Al Viro wrote:
> On Wed, Dec 03, 2014 at 01:22:33PM +1100, Alex Dubov wrote:
>
>> On a less related note, I hope you will agree that the simpler
>> mechanism for this very in-demand feature is long overdue on Linux
>> (every man and his do
On Wed, Dec 3, 2014 at 4:00 AM, Al Viro wrote:
> On Tue, Dec 02, 2014 at 03:35:18PM +1100, Alex Dubov wrote:
>> +
>> + if (rc < 0)
>> + __close_fd(dst_files, s_info.si_int);
>
> Oh, lovely... And we are guaranteed that it still the same file,
On Wed, Dec 3, 2014 at 3:42 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 03:23 +1100, Alex Dubov wrote:
>
> Tell me how a 128 threads program can use this new mechanism in a
> scalable way.
>
> One signal per thread ?
What for?
Kernel will deliver the signal only to the th
On Wed, Dec 3, 2014 at 2:26 AM, Jonathan Corbet wrote:
> On Tue, 2 Dec 2014 15:35:17 +1100
> Alex Dubov wrote:
>
>
> - Messing with another process's file descriptor table without its
>knowledge looks like a possible source of all kinds problems. Might
>the
On Wed, Dec 3, 2014 at 2:33 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote:
>> > User A can send fd(s) to processes belonging to user B, even if user B
>> > does (probably) not want this to happen ?
>>
>> 1. Process A must have
> User A can send fd(s) to processes belonging to user B, even if user B
> does (probably) not want this to happen ?
1. Process A must have sufficient permissions to signal process B.
This will only happen if process A belongs to the same user as process
B or has elevated capabilities, which can n
On Tue, Dec 2, 2014 at 10:42 PM, Michal Simek wrote:
> On 12/02/2014 09:01 AM, Geert Uytterhoeven wrote:
>> This really needs a CC to linux-arch (added).
>>
>> On Tue, Dec 2, 2014 at 5:35 AM, Alex Dubov wrote:
>>> Signed-off-by: Alex Dubov
>>> ---
On Tue, Dec 2, 2014 at 7:01 PM, Geert Uytterhoeven wrote:
> This really needs a CC to linux-arch (added).
>
>
> You forgot to update NR_syscalls in arch/m68k/include/asm/unistd.h.
>
Noted. I would assume that other architectures may have similar
problems (I only tested
my submission on x86_64).
ation signal queue, the newly created file descriptor will be
promptly closed.
Signed-off-by: Alex Dubov
---
fs/Makefile | 1 +
fs/sendfd.c | 82
init/Kconfig | 11
3 files changed, 94 insertions(+)
create mode 100644 fs/sen
Signed-off-by: Alex Dubov
---
arch/arm/include/uapi/asm/unistd.h| 1 +
arch/arm/kernel/calls.S | 1 +
arch/arm64/include/asm/unistd32.h | 2 ++
arch/ia64/include/uapi/asm/unistd.h | 1 +
arch/ia64/kernel/entry.S | 1 +
arch/m68k
A common requirement in parallel processing applications (relied upon by
popular network servers, databases and various other applications) is to
pass open file descriptors between processes. Historically, several mechanisms
existed to support this requirement, such as those provided by "cmsg" faci
x27;s
not
obvious how it is supposed to be handled these days.
From: Larry Finger
To: Catalin Marinas
Cc: Alex Dubov ; Linux Kernel Mailing List
; Kay Sievers ; Greg
Kroah-Hartman
Sent: Monday, 7 October 2013 11:02 AM
Subject: Re: [PATCH] memstick: Fix memo
>
>
> Hi Alex:
Hi,
>
> Do you have any comment on the MEMSTICK part in this v7 patchset? Can
> you help to merge the patch to the kernel tree?
I'm afraid that presently I don't have much time to look at the memstick
related stuff any further. Hopefully, somebody else can step in and take
--- Al Viro <[EMAIL PROTECTED]> wrote:
> readl(sock + ...) that should've been readl(sock->addr + ...)
>
Thanks. It's a first member in struct, so the problem was just sitting there
unnoticed.
Be a b
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
---
drivers/memstick/core/mspro_block.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/memstick/core/mspro_block.c
b/drivers/memstick/core/mspro_block.c
index b9bd0aa..423ad8c 100644
--- a/drivers/me
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
--- mspro_block.c.orig 2008-02-04 15:25:16.0 +1100
+++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
@@ -668,20 +668,13 @@
spin_lock_irqsave(&msb->q_lock, flags);
* Mark shared inline functions as static
* Use member-at-a-time assignment for protocol structures
* Comments for publicly exported functions
* Use end_queued_request to end unhandled block layer requests
* Use sysfs attribute group to export MSPro attributes
* Fix includes
* Use scnprintf in
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available
--- Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available both as storage and as IO expansion cards. Currently, only
> > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
>
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available
--- Carlos Corbacho <[EMAIL PROTECTED]> wrote:
>
> So do we require changes to the userspace udev rules here, or just some use
> of
> modalias in the drivers?
>
It was handled by whoever manages the distro's udev rules until now. Here's the
example:
https://lists.ubuntu.com/archives/ubuntu
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are used i
> However, my only concerns are that:
>
> 1) tifm_ms was not autoloaded
> 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
>
> Although, whether this is an issue with userspace (ie. udev) not dealing with
> the modules properly, I don't know.
>
This is exactly the sam
After a much longer, than expected, time I managed to implement a support for
MemoryStick (read-only currently, as there's still a subtle data corruption bug
with writes) and MemoryStick Pro cards. The implementation follows the MMC
driver model (there exist MSIO cards, but none are supported at
["if (!x & y)" patches from [EMAIL PROTECTED]
> >
> > While we're at it, below is somewhat ugly sparse patch for detecting
> > "&& 0x" typos.
> >
>
> The maintainer for tifm is Alex Dubov, so cc:ing him.
>
>
--- "Renato S. Yamane" <[EMAIL PROTECTED]> wrote:
> When I insert a SDCard in my laptop M45-S355 my system crash because
> tifm start a infinite loop. See below more detail about SD/MMC Card and
> infinite loop.
If you are using the built-in version found in 2.6.21 then it is a known
problem.
Not really.
Current svn has read-only support for legacy MS (not mspro yet). I'm still
working on it. The
major difference: mmc/sd has an open spec, sony ms has none.
--- Norbert Preining <[EMAIL PROTECTED]> wrote:
> Hi Alex, hi all,
>
> I have an Acer TM3012 with
> 0a:09.2 Mass storage contro
>
> > > - Do we need freezeable workqueues ?
> >
> > Well, we have at least one case in which they appear to be useful.
>
I need freezeable wq exactly for the fact that they are synchronized with
suspend/resume. My
workitem may do device_register/unregister and it can (and will be) scheduled
I don't have any particular need in multithreaded wq, but I do need it
freezeable. Freezeability
simplifies things quite a lot. This is ok with me:
> -#define create_freezeable_workqueue(name) __create_workqueue((name), 0, 1)
> +#define create_freezeable_workqueue(name) __create_workqueue((name),
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> > I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
> > After [tifm_sd] is loaded. My smoke test script at
> >
> > http://bugzilla.kernel.org/attachment.cgi?id=11240&action=view
> >
> > reliably hangs suspend.
> After [tifm_sd] is loaded. My smoke test script at
>
> http://bugzilla.kernel.org/attachment.cgi?id=11240&action=view
>
> reliably hangs suspend.
>
What is "modprobe tifm"? What modules have you loaded when it hangs?
__
Do You Yahoo!?
Tired of
> It seems a bit out-of-date. Here is the output:
>
It clearly says there that the driver is for 2.6.20. The changes needed for
2.6.21 are actually
very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree -
>
> I have submitted my version only after I have failed to find a stable
> version of your driver for the current kernel. If there is one, just
> post link to the patch. If not, let's make one.
>
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
prob
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> >
> > I have found it easier to rewrite the driver, than to fix.
>
> Before you get your hopes up, this development model is not one that will get
> your code merged upstream. You should really try to work with Alex, not si
>
> I am not in any way argue that your driver architecture is wrong or that you
> should change anything. My point was simple. [tifm_sd] can only work with
> [tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
> would have port offsets different that [tifm_7xx1], you wo
--- Sergey Yanovich <[EMAIL PROTECTED]> wrote:
> > > For a typical, non-linux-geek user there are just two states of the
> > > device -
> > > available and not available. Ububtu is famous for its end-user support.
> > > They ship your driver since linux-2.6.17. But they pack it in one module.
>
> Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
As I already said before,
daily
suspending/resuming) without a single glitch.
This patch only provides sources.
[PATCH1/2] [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7
Kernel configuration in this message.
[PATCH2/2] [mmc] alternative TIFM driver config for 2.6.21-rc7
Alex Dubov has done exceptionally great lots of work to
In fact, this is fixed in already queued patch set.
--- Daniel Drake <[EMAIL PROTECTED]> wrote:
> Noticed this in user logs.
>
> Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
>
> Index: linux/drivers/mmc/tifm_sd.c
> ===
> --- lin
Problem 2: After a data crc error all subsequent commands fail. May it be
caused by stop command
leaving card in some bad state (something clearable by SEND_STATUS)? On the
other hand, is there a
real need to issue a stop command in case main command failed?
Example:
Mar 14 09:25:13 Ti
Recently, I've obtained a bug report concerning an MMC card. Two problems are
described, both
sporadic.
Problem 1: illegal ocr value is returned. You may notice, in the non-working
case, obviously
incorrect ocr value (0x) is returned. The card won't work after this,
unless reinserted.
Wh
> >
> > mmc_rescan
> > mmc_register_card
> > device_add
> > mmc_block_probe
> > mmc_block_alloc
> > -> queue thread starts running
> > add_disk
> > -> issues a lot of requests; card fails, my drivers calls
> > mmc_remove_host, which in
correction
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of
> > requests (reads
> partition
> > table, fs superblocks and such - plenty of room for critical err
> > This is hard to trigger problem, so I'll spare you the rather lengthy log.
> > It happens if card timeouts and mmc_remove_host is called while
> > mmc_register_card is still in
> > progress (the hint was in crash dump). If I sleep before remove, it gives
> > the
> mmc_register_card
> > chance
>
> I don't see how that is possible. mmc_block's remove routine waits for mmcqd
> to
> exit, so there can't be any code still alive that has a request going. (I am
> also completely unable to reproduce this problem here).
>
> Add more printk:s do verify how the code in mmc_block executes.
>
Th
> I don't see that - as I say above, the correct sequence is:
>
> - host device resume
> - calls mmc_resume_host()
> - child's device resume (mmc_blk_resume)
> - mmc_queue_resume()
>
Of course, I understand that this is a correct sequence. It simply was not
obvious to me that host
w
> I don't actually think that is what happening. The block errors tend to trail
> a
> bit behind, so the errors you are seeing are probably the result of the queue
> being flushed out as you remove the card. I don't see any mmc debug messages
> that indicate that is trying to send more mmc request
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> > Alex Dubov wrote:
> > > And today: yet another problem with mmc.
> > > It so happens that after resume mmc layer issues requests to the device
> > > befor
And today: yet another problem with mmc.
It so happens that after resume mmc layer issues requests to the device before
mmc_resume_host is
called at all. Moreover, this prevents the machine from resuming, unless worked
around, because
software timer does not work at this stage of the resume and i
If we are already on the topic, I would like to report two additional issues
with mmc_block:
1. If, for some reason, device driver cannot return the requested data amount,
but does not sets
any error, mmc_block would retry indefinitely. Of course, its always a device
driver's fault, but
may be
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> > I removed that line altogether (it does not really needed as mmc host will
> > not be accessed
> > anymore). The problem is more elaborate. Here, the card fails,
> > mmc_host_remove is call
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > It just occurred to me that my synopsis of the problem was utterly lame.
> > Here, the correct description:
> > When the card is pulled out, I mark the host as "ejected" (so it f
>
> This looks like the problem with races in mmc_block again. Add some printk:s
> in
> the remove function so that you can see if this oops is after the remove
> function (shouldn't be possible, but will cause crash if it is).
It just occurred to me that my synopsis of the problem was utterly l
One more problem (you may already know about it) - I was contacted by somebody
from the hald
project and indeed I can confirm that on 2.6.20 kernel hald fails to take
action on card
insertion. I can't see anything in my code so this may be a general mmc problem.
The problem is described here:
htt
Greetings.
It seems that the recent shower of error reports was caused by my not so
thorough testing of the
R6 handling problems (I've sent you a patch for this).
However, there is this other problem with mmc_host_remove while transfer is in
progress.
First, I disabled my "sleep on remove" hack
with
sdhci unloaded and machine freshly rebooted (not resumed).
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov is the maintainer of tifm, not me.
>
> Andreas Steinmetz wrote:
> > Hi,
> > I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device
>
The patch looks ok.
However, due to certain peculiarities with memorystick and xd I have to emulate
a scatter-gather
in software. Considering that this particular aspect of implementation is the
same for all card
types on this TI chip, it can be shared by tifm_sd driver as well. In this case
hi
Memorystick support is not yet implemented (work in progress).
--- [EMAIL PROTECTED] wrote:
> Running recent kernels the insertion of a MemoryStick into the card
> reader of a Sony Vaio VGNSZ3XWP is detected but the card does not seem
> to be probed for partitions and hence is not made available
> That shouldn't be possible. Are you using the block queue fixes I wrote?
> Otherwise you will get problems like this.
>
> Basically, when you call mmc_host_remove(), it will remove all card
> devices. That shouldn't complete until all card drivers have released
> control of the card. At that poi
Greetings.
It appears to me that under certain circumstances mmc layer will issue requests
to the host after
mmc_host_remove returns. This happens, for example, in tifm_sd driver because
mmc_host may be
removed mid-transfer, as the socket shall be freed for possible reuse by
different media typ
I think the trivial fix will do (after all, there's nothing that should matter
to the controller
in the R6 response; I don't know about R7). I don't have any SDHC cards so I
can't test this.
--- tifm_sd.c.orig 2006-12-11 01:39:28.0 +1100
+++ tifm_sd.c 2007-01-04 23:40:48.441724000
66 matches
Mail list logo
